Re: [TLS] Followup on Update

Ilari Liusvaara <> Wed, 25 February 2015 08:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E8E141A1EF1 for <>; Wed, 25 Feb 2015 00:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Kbsmu9YSd10 for <>; Wed, 25 Feb 2015 00:18:06 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D17211A1C06 for <>; Wed, 25 Feb 2015 00:18:05 -0800 (PST)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 3DD38400D; Wed, 25 Feb 2015 10:18:03 +0200 (EET)
Date: Wed, 25 Feb 2015 10:18:02 +0200
From: Ilari Liusvaara <>
To: Eric Rescorla <>
Message-ID: <20150225081802.GA6434@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Followup on Update
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, 25 Feb 2015 08:18:09 -0000

On Tue, Feb 24, 2015 at 04:44:22PM -0800, Eric Rescorla wrote:
> Folks,
> I'd like to get a sense of the WG on whether they want to pursue the Update
> mechanism [0].
> There are several possibilities here, including:
> - Just do basic Update

This seems pretty okay to me.

If there is some cryptographic concerns (that I can't see, and would
really appeciate if those were pointed out[1]) of server sending data
with pending certificate request[2], could those be addressed by
having the client Update the connection after sending certificate
and its verification?

Regarding misuse potential of that, the client is unidentified at
the point, so it seems pretty hard to misuse.

Now, with some non-DHE key exchanges (mainly PAKE) you might have
identified but unauthenticated client. I think it is reasonable
for the TLS library to return error for attempts to obtain the
client identification before it is authenticated. The present
rule does not help here, since the authentication does not involve
a client certificate.

> - Move session ticket establishment to Update

How does client know when it can resume a session? It takes 1RTT
to get connection to state where it can transmit data, but 2RTT
to state where it can resume (since server needs to have received
client's second flight, or resume is not going to work right).

> - Mode client authentication to Update

This scares me. Not the crypto parts, but the misuse potential. Even
doing it once seems as bad to me as doing it N times.

If the protocol is something like imaps, submission(stmp) or ircs,
then sure it looks safe.

But try to use it e.g. with active HTTP/2 connection, and thing just
go badly wrong. This is because adding/dropping certificates with
multiplexed protocol needs substantial coordination at application
layer to do safely.

[1] And if there are such, I think SSH should carefully be analyzed,
because it does pretty much exactly this.

[2] Would be useful for e.g. protocol feature negotiation, since
ALPN does not scale. E.g. consider wanting to use HTTP/2 with
tokbind (ChannelID) + Websockets.