[Top] [All Lists]

Re: [ietf-smtp] certificate pinning

2014-06-13 18:13:03
On Sat, Jun 7, 2014 at 10:35 PM, Peter Bowen <pzbowen(_at_)gmail(_dot_)com> 

On Fri, Jun 6, 2014 at 4:12 PM, Brandon Long <blong(_at_)google(_dot_)com> 
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 ( to

I realize there's also DANE TLSA (RFC 6698), but that has a requirement
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-PKP PIN-SHA256=d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=
S: 250-PKP PIN-SHA256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=
S: 250-PKP MAX-AGE=259200

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.

ietf-smtp mailing list