Re: [TLS] Review of PR #209
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Wed, 16 September 2015 15:30 UTC
Return-Path: <ilari.liusvaara@elisanet.fi>
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 DC5EA1AC447 for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 08:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 9sp4GyLZ9fZT for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 08:30:45 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847131AC3DB for <tls@ietf.org>; Wed, 16 Sep 2015 08:30:44 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 034A13FD9; Wed, 16 Sep 2015 18:30:41 +0300 (EEST)
Date: Wed, 16 Sep 2015 18:30:41 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Message-ID: <20150916153041.GA14682@LK-Perkele-VII>
References: <CABkgnnWtUjH1b3xm_peffNxNpxXE9rudJLJpn1ExNpE7B29AhA@mail.gmail.com> <BLUPR03MB13962416E8D8AD71CFFE13C08C5C0@BLUPR03MB1396.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <BLUPR03MB13962416E8D8AD71CFFE13C08C5C0@BLUPR03MB1396.namprd03.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/K6nchLnRAEhMRaqob8KNV4w1APY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Review of PR #209
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 16 Sep 2015 15:30:48 -0000
On Tue, Sep 15, 2015 at 08:17:56PM +0000, Andrei Popov wrote: > Perhaps we can simplify the protocol by pulling client auth out of the > handshake as follows: Problem with pulling client auth out of the handshake is that it complicates applications that can't change identities involved with active connection. And applications that can't take dynamic identites may still be able to take static identities. As then the application needs to ensure that the authentication occurs between TLS handshake and actually starting up the protocol. > 2. The client can send Certificate and CertificateVerify at any > time application data is permitted, regardless of whether the > server had previously sent CertificateRequest. CertificateRequest contains the permitted signature algorithms for the PoP signature, which TLS library needs to verify before dumping the certificate chain on application (which can then figure out things like trust anchors). Without CertificateRequest, one has little idea what algorithms are acceptable there. > 3. The server can send CertificateRequest and NewSessionTicket at any > time application data is permitted. Alternatively, the server can > encapsulate CertificateRequest in an application protocol message. If done with protocols that can't support dynamic authentication properly, doing that tends not show up as things visibly breaking, it tends to show up as subtle security holes. Also, that doesn't properly bind NST with state is for (as already noted), possibly causing screwy behaviour if TLS resumption is attempted (client and server not agreeing on client identity, which actually breaks definition of secure key exchange outright). > Encapsulating CertificateRequest in an application protocol message > allows the client to determine which specific application request > resulted in the need for client auth. The application protocols that would indicate this seem to be pretty much the ones where dynamic authentication is unsafe. Basically, one must clear the pipeline before changing identities, and with protocols like HTTP/2, this is extremely expensive (seemingly even more expensive than establishing a new connecion). > We can decide exactly what CertificateVerify would be signing: > whether it's the handshake hash or some form of RFC5705 Exported > Keying Material (EKM). Also, it should sign the certificate, to avoid possible weirdness due to signatures not properly binding the key (some schemes do, most don't). -Ilari
- [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Ilari Liusvaara
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Eric Rescorla
- Re: [TLS] Review of PR #209 Eric Rescorla
- Re: [TLS] Review of PR #209 Ilari Liusvaara
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Daniel Kahn Gillmor
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Karthikeyan Bhargavan
- Re: [TLS] Review of PR #209 Ilari Liusvaara
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Daniel Kahn Gillmor
- Re: [TLS] Review of PR #209 Geoffrey Keating
- Re: [TLS] Review of PR #209 henry.story@bblfish.net
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Geoffrey Keating
- Re: [TLS] Review of PR #209 Henry Story