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