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

[Eric Rescorla <[e-mail]>]

On Tue, May 23, 2017 at 6:00 AM, Nico Williams <[e-mail]>
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!
>

As I said, I don't have a problem with it. It's TLS giving instructions to
the PKI subsystem.


> >    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.


I don't think "opportunistic" is a clearly enough defined category to be
useful
here. Rather, I think the relevant criterion is the one I listed above. If
people
agree, I'd be happy to make that change (and can produce text) because I
think it conforms to the WG consensus.

-Ekr