On Sat, Jun 7, 2014 at 10:35 PM, Peter Bowen <pzbowen(_at_)gmail(_dot_)com>
wrote:
On Fri, Jun 6, 2014 at 4:12 PM, Brandon Long <blong(_at_)google(_dot_)com>
wrote:
Now that more servers are offering STARTTLS, it would seem beneficial to
move forward towards certificate validation.
How do people feel about bringing the concept of certificate pinning from
HTTP (http://tools.ietf.org/html/draft-ietf-websec-key-pinning-13) to
SMTP?
I realize there's also DANE TLSA (RFC 6698), but that has a requirement
on
DNSSEC that may limit its deployment for some time to come.
translating the syntax in the http draft to smtp ehlo, I would imagine
something like (on a second EHLO after the TLS session is started):
C: EHLO foo
S: 250-SIZE 35882577
S: 250-8BITMIME
S: 250-PKP PIN-SHA256=d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=
S: 250-PKP PIN-SHA256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=
S: 250-PKP MAX-AGE=259200
S: 250-ENHANCEDSTATUSCODES
S: 250 CHUNKING
What about bringing HSTS to SMTP as well?
S: 250-STSEC MAX-AGE=31536000
This would indicate that connections must use STARTTLS for future
connections. Ideally, this would allow a client to directly issue
STARTTLS on connect, rather than EHLO (a protocol violation today),
reducing the amount of unencrypted data on the connection and speeding
up the connection sequence.
I don't have a strong opinion either way on that. My original take was
that HSTS was important to HTTP since the whole request is sent unencrypted
immediately (including cookies, potentially), where-as with SMTP, their is
a negotiation prior to anything but the ehlo itself.
This is also why Gmail only offers imap/pop over ssl-wrapped connections,
less chance of clients mistakenly sending passwords in the clear (even if
the server ignores them since they haven't invoked STARTTLS).
Unfortunately, we didn't have a choice with smtp-msa as some clients
didn't support ssl-wrapped connections.
If there is sufficient interest in removing the extra round-trip or hiding
the original ehlo, I'm certainly not opposed to it, though.
Brandon
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp