Re: [TLS] Review of PR #209

Eric Rescorla <ekr@rtfm.com> Wed, 16 September 2015 18:18 UTC

Return-Path: <ekr@rtfm.com>
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 B0B4A1A87BD for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 11:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 QXytZc3bsoO7 for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 11:18:44 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF851A87D7 for <tls@ietf.org>; Wed, 16 Sep 2015 11:18:42 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so82705522wic.1 for <tls@ietf.org>; Wed, 16 Sep 2015 11:18:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WK24NoMc23Le1j2cBosiYoqZvmfBCfgYj1/EG6UTw+o=; b=RMbFmOtCbMRcuSPkBPGIzSDcAjQeNGRmkUc4IUP3JLLq2ICKKGI080pXFT3AC94/LX s7NE1ziH3nc3GLEU0v7uhqZ4KGnbtWbVTD6nioIiFygtP4WIlEJCZG4gXUiLtk+sOaBQ HjcXLdRSkbEkWfxQVpsLvmD4t/1G1tMRh9g1Hc9dKJuF42ErtGpjaExN2NRrOnOf42uw jSrxyloCvqJtTyfCuI4KggwMyMBHRINPtaLDIv57wT/pUwNkPMsJrFFZlKgoST1pwFvw HOxHnWpDDY91WTGQU22wEpoxKYFKf+64pMmhJ9Mw6GTZu7VD9/oktU8OkpxKyf4IM0xv tRgg==
X-Gm-Message-State: ALoCoQl4oEmAghY51sIRF9Lz3b6CBEhziH0iBQkEu+OhK2o0YAO8SHQnGcBVl9b5P1ZuudrpFX4Y
X-Received: by 10.194.133.129 with SMTP id pc1mr24357572wjb.148.1442427521061; Wed, 16 Sep 2015 11:18:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.79.200 with HTTP; Wed, 16 Sep 2015 11:18:01 -0700 (PDT)
In-Reply-To: <BLUPR03MB139654F63537A53BA3CD28C88C5B0@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CABkgnnWtUjH1b3xm_peffNxNpxXE9rudJLJpn1ExNpE7B29AhA@mail.gmail.com> <BLUPR03MB13962416E8D8AD71CFFE13C08C5C0@BLUPR03MB1396.namprd03.prod.outlook.com> <20150916153041.GA14682@LK-Perkele-VII> <CABkgnnVbJvFQ217Yq7eVLV+_cuQOUVoi1Ydixq5zBC9Zju1U-g@mail.gmail.com> <BLUPR03MB139654F63537A53BA3CD28C88C5B0@BLUPR03MB1396.namprd03.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 16 Sep 2015 11:18:01 -0700
Message-ID: <CABcZeBMJ4Kseu1Dy3eymZ+-XVx719szy8ZMKgcExm8myxByT5g@mail.gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary=089e01227d9401efcf051fe15481
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sEnEDkDwE-u_1PCGpH5fic4KJGI>
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 18:18:46 -0000

I think the potential issue here is needing a way for the server to tell the
client "don't bother sending me data until you've authenticated" (though,
as MT says, you could argue that the client's signature retroactively
authenticates, which does seem like the simplest way to think about things).

One might imagine dealing with that by a simple signal in a ServerHello
extension that said "authentication will be required, sit tight..."

-Ekr


On Wed, Sep 16, 2015 at 11:11 AM, Andrei Popov <Andrei.Popov@microsoft.com>
wrote:

> Martin's point makes sense to me: applications that need to do
> authentication upfront can still do that immediately after the handshake.
>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Wednesday, September 16, 2015 10:48 AM
> To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> Cc: Andrei Popov <Andrei.Popov@microsoft.com>om>; tls@ietf.org
> Subject: Re: [TLS] Review of PR #209
>
> On 16 September 2015 at 08:30, Ilari Liusvaara <
> ilari.liusvaara@elisanet.fi> wrote:
> > Problem with pulling client auth out of the handshake is that it
> > complicates applications that can't change identities involved with
> > active connection.
>
> Why would that be unsupported here?  The server can still send
> CertificateRequest immediately after its Finished.  That looks exactly like
> it does today, only the order has changed.
>
> > As then the application needs to ensure that the authentication occurs
> > between TLS handshake and actually starting up the protocol.
>
> I'm not sure that is necessarily a problem.  If the claim is that the
> authentication attests to everything prior to its appearance, then you have
> no problem.  I think that claim is reasonable, but I'm happy to discuss it.
>
> >> 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.
>
> Arguably, signature_algorithms covers that adequately.  Though I'll grant
> that certificate chain validation often happens in a separate component to
> the TLS stuff.
>
> > 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).
>
> There's been some confusion about this with HTTP/2.  I think that if you
> adopt the position that authentication applies to the entire session - even
> retroactively - then the only remaining concern is the correlation one.  If
> you have three tabs to the site open where all of them are making requests
> and you see a certificate request, which one do you pop the dialog on?
>
> > Also, it should sign the certificate, to avoid possible weirdness due
> > to signatures not properly binding the key (some schemes do, most
> > don't).
>
> I agree with this.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>