On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote: > On Tue, May 23, 2017 at 5:43 AM, Nico Williams <n...@cryptonector.com> > 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 <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)? > > > > 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.
That *really* seems like a layer violation! > > > 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. Why not be clear? > > > 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. Well, I want it to be crystal clear that the "not MD5 and such" requirement need not apply to opportunistic TLS usage. If you don't like my text, maybe you can propose your own. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
