On Tue, May 23, 2017 at 5:43 AM, Nico Williams <[email protected]> wrote:
> On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote: > > On Tue, May 23, 2017 at 5:17 AM, Nico Williams <[email protected]> > > 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)? > I don't understand the question. If you treat them as unknown then either your path construction code will route around them or once you try to verify, it will fail. > > 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. > I wouldn't have any trouble interpreting it that way. > 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. > I don't think "strongly authenticate" is useful here. I think the requirement is that the RP must not accept these algorithms in any context which would require validating signatures made using them. -Ekr 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
