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

[Nico Williams <[e-mail]>]

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)?

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

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

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