On 20/04/15 22:03, Viktor Dukhovni wrote: > On Mon, Apr 20, 2015 at 08:36:39PM +0100, Stephen Farrell wrote: > >>> Can we move forward with s/SSL 3.0/TLS 1.0/g? This modifies just >>> the first paragraph of 8.1 and is not a big deal. >>> >>> I don't recall seeing any other recent BCPs at issue in this thread. >> >> One could encourage adhering to the generic UTA BCP though >> as well right? > > There is AFAIK no UTA BCP for opportunistic TLS.
Agreed. > > Even though once usable TLSA records are found (DANE) authenticated > TLS becomes mandatory, the client is (a-priori) opportunistic and > was willing to send cleartext. > > The client is honouring the server's preference for authenticated > TLS, but should not be unduly strict with respect to the server's > TLS protocol capabilities, which are not advertised as part of the > TLSA records which the client uses to "commit" to using TLS. > > Opportunistic DANE TLS will be disabled by users if it enforces Did I mention "enforcing"? If so that wasn't what I meant. But in any case, the UTA BCP is designed not to require things that aren't commonly available. > TLS settings with which more a negligible fraction of servers cannot > comply. This protocol needs to have conservatively low expectations > of server TLS capabilities. What that means will vary over time. > > What Postfix does when TLS is mandatory is to disable low-grade > ciphersuites and obsolete TLS protocol versions. > > http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers > http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols > > Are you looking for something that elaborates on the text below > from Section 3 of RFC 7435? > > With unauthenticated, encrypted communication, OS protocols may > employ more liberal settings than would be best practice when > security is mandated by policy. Some legacy systems support > encryption, but implement only outdated algorithms or protocol > versions. Compatibility with these systems avoids the need to resort > to cleartext fallback. > > For greater assurance of channel security, an OS protocol may enforce > more stringent cryptographic parameters when the session is > authenticated. For example, the set of enabled Transport Layer > Security (TLS) [RFC5246] cipher suites might exclude deprecated > algorithms that would be tolerated with unauthenticated, encrypted > communication. No, not that I think. > > In particular the second quoted paragraph hints at the possibility > of being a bit more strict when authentication is mandatory and > active attack protection is expected. > > What specifically in the UTA BCP should be referenced in this draft? How about: "BCPxxx [draft-ietf-uta-tls-bcp] documents current best practice recommendations for TLS, e.g. which ciphersuites are best to adopt etc. Implementations and deployments are encouraged to adopt those practices." Cheers, S. > > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
