Re: [TLS] Review of PR #209

Martin Thomson <> Wed, 16 September 2015 17:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3CFBC1A7020 for <>; Wed, 16 Sep 2015 10:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0i3MwwW5SLrS for <>; Wed, 16 Sep 2015 10:48:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C373A1A6FEB for <>; Wed, 16 Sep 2015 10:48:27 -0700 (PDT)
Received: by ykft14 with SMTP id t14so75123491ykf.0 for <>; Wed, 16 Sep 2015 10:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id u2mr29493300ywf.57.1442425707116; Wed, 16 Sep 2015 10:48:27 -0700 (PDT)
Received: by with HTTP; Wed, 16 Sep 2015 10:48:27 -0700 (PDT)
In-Reply-To: <20150916153041.GA14682@LK-Perkele-VII>
References: <> <> <20150916153041.GA14682@LK-Perkele-VII>
Date: Wed, 16 Sep 2015 10:48:27 -0700
Message-ID: <>
From: Martin Thomson <>
To: Ilari Liusvaara <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Review of PR #209
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Sep 2015 17:48:29 -0000

On 16 September 2015 at 08:30, Ilari Liusvaara
<> 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.