[Cryptography] ISPs caught in STARTTLS downgrade attacks

Jerry Leichter leichter at lrw.com
Fri Nov 14 18:01:47 EST 2014

On Nov 14, 2014, at 12:24 AM, Viktor Dukhovni <cryptography at dukhovni.org> wrote:
> ...I think very few people would likely want to use end-to-end encrypted
> mail, even if all the key-management usability issues were addressed
> and it became easy to send encrypted mail and read a given encrypted
> message.  Subtantial problems remain:
> ...
>    * No server-side search.
A minor point, but telling:  I have yet to see a server-side search that performs as well, not to mention as flexibly, as search in Mail.app on my Mac, which is done entirely locally on my laptop - and was extremely fast, even against very large mailboxes, on Mac's several generations back.

(Before I started using Mail.app, I used pine for many years.  It had great mechanisms for selecting messages based on various attributes - mechanisms that remain unmatched in any other mailer I've used - but it didn't do a particularly good job on search.  I used to keep copies of all my mail locally and build a GLIMPSE index over it every night so that I could search it quickly.)

SMTP works reasonably well for what it is, but many of its promises - like decent server-side search - remain unfulfilled.  Quality of implementation reigns, and few implementations care - the "minimal acceptable level" for a mail server was established years ago, and everyone has stuck there.  (gMail strikes out in some new directions, but has its own costs to go with its benefits.)

Returning to the other points you raised:  Actually, many of them concern *encrypted mail at rest*, not STARTTLS.  Server search - if it's worth having - would be completely unaffected by STARTTLS.  About the only service that's (sometimes) implement "within the network" - that is, the only service that encrypted connections would break - is spam and malware detection.  And there are alternative architectures even there, and strong arguments for why such services belong at the endpoints, not in the network itself.  (End-to-end arguments and all.)  And, yes, some find these added services valuable.  If they want to opt in by *not* encrypting their connections, I have no problem.

Look, as discussed on this list previously, STARTTLS even if universally deployed is not much of a security solution, depending as it does on insecure MX (not to mention other issues).  So in that sense, this is a tempest in a teapot.  But on the broader scale, the general question of network service providers forcing you to take services you don't want - and which in fact you might object to - is an important one.  STARTTLS today, SSL and VPN's tomorrow.  After all, many of the arguments for in-network services for mail - like malware screening - apply equally (in fact more strongly) to Web sites, downloads, etc.
                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141114/2e47e4da/attachment.bin>

More information about the cryptography mailing list