> On May 22, 2017, at 10:50 AM, Nico Williams <n...@cryptonector.com> wrote: > >>> "When using TLS to authenticate the server, certificate signature >>> algorithms weaker than <list of weakest acceptable signature algs here> >>> MUST NOT be used." >> >> Minor correction, perhaps you really mean to say "when using RFC5280 (PKIX) >> to authenticate... (the [server or client?]). TLS is just the transport >> after all. > > No, I meant what I said, as in "as opposed to using TLS > opportunistically".
While we are quibbling over terminology and not substance: Note that opportunistically != unauthenticated. Opportunistic DANE TLS still authenticates when the peer has TLSA records, and even uses PKIX when the TLSA record certificate usage is DANE-TA(2). And sufficiently strong algorithms are desirable even under those conditions: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L955 So it seems the phrase "using TLS to authenticate" in fact means using RFC5280 (PKIX) to authenticate the peer via its signature over its Cerificate Verify message: https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.3 The phrase used to describe the situation in that section of the draft is "when authenticating via a certificate", which is part of the story, what would need to be added to that to get the right context for setting a floor on acceptable certificate signature algorithms is something along the lines of "with PKIX chain verification". Still, all of this belongs in an update of RFC5280, but if we just can't resist saying something here along the lines you suggest then it might be: "When peer authentication is via a certificate, with RFC5280 (PKIX) chain verification, certificate signature algorithms weaker than <list of weakest acceptable signature algs here> MUST NOT be trusted." I carefully say "MUST NOT be trusted" rather than "MUST NOT be used", it is the relying party that decides what minimal algorithm strength is acceptable. The peer may send whatever chain it has (lacking one that meets the advertised supported signature algorithms). Peers that desire broadly interoperable RFC5280 authentication via their certificate chain should of course be configured to present chains that avoid deprecated certificate signature algorithms (except in self-signatures of trust-anchors). -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
