Viktor, I was just getting to your email :) Thanks for pointing out https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 - something like this seems quite useful in codifying the expectation of STARTTLS support for SMTP (or other protocols) given that a TLSA record exists.
I'm not sure that I agree with everything in that draft, particularly the bit about not using certificate usage 0/1, as this is precisely what we would do for Gmail most likely (we operate our own CA, and for instance in Chrome and via http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we typically pin google.com to a set of CA certificates, not leaf certificates, as the leaf certificates can rotate more frequently based on operational needs but our CA cert changes much more rarely.) It's not clear to me why requiring PKIX validation in that case would be an unreasonable expectation. Indeed, most of the certs I see from a random inspection of servers offering STARTTLS (google, t-online, web.de etc) include a full certificate chain to a public CA. Other than that nit though, I would love to see that draft advance. -Ian On Tue, Sep 3, 2013 at 9:02 PM, Viktor Dukhovni <[email protected]>wrote: > On Tue, Sep 03, 2013 at 08:59:24PM -0700, Ian Fette (????????) wrote: > > > " The STARTTLS client then expects to see STARTTLS in the > > EHLO response if it has a TLSA RRset." - this wasn't clear from my > reading > > of the RFC. Where is that specified, or well understood? If that's a safe > > assumption, that certainly simplifies things, but this was not clear from > > my (admittedly hurried) reading of the RFC. > > See my earlier reply. > > Downgrade-resistant opportunistic TLS is out of scope for RFC 6698, > this subject will be covered in various application-specific documents > that specify how DANE is to be used for the protocol in question. > > -- > Viktor. > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
