Re: [TLS] Review of PR #209

Martin Thomson <martin.thomson@gmail.com> Wed, 16 September 2015 17:48 UTC

Return-Path: <martin.thomson@gmail.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 3CFBC1A7020 for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 10:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 0i3MwwW5SLrS for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 10:48:28 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 C373A1A6FEB for <tls@ietf.org>; Wed, 16 Sep 2015 10:48:27 -0700 (PDT)
Received: by ykft14 with SMTP id t14so75123491ykf.0 for <tls@ietf.org>; Wed, 16 Sep 2015 10:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VbGlzMvFf0Rsil0qNxY6jE9o2zK//wslHMlcoo8y6AM=; b=mpHD/xEmjtLPwUEoFsEPhOxplcov3cWRK5YYqGB5sM3SNY2TXzw+rev2HRFDmT0nqP k/THKMIkYaxoY1aet8053gWhwsDrfuCaDR1VoQKv2irZWFaczPOJDcuB3e2dg7cFxBO9 Vr2yt1SiEiV/F9cZab6StBebTa8hjKFe9tYdTXIpMzPDwNmLoVbrvI/Q71+4i6m/6a99 Wgi0Am1dfI88HICZ7gZ068dy/F5G1n50RjcxWAdSUNilNJQTGTnyGXpPq79hTfDjwONX zcv7ITcfUqQZyUhzQ3kxZGzc8dZ9W6YLWjgGZyZaZyF/wGK/XrHcAtmilWFBHikZWN70 YfiA==
MIME-Version: 1.0
X-Received: by 10.129.132.2 with SMTP id u2mr29493300ywf.57.1442425707116; Wed, 16 Sep 2015 10:48:27 -0700 (PDT)
Received: by 10.129.133.130 with HTTP; Wed, 16 Sep 2015 10:48:27 -0700 (PDT)
In-Reply-To: <20150916153041.GA14682@LK-Perkele-VII>
References: <CABkgnnWtUjH1b3xm_peffNxNpxXE9rudJLJpn1ExNpE7B29AhA@mail.gmail.com> <BLUPR03MB13962416E8D8AD71CFFE13C08C5C0@BLUPR03MB1396.namprd03.prod.outlook.com> <20150916153041.GA14682@LK-Perkele-VII>
Date: Wed, 16 Sep 2015 10:48:27 -0700
Message-ID: <CABkgnnVbJvFQ217Yq7eVLV+_cuQOUVoi1Ydixq5zBC9Zju1U-g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/JLNhZwsWnNQ5_jkhs5jeuCsqdec>
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 17:48:29 -0000

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.