Re: [TLS] Review of PR #209

Eric Rescorla <ekr@rtfm.com> Wed, 16 September 2015 18:20 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 501361A8823 for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 11:20: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 refKvOr1MGSX for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 11:20:44 -0700 (PDT)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 B0EE81A87EB for <tls@ietf.org>; Wed, 16 Sep 2015 11:20:43 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so85383461wic.1 for <tls@ietf.org>; Wed, 16 Sep 2015 11:20:42 -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=03JMSKdo8yZz3kPtocrtgoPELNmyk+CjIpdhM0EEeAo=; b=gc61rA0K0ZqnN1HBKSAwTxcIKw8Md09XXKdSjdFtzRJfDSJI4NO5bYGRf9hf3Q4nDp LGEmxYtE+nFyqYfJ6QqAgIUOotKsVCeJUle+gmb4XP5izrlLdMClyBYEilWII2fLcnqf VfaEWWNfr7HSfvW6wGHmabGrxAxVaej8yfdIE313OTircANhYRauVZrs+zV9ZRq10rUs yrZIGC+mGnxGiSvkCEXRRvolhHn0j6msgNqTQfiGaEb4ThFpYTEe+I7ICG/OX//mK8yO phb0A27qo6Mmca9PyQq9/m0m6b6JeiJrRyqn2xtgNi7f3OqsJJMxfIOpE6h1pyhHoz5K INrg==
X-Gm-Message-State: ALoCoQmfY4j0mrGSf+9CtiiLODPxeq8BIfgzd+FAtifPAkAjbKRtTtfMDY8GGY/t/KPSpCsxHi6n
X-Received: by 10.180.88.4 with SMTP id bc4mr22340275wib.68.1442427642275; Wed, 16 Sep 2015 11:20:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.79.200 with HTTP; Wed, 16 Sep 2015 11:20:02 -0700 (PDT)
In-Reply-To: <CABcZeBMJ4Kseu1Dy3eymZ+-XVx719szy8ZMKgcExm8myxByT5g@mail.gmail.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> <CABcZeBMJ4Kseu1Dy3eymZ+-XVx719szy8ZMKgcExm8myxByT5g@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 16 Sep 2015 11:20:02 -0700
Message-ID: <CABcZeBMKkt6R5NjvKN=5z3dPFX=keX=gWk6aJB62odcRf1dW8g@mail.gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary=f46d04428ee43b8453051fe15b3c
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/cfYOb-cKw4k5A0veXiCP5DBB6gA>
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:20:46 -0000

I should add: I do think this general line of consolidating all the client
auth modes is a good idea, assuming we can work out the details.

-Ekr


On Wed, Sep 16, 2015 at 11:18 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> 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
>>
>
>