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

This document has WGLC and so has a presumption of consensus. If you want
to re-raise that, this is a process question which is the province of the
chairs, so if you feel strongly, as it appears you do, I would encourage
you raise it with them.

-Ekr

On Tue, May 23, 2017 at 6:02 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

>
> > On May 22, 2017, at 3:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > Well, I certainly think past the Web PKI, because one of the cases I
> care about
> > is WebRTC, which doesn't do any PKI validation at all.
> >
> > 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.
>
> The operative word here is *was*.  Time has passed, and things have
> changed:
>
>         1.  The motivating problem (broad use of weak hashes in Web PKI
>             certificates) has become a non-problem.  The CAs and the
> browsers
>             have moved on.
>
>         2.  We've since had many discussions that make it clearer still
> that
>             layer violation into RFC5280 space is suboptimal.
>
>         3.  While did not object strongly at the time, I've since seen
> that the
>             language in question temps TLS stack authors to implement
> checks against
>             the specific certificate algorithms at the TLS layer, instead
> of at the
>             X509 verification layer where X509 security checks belong.
>
> Surely there are some old GOST signature algorithms that could appear in
> certificates,
> that TLS 1.3 does not prohibit, but which are not much stronger than
> SHA-1, and if not
> GOST then something else.  Plucking out the specific code-points in
> question is both
> insufficient and counter-productive.
>
> It is time to revisit the previous consensus, because its motivation is no
> longer
> relevant, and its negative consequences are more apparent.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>