Re: Yahoo releases internet standard draft for using DNS as public key server
Russell Nelson [EMAIL PROTECTED] writes:
Peter Gutmann writes:
STARTTLS
If Alice and Cathy both implement STARTTLS, and Beatty does not, and Beatty
handles email which is ultimately sent to Cathy, then STARTTLS accomplishes
nothing. If Uma and Wendy implement DomainKeys, and Violet does not, and
Violet handles email which is ultimately sent to Wendy, then Wendy can check
Uma's signature.
Since none of Uma, Wendy, or Violet implement DomainKeys or even know what
they are, DomainKeys accomplishes nothing. OTOH if their { ISP, company,
whatever } has STARTTLS enabled, they're getting their email encrypted without
even knowing about it and are having better-than-average security applied to
their POP/IMAP mail account, again without even knowing about it (I suspect
the latter is far more of a selling point to users than encryption. No-one
would want to read their mail anyway so they're not worried about that, but if
it stops those nasty hackers from breaking into their account, it's a good
thing).
If, instead, Perry had a list of PGP keys and email addresses, he wouldn't
*need* to compare the email address on the incoming email.
He'd instead need to spend even more time mucking around with keyrings and
updating keys and writing scripts to handle all the checking and wondering why
it all has to be so complicated, and maybe he should just ask people to fax in
submissions.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Peter Gutmann wrote: The S/MIME list debated this some time ago, and decided (pretty much unanimously) against it, for two reasosn. Firstly, because it adds huge ugly blobs of base64 crap to each message (and before the ECC fans leap in here, that still adds small ugly blobs of base64 crap to each message). Secondly, because if you get a message from someone you know you'll be able to get a pretty good idea of its authenticity from the content (for example an SSH developer would be unlikely to be advocating SSL in a list posting), and if you get a message from someone you don't know then it's pretty much irrelevant whether it's signed or not. So the consensus was not to sign messages. What you're saying is that based on only *two* bits of information (e.g., SSH=1 and SSL=0) for a given mail sender, the message could be authenticated well-enough to be useful in the operational context. I agree with this and that's why I think that conventional digital signatures with 1024-bit keys are an overkill for common email. If the ugly blob of base64 rubbish is small enough, it should be tolearable. The problem with asymmetric keys, though, is that faking short signatures is too trivial for current cryptosystems. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Dave Howe wrote: Peter Gutmann wrote: It *is* happening, only it's now called STARTTLS (and if certain vendors (Micromumblemumble) didn't make it such a pain to set up certs for their MTAs but simply generated self-signed certs on install and turned it on by default, it'd be happening even more). TLS for SMTP is a nice, efficient way to encrypt the channel. However, it offers little or no assurance that your mail will *stay* encrypted all the way to the recipients. That's correct. But, the goal is not to secure email to the extent that there is no risk, that's impossible, and arguing that the existence of a weakness means you shouldn't do it just means that we should never use crypto at all. See those slides that Adi Shamir put up, I collected the 3 useful ones in a recent blog: http://www.financialcryptography.com/mt/archives/000147.html I'd print these three out and post them on the wall, if I had a printer! The goal is to make it more difficult, within a tight budget. Using TLS for SMTP is free. Why not do it? (Well, it's free if self-signed certs are used. If CA-signed certs are used, I agree, that exceeds the likely benefit.) Most of us (including me most of the time) are in the position of using their ISPs or Employer's smarthost to relay email to its final destination; in fact, most employers (and many ISPs) actually enforce this, redirecting or blocking port 25 traffic. If my employer or isp accept TLS traffic from me, but then turn around and send that completely unprotected to my final recipient, I have no way of preventing or even knowing that. Sendmail's documentation certainly used to warn this was the case - probably still does :) a) Once a bunch of people send mail via TLS/SMTP, the ISP is incentivised to look at onward forwarding it that way. b) It may be that your local threat is the biggest, if for example you are using 802.11b to send your mail. The threat of listening from the ISP onwards is relatively small compared to what goes on closer to the end nodes. c) every node that starts protecting traffic this way helps - because it boxes the attacker into narrower and narrower attacks. It may be that the emails are totally open over the backbone, but who cares if the attacker can't easily get there? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Dave Howe wrote: Ian Grigg wrote: Dave Howe wrote: TLS for SMTP is a nice, efficient way to encrypt the channel. However, it offers little or no assurance that your mail will *stay* encrypted all the way to the recipients. That's correct. But, the goal is not to secure email to the extent that there is no risk, that's impossible, and arguing that the existence of a weakness means you shouldn't do it just means that we should never use crypto at all. No - it means you might want to consider a system that guarantees end-to-end encryption - not just first link, then maybe if it feels like it That doesn't mean TLS is worthless - on the contrary, it adds an additional layer of both user authentication and session encryption that are both beneficial - but that *relying* on it to protect your messages is overoptimistic at best, dangerous at worst. This I believe is a bad way to start looking at cryptography. There is no system that you can put in place that you can *rely* upon to protect your message. (Adi Shamir again: #1 there are no secure systems, ergo, it is not possible to rely on them, and to think about relying will take one down false paths.) In general terms, most ordinary users cannot rely on their platform to be secure. Even in specific terms, those of us running BSD systems on laptops that we have with us all the time still have to sleep and shower... There are people out there who have the technology to defeat my house alarm, install a custom key logger designed for my model of laptop, and get out before the hot water runs out. For that reason, I and just about everyone else do not *rely* on tech to keep my message safe. If I need to really rely on it, I do what Adolf Hitler did in November of 1944 - deliver all the orders for the great breakout by secure courier, because he suspected the enigma codes were being read. (He was right.) Otherwise, we adopt what military people call tactical security: strong enough to keep the message secure enough so that most of the time it does the job. The principle which needs to be hammered time and time again is that cryptography, like all other security systems, should be about risk and return - do what you can and put up with the things you can't. Applying the specifics to things like TLS and mail delivery - yes, it looks very ropey. Why for example people think that they need CA-signed certs for such a thing when (as you point out) the mail is probably totally unprotected for half the journey is just totally mysterious. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
At 10:14 PM 5/30/2004, Peter Gutmann wrote: The S/MIME list debated this some time ago, and decided (pretty much unanimously) against it, for two reasosn. Firstly, because it adds huge ugly blobs of base64 crap to each message (and before the ECC fans leap in here, that still adds small ugly blobs of base64 crap to each message). Secondly, because if you get a message from someone you know you'll be able to get a pretty good idea of its authenticity from the content (for example an SSH developer would be unlikely to be advocating SSL in a list posting), and if you get a message from someone you don't know then it's pretty much irrelevant whether it's signed or not. So the consensus was not to sign messages. this may or may not be my KISS authentication thread. mid-90s, some number of financial institutions retrenched from x.509 identity certificates to simple relying-party-only certificates ... because of enormous privacy issues regarding blanketing the world with privacy information contained in identity certificates. however, they were still looking at taking a 60-80 bytes payment message, attaching a 128byte digital signature, and then attaching a 4k byte to 12k byte relying-party-only certificate ... and sending it back to the financial institution that issued the certificate. this is not counting any ASN.1 encoding that might have been done which then possiby includes a bunch more bytes. note that standard payment message message has been around some 30 years carefully crafted as simple 7bit ascii w/o any addition encoding requirements. the purpose of the certificate was to carry the account number ... which was also included in the signed payment message ... and the public key ... which was stored in the account record back at the financial institution that was receiving the transmission and had originally issued the relying-party-only certificate. so the financial institution receives this new payment object, retrieves the account number from the (signed) payment message and uses the public key in the account record to verify the signature ... w/o ever resorting to the certificate. So we have a payload bloat of one hundred times ... in order to carry a certificate that is redundant and superfluous and never used. so x9.59 was fairly carefully crafted to add a 42byte ECC signature to a standard 60-80byte payment message. any special encoding to carry 42byte ecc 8bit in 7bit transmission at worst doubled the signature payload size. http://www.garlic.com/~lynn/index.html#x959 -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Ian Grigg wrote: Dave Howe wrote: No - it means you might want to consider a system that guarantees end-to-end encryption - not just first link, then maybe if it feels like it That doesn't mean TLS is worthless - on the contrary, it adds an additional layer of both user authentication and session encryption that are both beneficial - but that *relying* on it to protect your messages is overoptimistic at best, dangerous at worst. This I believe is a bad way to start looking at cryptography. There is no system that you can put in place that you can *rely* upon to protect your message. No, there are plenty that you can rely on to protect your message while still in transit. If you can ensure that the only possible points of vulnerability are at the two endpoints, then you and your correspondent take control of your security - it won't be perfect, as you point out - but you won't be reliant on the goodwill and efforts of some third party whose most economic option is to accidentally or deliberately neglect TLS between your local smart host and your correspondent's email spooler, or indeed, to supply minimal security to the email spools at smarthost or destination. (Adi Shamir again: #1 there are no secure systems, ergo, it is not possible to rely on them, and to think about relying will take one down false paths.) Secure systems exist - but are rarely worth the effort involved. Many PDAs can handle PGP or S/Mime traffic these days - certainly, you could offload your message (already encrypted) to flash media, insert into sending host, receive (from email spool) at the destination and transfer to flash media, then insert into decoding PDA. To compromise either PDA would require access - so if you keep it about your person (and within sight when you bathe), you should be safe against anything but a midnight intrusion with sleeping gas But regardless - the level of defence required is proportional to the likely threat. It is entirely possible that it would be worthwhile for some hacker to compromise a router between your ISP's mail server and your correspondent's spool, or that spool itself. It is less likely that it would be worth someone's while to break into your home with exquisite timing and tracelessly alter software on your trusted airgapped machine while you shower (and if that *is* your threat model, I envy the income you must get to justify being in such a position or bow to the value of your information to some repressive regime) Otherwise, we adopt what military people call tactical security: strong enough to keep the message secure enough so that most of the time it does the job. Indeed so. The principle which needs to be hammered time and time again is that cryptography, like all other security systems, should be about risk and return - do what you can and put up with the things you can't. Again, true. I suspect we differ in what we consider an acceptable risk - I don't consider any setup where the security of the channel is against the best interests of the people controlling that channel acceptable - especially where I have no way to discover if that channel was compromised. I have what I hope is an acceptably secure system at home - and I also hope my correspondents do likewise. If our messages are compromised (not that they contain anything worth stealing) then it is my fault or theirs - not an admin at the isp, or some minimum-wage employee on a helpdesk bribed to let someone take a peak at my mailspool. This extra security comes free, gratis, not a penny does it cost - beyond the effort of learning how to use it - and while I was used to hotkeying my way into the current window, my recent switch to Enigmail means I don't even have to do that. Why would I settle for less? Applying the specifics to things like TLS and mail delivery - yes, it looks very ropey. Why for example people think that they need CA-signed certs for such a thing when (as you point out) the mail is probably totally unprotected for half the journey is just totally mysterious. And indeed I had a conversation with someone who was interested in a secure mailing list only a few days ago. I suggested he not bother and just set up a HTTPS website with any one of a dozen BBoard systems and local certificate support - because that was free and all the complexity (and most of the vulnerabilites) are at the server side - while setting up a secure email burster would be almost impossible and would rely on not only training the end users, but ensuring they have the right software installed. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Russell Nelson [EMAIL PROTECTED] writes: It would be better if the solution does NOT need industry support at all, only user support. It should use what is already available. This is the point in the script at which I laugh at you, Ed. S/MIME and PGP have been available for many many years now. How many messages to the Cryptography Mailing List are cryptographically signed? If it was going to happen, it would have *already* happened. It *is* happening, only it's now called STARTTLS (and if certain vendors (Micromumblemumble) didn't make it such a pain to set up certs for their MTAs but simply generated self-signed certs on install and turned it on by default, it'd be happening even more). How many messages to the Cryptography Mailing List are cryptographically signed? The S/MIME list debated this some time ago, and decided (pretty much unanimously) against it, for two reasosn. Firstly, because it adds huge ugly blobs of base64 crap to each message (and before the ECC fans leap in here, that still adds small ugly blobs of base64 crap to each message). Secondly, because if you get a message from someone you know you'll be able to get a pretty good idea of its authenticity from the content (for example an SSH developer would be unlikely to be advocating SSL in a list posting), and if you get a message from someone you don't know then it's pretty much irrelevant whether it's signed or not. So the consensus was not to sign messages. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
On Thu, May 20, 2004 at 10:07:43AM -0400, R. A. Hettinga wrote: yahoo draft internet standard for using DNS as a public key server http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt The main problem with this approach is revealed in a mind slip by Yahoo themselves at http://antispam.yahoo.com/domainkeys : For consumers, such as Yahoo! Mail users or a grandmother accessing email through a small mid-western ISP, industry support for sender authentication technologies will mean that they can start trusting email again It's industry support. We know what it means: multiple, conflicting approaches, slow, fragmented adoption -- will not work. It would be better if the solution does NOT need industry support at all, only user support. It should use what is already available. Cheers--/Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
On Thu, May 20, 2004 at 10:07:43AM -0400, R. A. Hettinga wrote: [...] yahoo draft internet standard for using DNS as a public key server http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt This sounds quite a lot like the ideas outlined in a paper I co-authored in 1995, proposing the idea of a trustmaster for each domain, keyed to the DNA hierarchy. http://www.hedge.net/fields/projects/trust/trust.pdf http://www.hedge.net/fields/projects/trust/trustfig.pdf -- - Adam - http://www.adamfields.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
