Indeed. The objects shown in the illustrations aren't secret, and aren't unique. If you're calling the object "something you have" and the camera angle "something you know", anyone with the same watch (for example) satisfies the first of those.
So that's about a 1/1000 false accept rate against a brute force attack, which is comparable to some biometrics. This actually isn't very good. A determined attacker will not just send random pictures, but will send pictures that they think the target of the attack may have used. This results on a much higher false accept rate.
Even 1/1000 is marginal enough that substantial rate limiting is going to be needed to keep the account secure. Compare that against the security of, say, a 6-digit random one-time password (1/1 million).
And as another commenter pointed out, it's not meaningful to talk about false accept rate without also talking about the false reject rate.
I bought a Model B several months ago from Newark, and have two more in transit to me from them. But yes, stock is low; they were backordered a couple of weeks.
My Fedora 8 machine (kernel: 2.6.26.6-49.fc8) crashed around midnight UTC as well. Last syslog message was at 23:40:07 UTC so it may have not happened at exactly midnight; it would be unusual not to have something logged for 20 minutes. When I got to the machine, it was completely unresponsive; couldn't get it to do anything but reboot. The hardware has been very reliable and it's on a UPS.
I have seen a thread on linux.debian.user about this happening on Debian.
Before someone points it out, yes, I know that support for Fedora 8 goes away in a week or so.
DKIM is designed to not require individual devices such as PDAs to be modified; that's one of the benefits of signing at the domain level. But it does require the domain to support it, although with a Blackberry you may not have much choice in the matter.
The SSP specification is under active development in the IETF DKIM Working Group. There is a much newer version of the spec here, but the spec is still evolving.
The public key is looked up using the "s" (selector) and "d" (domain) attributes of the signature. "c" specifies the canonicalization algorithm (used to deal with trivial modifications such as spacing to the body).
Actually, DKIM permits MUAs to sign and verify messages, but we really expect the vast majority of DKIM signing and verifying to be done my MTAs, at the domain level. The ability to delegate keys to individual users is to handle those few cases where an individual user needs to sign a message, plus other outsourced functions (such as an enterprise's outsourced benefits provider) where a party outside the domain needs to be able to apply a signature. It's less of a leap of trust to do this when the key is constrained to a specific address.
Does this mean that if a hotel charges me $12.95 a day for "broadband", I can get my money back if I'm not getting 2 Mbps? I'm tired of paying for hotel "broadband" connections that are slower than dialup.
Of course, I tend to go to conferences with a lot of other Internet-hungry attendees, but hotels ought to be able to buy more bandwidth with what they're making on these charges.
You need to be a little careful with SPF -all; if you send to people who forward their mail (as from a college alumni address) and the address they forward to honors SPF, your messages could be rejected.
DKIM does solve much the same problem as SPF, but Sender Signing Practices (SSP), which gives guidance for recipients on dealing with unsigned mail, is still under development.
The biggest problem with the classic signature systems (e.g., PGP, S/MIME) is that they don't have quite the right key management model. Anyone can create a PGP key with any mail address they want, and sign messages. Similarly, anyone can get a certificate for an email address they have (perhaps an employer), but when they leave the company, does the certificate get revoked? No; the employer may not even know of its existence.
Signature schemes designed for this purpose, like DKIM, are actually a signature from the domain owner, not the author. While the domain owner may delegate a signing key to an individual in certain cases, they retain the ability to revoke the key at any time.
Maybe I'm missing something about DomainKeys, but if I'm using an "@aol.com" "From:" header, I need to send it through AOL's SMTP servers so that AOL can sign it; if I can't reach AOL's SMTP servers, I can't get it signed. It's that simple. Even if I can get it signed by the SMTP server of my ISP, that signature won't match my "From:" header so it fails the check on the user's end.
What are you offering as mitigating that problem?
In the case of AOL you're probably right; they will, on account of their scale, probably want you to submit mail through them. But some domains might allow you to have your own key that is valid. And note the g= flag in the DNS record, which allows the domain to authorize a key only for a specific address.
If I have to sign it on my laptop with my personal key, that is entirely different (and much more difficult to manage) than DomainKeys.
It is indeed more difficult to manage. But I don't see anything in DomainKeys that says the signature couldn't be applied by your laptop, if you had the appropriate software and private key. So it's not different from DomainKeys.
Yes, but if it's not signed it will get dropped. That's the whole point. So it's not "drop them in the nearest mailbox" because it will look like spam--"From:" header doesn't match the signature--and get tossed.
Where does it say that unsigned mail will get dropped? That seems a long way off. But you're right, a signature for the wrong domain is more likely to be suspicious than a message that is just left unsigned.
Each user having a personal signature is a method, but it is much harder to manage. Yes, we can come up with a thousand other implementations to fill in the blanks, but that is not what was being proffered here; this discussion is about the DomainKeys implementation. So I'm confused how your response in any way mitigates the issues I presented.
Yes, per-user signatures are harder to manage, particularly if they are to be stored in the DNS, because they are more likely to require frequent changes than keys at the domain level. There are indeed other proposals out there; I'm the co-author of one of them.
Why not use the SMTP service for whomever your email address is through?
This is one of the advantages of using signatures; if you can sign the message (or get it signed by an authorized MTA) you don't need to submit through a specific MTA, which may be blocked from where you are.
What about users who travel?
This is handled by doing the signing on your laptop. DK (and similar schemes like IIM) are designed not to require changes on user PCs for the vanilla use cases, but they permit the user to sign if they're so equipped. So you would just sign the messages yourself, and "drop them in the nearest mailbox" (ISP).
The SpamAssassin headers shouldn't interfere with the signature because the DK signature includes a list of the headers that are included, and the SpamAssassin headers won't be there.
Your employer could check the signature and annotate the message prior to removing the.ZIP attachments. Hopefully you trust your employer's verification of the signature!
I assume you mean that your domain provider doesn't support SMTP...I don't see how it would have much to say about whether or not you use it.
One way this could be done is that if your ISP is signing, you could add their public key to your DNS zone and ask them to sign for your domain. Of course, this requires some faith on your part that your ISP's other customers won't (or can't) spoof your address.
A slightly better solution, if your ISP supports it, is to have a separate keypair for your domain, and give your ISP the private key so they can sign for you (hopefully, only after authenticating you using SMTP AUTH or something). Again, you would put the public key in your DNS zone.
I suspect that other services will spring up that you can use to sign mail.
It should work fine. Forwarding is one of the motivations for using a signature-based scheme like DomainKeys. However, it doesn't look like Gmail is verifying signatures yet -- I just sent them a message with a signature and I don't see anything in the headers saying the signature checked out (there is something like that for SPF).
There are actually several such proposals, and there was a Birds of a Feather session at the last IETF meeting to discuss them (since this approach is explicitly out-of-scope for the MARID WG.
Slashdot Mirror
Indeed. The objects shown in the illustrations aren't secret, and aren't unique. If you're calling the object "something you have" and the camera angle "something you know", anyone with the same watch (for example) satisfies the first of those.
"has a false accept rate of only 0.09%"
So that's about a 1/1000 false accept rate against a brute force attack, which is comparable to some biometrics. This actually isn't very good. A determined attacker will not just send random pictures, but will send pictures that they think the target of the attack may have used. This results on a much higher false accept rate.
Even 1/1000 is marginal enough that substantial rate limiting is going to be needed to keep the account secure. Compare that against the security of, say, a 6-digit random one-time password (1/1 million).
And as another commenter pointed out, it's not meaningful to talk about false accept rate without also talking about the false reject rate.
The headline "Raspberry Pi Goes On Sale In US, Sells Out" isn't specific to the model A.
I bought a Model B several months ago from Newark, and have two more in transit to me from them. But yes, stock is low; they were backordered a couple of weeks.
My Fedora 8 machine (kernel: 2.6.26.6-49.fc8) crashed around midnight UTC as well. Last syslog message was at 23:40:07 UTC so it may have not happened at exactly midnight; it would be unusual not to have something logged for 20 minutes. When I got to the machine, it was completely unresponsive; couldn't get it to do anything but reboot. The hardware has been very reliable and it's on a UPS.
I have seen a thread on linux.debian.user about this happening on Debian.
Before someone points it out, yes, I know that support for Fedora 8 goes away in a week or so.
DKIM is designed to not require individual devices such as PDAs to be modified; that's one of the benefits of signing at the domain level. But it does require the domain to support it, although with a Blackberry you may not have much choice in the matter.
Maybe if enough people ask nicely?
A couple of smallish corrections:
The SSP specification is under active development in the IETF DKIM Working Group. There is a much newer version of the spec here, but the spec is still evolving.
The public key is looked up using the "s" (selector) and "d" (domain) attributes of the signature. "c" specifies the canonicalization algorithm (used to deal with trivial modifications such as spacing to the body).
But generally, very good points...
Actually, DKIM permits MUAs to sign and verify messages, but we really expect the vast majority of DKIM signing and verifying to be done my MTAs, at the domain level. The ability to delegate keys to individual users is to handle those few cases where an individual user needs to sign a message, plus other outsourced functions (such as an enterprise's outsourced benefits provider) where a party outside the domain needs to be able to apply a signature. It's less of a leap of trust to do this when the key is constrained to a specific address.
Does this mean that if a hotel charges me $12.95 a day for "broadband", I can get my money back if I'm not getting 2 Mbps? I'm tired of paying for hotel "broadband" connections that are slower than dialup.
Of course, I tend to go to conferences with a lot of other Internet-hungry attendees, but hotels ought to be able to buy more bandwidth with what they're making on these charges.
You need to be a little careful with SPF -all; if you send to people who forward their mail (as from a college alumni address) and the address they forward to honors SPF, your messages could be rejected.
DKIM does solve much the same problem as SPF, but Sender Signing Practices (SSP), which gives guidance for recipients on dealing with unsigned mail, is still under development.
The biggest problem with the classic signature systems (e.g., PGP, S/MIME) is that they don't have quite the right key management model. Anyone can create a PGP key with any mail address they want, and sign messages. Similarly, anyone can get a certificate for an email address they have (perhaps an employer), but when they leave the company, does the certificate get revoked? No; the employer may not even know of its existence.
Signature schemes designed for this purpose, like DKIM, are actually a signature from the domain owner, not the author. While the domain owner may delegate a signing key to an individual in certain cases, they retain the ability to revoke the key at any time.
Maybe I'm missing something about DomainKeys, but if I'm using an "@aol.com" "From:" header, I need to send it through AOL's SMTP servers so that AOL can sign it; if I can't reach AOL's SMTP servers, I can't get it signed. It's that simple. Even if I can get it signed by the SMTP server of my ISP, that signature won't match my "From:" header so it fails the check on the user's end.
What are you offering as mitigating that problem?
In the case of AOL you're probably right; they will, on account of their scale, probably want you to submit mail through them. But some domains might allow you to have your own key that is valid. And note the g= flag in the DNS record, which allows the domain to authorize a key only for a specific address.
If I have to sign it on my laptop with my personal key, that is entirely different (and much more difficult to manage) than DomainKeys.
It is indeed more difficult to manage. But I don't see anything in DomainKeys that says the signature couldn't be applied by your laptop, if you had the appropriate software and private key. So it's not different from DomainKeys.
Yes, but if it's not signed it will get dropped. That's the whole point. So it's not "drop them in the nearest mailbox" because it will look like spam--"From:" header doesn't match the signature--and get tossed.
Where does it say that unsigned mail will get dropped? That seems a long way off. But you're right, a signature for the wrong domain is more likely to be suspicious than a message that is just left unsigned.
Each user having a personal signature is a method, but it is much harder to manage. Yes, we can come up with a thousand other implementations to fill in the blanks, but that is not what was being proffered here; this discussion is about the DomainKeys implementation. So I'm confused how your response in any way mitigates the issues I presented.
Yes, per-user signatures are harder to manage, particularly if they are to be stored in the DNS, because they are more likely to require frequent changes than keys at the domain level. There are indeed other proposals out there; I'm the co-author of one of them.
Why not use the SMTP service for whomever your email address is through?
This is one of the advantages of using signatures; if you can sign the message (or get it signed by an authorized MTA) you don't need to submit through a specific MTA, which may be blocked from where you are.
What about users who travel?
This is handled by doing the signing on your laptop. DK (and similar schemes like IIM) are designed not to require changes on user PCs for the vanilla use cases, but they permit the user to sign if they're so equipped. So you would just sign the messages yourself, and "drop them in the nearest mailbox" (ISP).
And to answer the other part of the question, yes, the signatures do verify.
On a couple of your specific points:
.ZIP attachments. Hopefully you trust your employer's verification of the signature!
The SpamAssassin headers shouldn't interfere with the signature because the DK signature includes a list of the headers that are included, and the SpamAssassin headers won't be there.
Your employer could check the signature and annotate the message prior to removing the
I assume you mean that your domain provider doesn't support SMTP...I don't see how it would have much to say about whether or not you use it.
One way this could be done is that if your ISP is signing, you could add their public key to your DNS zone and ask them to sign for your domain. Of course, this requires some faith on your part that your ISP's other customers won't (or can't) spoof your address.
A slightly better solution, if your ISP supports it, is to have a separate keypair for your domain, and give your ISP the private key so they can sign for you (hopefully, only after authenticating you using SMTP AUTH or something). Again, you would put the public key in your DNS zone.
I suspect that other services will spring up that you can use to sign mail.
It should work fine. Forwarding is one of the motivations for using a signature-based scheme like DomainKeys. However, it doesn't look like Gmail is verifying signatures yet -- I just sent them a message with a signature and I don't see anything in the headers saying the signature checked out (there is something like that for SPF).
There are actually several such proposals, and there was a Birds of a Feather session at the last IETF meeting to discuss them (since this approach is explicitly out-of-scope for the MARID WG.
s .htm
Draft minutes of the meeting are at http://www.ietf.org/proceedings/04aug/minutes/mas
Another report in The Mercury News says Kirsch is suing for $500 billion. One of his advisors said he had to be talked down to that amount.