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

[Russ Housley <[e-mail]>]

> On May 16, 2017, at 11:23 AM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Tue, May 16, 2017 at 8:17 AM, Russ Housley <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> On May 15, 2017, at 7:01 PM, Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> 
>> On Mon, May 15, 2017 at 12:38 PM, Russ Housley <[e-mail] <mailto:[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.
> 
> I think we want to say that if the certificates are used, then the certification path MUST be validated in a manner that is compatible with Internet X.509 certificate profile [RFC5280]; however, other approaches to validation of the public key, such as the DANE TLSA resource record [RFC6698], are also acceptable.
> 
> I can see how you would want to say that, but it's not really consistent either
> with historical practice or with the way that other standards track RFCs use TLS
> with certificates (see RFC 5763).

Actually, that is a great example.  I accept the need for loose coupling.

Russ