Re: [TLS] AD Review of draft-ietf-tls-tls13

[Ilari Liusvaara <[e-mail]>]

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 <[e-mail]>
> > 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 <[e-mail]>
> > > > 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