Yahoo releases internet standard draft for using DNS as public key server

Dave Howe DaveHowe at gmx.co.uk
Tue Jun 1 13:29:20 EDT 2004


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 majordomo at metzdowd.com



More information about the cryptography mailing list