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
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
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
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. In limited circumstances it could well be enough - say, if your mailserver *is* yours, and hands off directly to the recipient's mail server which you know is accessed by either ssl-secured pop3, https, or some other secure access method (or unencrypted, but via a local lan link of course) - but for the majority of users this isn't going to be possible; more and more ISPs frown on even their business customers using direct outbound SMTP, and few sites are willing or able to accept mail using the alternate port for TLS. The goal is to make it more difficult, within a tight budget. Using TLS for SMTP is free. Why not do it? You should do it - but you shouldn't expect it to do any good; in the long term, pushing for TLS support from your ISP, giving them grief (within limits of course) to ensure opportunistic TLS outbound, and so forth, will increase the security of the system as a whole. but at the moment reliance is a step too far. a) Once a bunch of people send mail via TLS/SMTP, the ISP is incentivised to look at onward forwarding it that way. Many ISPs accept TLS inbound, but don't specify it outbound. there is no value to them in doing so - its transparent to the user either way, adds additional load to the local server, and the occasions they get asked about it are so rare they can safely ignore it. 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. Certainly possible - but of course that implies using SSL during the collection too. 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? Indeed so, yes. however, as I say - just because it is a step forward towards a completely end-to-end secure link, it is worth doing - even a little extra security for free is worth having - but if it is important enough to *need* encryption, it is important enough to ensure end-to-end encryption is used. I must admit to being impressed by how functional EnigMime for thunderbird is in this regard - I can specify per-destination-user that encryption will aways be used, and its type - and have it "just work" - 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
I see that you are not interested in discussing the relative merits of
STARTTLS vs. DomainKeys, but instead are just trying to push
STARTTLS. I hope that Perry will see through your sales job, and will
return your email to you, just as he will return this one to me.
-russ
[Moderator's note: No such luck for you I'm afraid. However, I'd
prefer if both of you tried to stay away from being personal. --Perry]
Peter Gutmann writes:
> 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
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. 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 :) 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. Agreed. In cases of spoofing, there could of course be an issue - but lets be honest here; when was the last time a mailing list regular *anywhere* lost reputation because someone posted spam or trollishness to the list in their name? I am not saying that doesn't happen - but it is rare, and usually the real poster points out the difference in header data that would indicate that email came from a source other than him. - 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
Ed Gerck wrote: No -- DomainKeys has nothingf to do with 'email cryptography'. They are S/MIME and PGP/MIME. I wouldn't say PGP/MIME (as opposed to pgp inline) was a widely enough used standard to be considered one of two options - pgp (both methods) certainly, but not pgp/mime exclusively. - 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:
>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 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. > [ S/MIME uses huge ugly blogs of base64 crap, and context is > sufficient for authentication. ] So the consensus was not to sign > messages. Before I could send the previous email, I had to tell Perry to accept email from my outgoing email address because I'm subscribed to the list under a list-specific email address. 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 could just verify the key. Then, he could discard the signature, since everybody has [EMAIL PROTECTED] whitelisted anyway, right? -- --My blog is at angry-economist.russnelson.com | Crynwr sells support for free software | PGPok | Bugs of a feather 521 Pleasant Valley Rd. | +1 315 268 1925 voice | flock together. Potsdam, NY 13676-3213 | FWD# 404529 via VOIP | - 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
Russell Nelson wrote: > also sprach Ed Gerck <[EMAIL PROTECTED]> [2004.05.28.1853 +0200]: > > It's "industry support". We know what it means: multiple, > > conflicting approaches, slow, fragmented adoption --> will not > > work. In other words change. If you have any alternatives to change, please describe them. Ollivander's wand shop is not available in this universe. The alternative to change (ie, replacement) is complement. I mentioned that. > > 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. I laugh with you ;-) 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. S/MIME and PGP did NOT earn user support. What's wrong with them, we all know and Martin exemplifies below: martin f krafft writes: > - The technology is too complex to be grasped. users may be able > to select encryption in their GUI, but they fail to understand > the consequences. This is especially problematic on the receiver > side, because no standard user knows how to handle a BAD > SIGNATURE alert. Yup. That's why I think that the MTA that checks the signature should surround the RFC2822 address comment with '?' if the signature is missing or bad. If the email lacks a valid signature, you really *don't* know who it's from, so the question marks are simply telling the truth. That's cute but your suggestion may have missed the point. If the email lacks a valid signature, there may be many causes. Today, within CA cert rollover dates, your browser's root certs may just need an update. Absence of a valid signature simply means you have less evidence of whom it's from, not no evidence. > - The infrastructure is not there. Two standards compete for email > cryptography, and both need an infrastructure to back them up. Two standards? DomainKeys and what else? No -- DomainKeys has nothingf to do with 'email cryptography'. They are S/MIME and PGP/MIME. EG - 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
also sprach Russell Nelson <[EMAIL PROTECTED]> [2004.05.30.0515 +0200]: > > - The infrastructure is not there. Two standards compete for > > email cryptography, and both need an infrastructure to back > > them up. > > Two standards? DomainKeys and what else? I meant PGP and S/MIME But there's DomainKeys and CAs I guess... including those CAs inserted into web of trusts. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! "... alle sätze der logik sagen aber dasselbe. nämlich nichts." -- wittgenstein signature.asc Description: Digital signature
Re: Yahoo releases internet standard draft for using DNS as public key server
> also sprach Ed Gerck <[EMAIL PROTECTED]> [2004.05.28.1853 +0200]: > > It's "industry support". We know what it means: multiple, > > conflicting approaches, slow, fragmented adoption --> will not > > work. In other words change. If you have any alternatives to change, please describe them. Ollivander's wand shop is not available in this universe. > > 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. martin f krafft writes: > - The technology is too complex to be grasped. users may be able > to select encryption in their GUI, but they fail to understand > the consequences. This is especially problematic on the receiver > side, because no standard user knows how to handle a BAD > SIGNATURE alert. Yup. That's why I think that the MTA that checks the signature should surround the RFC2822 address comment with '?' if the signature is missing or bad. If the email lacks a valid signature, you really *don't* know who it's from, so the question marks are simply telling the truth. > - The infrastructure is not there. Two standards compete for email > cryptography, and both need an infrastructure to back them up. Two standards? DomainKeys and what else? -- --My blog is at angry-economist.russnelson.com | Crynwr sells support for free software | PGPok | Bugs of a feather 521 Pleasant Valley Rd. | +1 315 268 1925 voice | flock together. Potsdam, NY 13676-3213 | FWD# 404529 via VOIP | - 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
also sprach Ed Gerck <[EMAIL PROTECTED]> [2004.05.28.1853 +0200]: > 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. While I fundamentally agree, a user-side approach will not work for two reasons, at least: - The technology is too complex to be grasped. users may be able to select encryption in their GUI, but they fail to understand the consequences. This is especially problematic on the receiver side, because no standard user knows how to handle a BAD SIGNATURE alert. - The infrastructure is not there. Two standards compete for email cryptography, and both need an infrastructure to back them up. Unless the governments do not settle on one standard and provide the necessary infrastructure, such as signing keycards or pocket devices capable of stream en/decryption, encryption is not going to be standard. If everyone and their mother is supposed to use cryptography, then the two points need to be addressed. And unless everyone (and their mother) uses cryptography consistently, email is not going to be safe. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! the unix philosophy basically involves giving you enough rope to hang yourself. and then some more, just to be sure. signature.asc Description: Digital signature
Re: Yahoo releases internet standard draft for using DNS as public key server
On Fri, May 28, 2004 at 03:20:52PM -0400, [EMAIL PROTECTED] wrote: [...] > How soon will the spammers get into the business of hosting free mailboxes > for people who actually buy spamvertized products. Much easier to send the > spam to their own users, let them indicate their preferences, set up > forwarded notifications, ... Er, doesn't this describe Gmail? > What things brings us to is that a major part of the problem are of course > the people who buy the spamvertized products. So long as there is a new > sucker born every minute, there will also be someone ready to take > advantage of same. Yeah... I'm curious about who these suckers actually are. I've never heard of anyone buying any spam crap except journalists researching whether or not you can actually buy spam crap. Does >anyone< personally know someone who's bought something from a spammer, for real? > Can spam be solved through end-user education? "Do not buy spammed > products" campaign signs right next to the public health signs against > smoking? "How to not be this minute's sucker" education in schools? :-) Put that sign right next to the Snapple machine. > Is spam really that important a societal ill, if the spammers had better > parenting, schooling and better career prospects would they still spam or > litter the sidewalk? Are human societies free of spam and more serious > ills possible or even desirable (what is the cost of eliminating the > ills)? > > We get too carried away with spam, as threats to our way of life there are > far more serious problems... -- - Adam - http://www.adamfields.com - 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 Fri, 28 May 2004, Ed Gerck wrote: > 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. And indeed some will view the various sender authentication proposals as misguided solutions for the wrong problems, while others will be simply disinclined to spend money to upgrade their working "just fine" MTAs so these will by no means be universally adopted. The spammers will increase the cost of receiving a clean mail stream, but if that increase is not too high and the filter accuracy is high enough, email will continue to work just fine. The bargain basement email providers may be disinclined to pay more to provide a commodity service where the competition often offers the service at no cost. There may in the future be a larger market for premium email services, with a second market for low to zero cost mailboxes subjected to a kinder, gentler spam stream (likely from the email provider). How soon will the spammers get into the business of hosting free mailboxes for people who actually buy spamvertized products. Much easier to send the spam to their own users, let them indicate their preferences, set up forwarded notifications, ... What things brings us to is that a major part of the problem are of course the people who buy the spamvertized products. So long as there is a new sucker born every minute, there will also be someone ready to take advantage of same. Can spam be solved through end-user education? "Do not buy spammed products" campaign signs right next to the public health signs against smoking? "How to not be this minute's sucker" education in schools? :-) Is spam really that important a societal ill, if the spammers had better parenting, schooling and better career prospects would they still spam or litter the sidewalk? Are human societies free of spam and more serious ills possible or even desirable (what is the cost of eliminating the ills)? We get too carried away with spam, as threats to our way of life there are far more serious problems... -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - 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
thats pretty much DNSSEC, now eleven years old. or - presuming DNS is fine w/o integrity checks, one should look at the rational for the creation of the CERT (x509) resource record back in 1999 and documented in RFC 2538. > > > > yahoo draft internet standard for using DNS as a public key server > http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt > misc past news refs: > http://docs.yahoo.com/docs/pr/release1143.html > http://blogs.ittoolbox.com/linux/technologist/archives/000241.asp > http://www.computerweekly.com/Article127082.htm > http://zdnet.com.com/2100-1104_2-5164279.html > http://www.ecommercetimes.com/perl/story/32995.html > - 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]
Yahoo releases internet standard draft for using DNS as public key server
--- begin forwarded text Date: Wed, 19 May 2004 21:26:31 -0600 From: [EMAIL PROTECTED] Subject: Yahoo releases internet standard draft for using DNS as public key server To: [EMAIL PROTECTED] List-Post: <mailto:[EMAIL PROTECTED]> List-Subscribe: <http://ls.fstc.org/subscribe>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://ls.fstc.org/archives/internet-payments/> List-Help: <http://ls.fstc.org/elists/admin.shtml>, <mailto:[EMAIL PROTECTED]> List-Id: yahoo draft internet standard for using DNS as a public key server http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt misc past news refs: http://docs.yahoo.com/docs/pr/release1143.html http://blogs.ittoolbox.com/linux/technologist/archives/000241.asp http://www.computerweekly.com/Article127082.htm http://zdnet.com.com/2100-1104_2-5164279.html http://www.ecommercetimes.com/perl/story/32995.html a few past threads on using DNS as a public key server http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aepay4.htm#comcert2 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert4 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki12 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?) http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda) http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf? http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ? http://www.garlic.com/~lynn/2001c.html#8 Server authentication http://www.garlic.com/~lynn/2001c.html#9 Server authentication http://www.garlic.com/~lynn/2001d.html#36 solicit advice on purchase of digital certificate http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate http://www.garlic.com/~lynn/2001e.html#26 Can I create my own SSL key? http://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key? http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key? http://www.garlic.com/~lynn/2001g.html#2 Root certificates http://www.garlic.com/~lynn/2001g.html#19 Root certificates http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me http://www.garlic.com/~lynn/2001n.html#57 Certificate Authentication Issues in IE and Verisign http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification http://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#51 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#53 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new) -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm --- end forwarded text -- - R. A. Hettinga The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
