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

[Eric Rescorla <[e-mail]>]

On Mon, May 15, 2017 at 12:38 PM, Russ Housley <[e-mail]> wrote:

> Just commenting on Section 4.2 …
>
> >
> > > 3. Section 4.2.
> > >
> > >    "In general, detailed certificate validation procedures are out of
> > >    scope for TLS (see [RFC5280]).  This section provides TLS-specific
> > >    requirements."
> > >
> > > I don't see an explanation of why it is out-of-scope.  The reference
> > > is just to RFC5280, which seems odd.  I would expect the reference to
> > > be to something that explains why it is out-of-scope.
>
> I think the the separation of certificate path validation from the TLS
> protocol is correct, but perhaps this can be explained differently.
> Perhaps the approach should be that TLS depends upon certificate path
> validation as described in RFC 5280.
>
> > In general, TLS's policy (dating back to TLS 1.0) has been that the
> > job of TLS is to carry the certificates and other authentication
> > material but to leave it up to other parts of the system to
> > interpret them. It's been a long time since that decision was made,
> > but from my perspective, there are a number of major reasons:
> >
> > 1. Most of PKI processing (path construction, etc.) is generic and
> >    not specific to TLS. What is specific to TLS is:
> >
> >    * How to indicate what your PKI capabilities are
> >      (see, e.g, S 4.2.4 and 4.3.2)
> >    * How to stuff the PKI material into the protocol
> >      (principally S 4.4.2)
> >    * How to determine whether a given certificate is suitable for
> >      use in TLS 4.4.4.2 and 4.3.2.1).
> >
> >    So we want to outsource the generic PKI part
> >
> >
> > 2. It matches the software architecture that people often use,
> >    which is to have a TLS stack but separate PKI validation. For
> >    instance, Firefox uses NSS for TLS but moz::pkix for
> >    validation. Similarly, Chrome uses BoringSSL for TLS
> >    but the system PKI libraries for validation.
> >
> >
> > In this case, I think that this text was more intended to
> > say "and go read 5280 to learn how to do this". To that end,
> > I suggest we say"
> >
> >
> >     "In general detailed certificate validation procedures are out of
> >     scope for TLS. [RFC5280] provides general procedures for
> >     certificate validation. This section provides TLS-specific
> >     requirements.”
>
> I agree with the reasoning, however the dependency on RFC 5280 should be
> called out in a MUST statement.  I suggest something like:
>
>     "TLS depends on certificate path validation, and a conformant
>     TLS implementation MUST implement certificate paths validation
>     in a manner that achieves the same result as [RFC5280]. This
>     section provides TLS-specific requirements.”
>
> Note that RFC 5280 is already a normative reference.
>

A MUST here would be a pretty material change to historical TLS practice.
As Viktor says, there are TLS-using applications that just don't validate
the cert via 5280 at all.

-Ekr


> Russ
>
>