Re: [TLS] Update spec to match current practices for certificate chain order

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 11 May 2015 16:57 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2B81ACDF0 for <tls@ietfa.amsl.com>; Mon, 11 May 2015 09:57:04 -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
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 XRksJrhEzMM2 for <tls@ietfa.amsl.com>; Mon, 11 May 2015 09:57:02 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812FF1A86E3 for <tls@ietf.org>; Mon, 11 May 2015 09:57:02 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CD2A1283032; Mon, 11 May 2015 16:57:00 +0000 (UTC)
Date: Mon, 11 May 2015 16:57:00 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150511165700.GY17272@mournblade.imrryr.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AB01B158@uxcn10-tdc05.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB01B158@uxcn10-tdc05.UoA.auckland.ac.nz>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Y3njknBlrIvYZBjF9XciAI8FQbU>
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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: <http://www.ietf.org/mail-archive/web/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, 11 May 2015 16:57:04 -0000

On Mon, May 11, 2015 at 03:03:25PM +0000, Peter Gutmann wrote:

> >https://tools.ietf.org/html/rfc5246#page-5
> >
> >                                  the decisions on how to initiate TLS
> >   handshaking and how to interpret the authentication certificates
> >   exchanged are left to the judgment of the designers and implementors
> >   of protocols that run on top of TLS.
> 
> Oh, I thought that was just marketing fluff rather than a hard-and-fast
> requirement.  If it is a set requirement for the protocol though then it shows
> a major disconnect between the protocol designers and its users, you've got a
> protocol that promises to do cryptographic authentication of the server so
> that developers of apps running on top of it don't have to deal with this, and
> yet in that one sentence it quietly makes it Someone Else's Problem.  So the
> developers of the thousands of vulnerable apps will be assuming that the TLS
> layer [0] will do the checking for them, while the TLS layer can conveniently
> say "well, it's not my problem, and I've got the weasel-words to prove it".

Cynicism is a comfortable posture, but you surely know that different
applications have different ways to verify the peer identity.

There are various alternative name forms SRV-ID, DNS-ID or whatever
the client and server operators bilaterally agree on out of band.
The client may even be using leap-of-trust with pinning to authenticate
the server.

Also, with DANE TLSA certificate usage DANE-EE(3) the name binding
is *outside* the certificate (handled by the TLSA record itself):

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-3.1.1
    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.1

-- 
	Viktor.