On Mon, May 22, 2017 at 04:00:20PM -0500, Nico Williams wrote: > 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!
The code I have tries to route around (with equivalent to exhaustive search of all paths). And altough the code I have has the TLS and certificate code more tightly bound togethe than most libraries, the certificate validation algorithm handling is wholly inside the certificate handling part. The algorithm handling being inside certificate code is even true for SHA-1 signatures, which have nontrivial validity rules (only allowed for dedicated OCSP responders). The certificate code does not concern itself about TLS version it is running on. The exchange signature (which has differences between TLS versions) is direct signature validation and does not involve certificate code. BTW: Section 4.4.3. seemingly allows use of unadvertised exchange signature schemes if advertised one can't be used. This should be fixed: There is no way that can actually work (even pinning the server's key doesn't make that work, unlike say EE certificate being signed with something unknown). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
