On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote: > On Tue, May 23, 2017 at 5:17 AM, Nico Williams <n...@cryptonector.com> > wrote: > > > In any case, I think there are two issues: > > > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1. > > > 2. Require a specific failure if the peer presents such a certificate. > > > > > > There was pretty strong consensus to do #1 and I don't support removing > > > it. That seems like a pretty modest layering violation. If people think > > that > > > the mandate for this specific alert is too onerous, I could live with > > > removing > > > that. > > > > I don't understand how you can have (1) and not (2). > > As Ilari suggests, you could just treat the algorithms as unknown.
How does that square with (1)? > > Instead of altogether forbidding certs with MD5 signatures, forbid them > > when the application expects TLS to authenticate the server [with PKIX, > > as opposed to certain DANE usage values, or with pre-shared certs, > > etc.]. I.e., a server authentication security level knob is needed. > > I don't think that the current text prohibits that, because of : That takes care of DANE and pre-shared cert uses, but not of opportunistic use. And maybe not of TOFU either: since on first use the server's cert won't be known to the client, it's not a "trust anchor" yet and cannot fall under this safe-harbor. > The signatures on certificates that are self-signed or certificates > that are trust anchors are not validated since they begin a > certification path (see [RFC5280], Section 3.2). A certificate that > begins a certification path MAY use a signature algorithm that is not > advertised as being supported in the "signature_algorithms" > extension. > > In this case, I think one can argue are treating this as a trust > anchor. Feel free to propose new text that you think makes that > clearer. Proposal: Clients SHOULD/MUST NOT accept server certificates, or certificate validation paths, where the server certificate or intermediate certificates (but not trust anchors) are signed with "weak" signature algorithms, unless the client is not expecting TLS to strongly authenticate the server (e.g., for opportunistic use) or where the client has previously learned and cached the server's certificate. A "weak" signature algorithm is any of <list1>, or any that isn't on <list2> and was introduced prior to publication date of this document. The last is a way to eliminate any old hash. List some of them in <list1>, list all the allowable ones that we know about today in <list2>, and the publication date will take care of any that should have been on <list1> but was not listed in it, while future-proofing <list2>. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
