IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 16 May 2017 16:43 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 BB422128B51 for <tls@ietfa.amsl.com>; Tue, 16 May 2017 09:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 B3p4oHwFi2wx for <tls@ietfa.amsl.com>; Tue, 16 May 2017 09:43:58 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9758128768 for <tls@ietf.org>; Tue, 16 May 2017 09:37:44 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 6E66D7A32F1 for <tls@ietf.org>; Tue, 16 May 2017 16:37:43 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAHbuEH7djXnZv-SvOFyLxTb6UWCKj8Hn0ZMS3ccgvviuPuPFKQ@mail.gmail.com>
Date: Tue, 16 May 2017 12:37:42 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <854FCD7A-B4C7-4E7A-A45E-7EECAA5E856C@dukhovni.org>
References: <CAHbuEH4PXU5569RYJ1uPcriQruCewmRrXUU3MVBZ+GtpyceiAw@mail.gmail.com> <CABcZeBMMQ8kNWUA4Y6ssMw7h54fPbBxrLbgZtxSkYc7-fzypSA@mail.gmail.com> <9C0E15E5-E852-47E0-B9A6-F807034ECFB8@vigilsec.com> <CABcZeBPGK9BguF6OJo=QT3Sx1mLwBQJhh4JiBkAmws5umvctSg@mail.gmail.com> <0ED5F216-365D-432E-B390-D95014ED5676@vigilsec.com> <CABcZeBPnLSbNySpRoGd8gQNBDf9jAEzX8eG6WC96MTmoqdpJHA@mail.gmail.com> <45BECF9F-0BBD-4E2D-B517-77709C0EAC9F@vigilsec.com> <CAHbuEH7djXnZv-SvOFyLxTb6UWCKj8Hn0ZMS3ccgvviuPuPFKQ@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qgBtcvCI4tAWecylTCQaACEYpn8>
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: Tue, 16 May 2017 16:44:00 -0000

> On May 16, 2017, at 11:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
> 
> OK, does that put us back to the suggested wording:
> 
>    "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.”
> 
> For any developers following, does this help enough with any
> interoperability questions?

TLS does not depend on certificate path validation.  Many TLS
*applications* rely PKIX certificate path validation (along with
RFC 6125 server identity verification), but TLS itself supports
various alternative authentication (and non-authentication) modes.

   * PSK or SRP without certificates
   * Opportunistic unauthenticated TLS (perhaps anon-(EC)DH with TLS <= 1.2)
   * TOFU public key pinning
   * Static leaf key or leaf cert matching
   * RFC7250 raw public keys
   * DANE-EE(3) leaf certificate/key verification, without expiration
     or server name checks
   * DANE-EE(3) ... with name checks (where UKS attack are relevant)
   * DANE-TA(2) with RFC5280 chain verification, but the trust-anchor
     is part of the chain, and identified via DNS TLSA records.
   * PKIX-EE(1) which is RFC5280 + DANE leaf cert "constraint"
   * PKIX-TA(0) which is RFC5280 + DANE CA "constraint"

Keeping in mind that many implementations of RFC5280 violate that specification
by interpreting EKUs in CA certificates to constrain the kinds of certificates
that the CA may issue.  That de-facto usage is I think much more widely implemented
than the far too complex X.509 policy constraints (RFC5280 4.2.1.11).

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email