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

Russ Housley <housley@vigilsec.com> Mon, 15 May 2017 19:41 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1F2129AF9 for <tls@ietfa.amsl.com>; Mon, 15 May 2017 12:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQcgjTSS0JXj for <tls@ietfa.amsl.com>; Mon, 15 May 2017 12:41:45 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CD012EAA1 for <tls@ietf.org>; Mon, 15 May 2017 12:38:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 42367300581 for <tls@ietf.org>; Mon, 15 May 2017 15:38:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CZtYQHRxf6Ms for <tls@ietf.org>; Mon, 15 May 2017 15:38:40 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 678F030056B; Mon, 15 May 2017 15:38:40 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CABcZeBMMQ8kNWUA4Y6ssMw7h54fPbBxrLbgZtxSkYc7-fzypSA@mail.gmail.com>
Date: Mon, 15 May 2017 15:38:43 -0400
Cc: IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com>
References: <CAHbuEH4PXU5569RYJ1uPcriQruCewmRrXUU3MVBZ+GtpyceiAw@mail.gmail.com> <CABcZeBMMQ8kNWUA4Y6ssMw7h54fPbBxrLbgZtxSkYc7-fzypSA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/a1m7ZfgGA3hyXqtv8a9FUso9xUc>
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 May 2017 19:41:47 -0000

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.

Russ