Re: [TLS] SNI and Resumption/0-RTT

Ilari Liusvaara <> Fri, 21 October 2016 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CCBA1295E6 for <>; Fri, 21 Oct 2016 07:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rhMB1Lqni5Rz for <>; Fri, 21 Oct 2016 07:42:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D46F41295CF for <>; Fri, 21 Oct 2016 07:42:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 739CF1415C; Fri, 21 Oct 2016 17:42:46 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id Otdw_0eGS8K6; Fri, 21 Oct 2016 17:42:46 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1783F283; Fri, 21 Oct 2016 17:42:46 +0300 (EEST)
Date: Fri, 21 Oct 2016 17:42:38 +0300
From: Ilari Liusvaara <>
To: Martin Thomson <>
Message-ID: <>
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)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] SNI and Resumption/0-RTT
X-Mailman-Version: 2.1.17
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: Fri, 21 Oct 2016 14:42:50 -0000

On Fri, Oct 21, 2016 at 12:38:29PM +1100, Martin Thomson wrote:
> So I think that the problem could be reduced in complexity.  A little
> at least.  The obvious consequence of changing SNI is that you end up
> somewhere different than last time.  But we can still ensure that the
> connection is to the same peer.

You _might_ end up somewhere different. And even with the same SNI, you
can still end up to different server in the same "group". And different
SNI names can still get you to the same actual place.

> If the server remembered which certificate it used, and insisted that
> THAT remain constant, then you could take a different SNI from - for
> example - a subjectAltName.  Provided that the routing works out, you
> might still get the same certificate.
> I mean, the point of SNI is to route to the right configuration.
> Changing name messes with resumption in that you want to make sure
> that you end up in a place that has the resumption secret.  But if you
> end up at the wrong server, you either fail to resume, or fail to
> connect on the normal terms of the protocol.

There are three tasks of SNI:

- Routing to the correct server. Sometimes this routing is performed by
  middleboxes (yay, middleboxes!).
- The certificate selection within the server.
- Set application instance, if the protocol can't do this in-band (but
  if it does, applications generally override this with in-band value).

And I would expect the servers to actually look at the PSKs offered and
not blindly trying to use one, so if connection is routed wrong, I would
expect fallback to the usual DH-CERT handshake.

> The only thing that could screw this all up is if we end up in a
> situation where one or other peer is confused about either its own
> identity, the identity of its peer, or the identity (-ies) that it
> believes it peer has for itself.  However, with certificate stability
> rather than name stability I don't think we are worse off than with -
> say - a wildcard cert.

I would expect such confusion about own identity to be pretty much the
norm for HTTP servers. And those are frequently used in ways that tend
to amplify even a small errors to serious attacks.

For other types of servers, I would expect any confusion resulting in
security problems to be pretty rare.

But since HTTP is very important usecase, this impiles that the client
shouldn't attempt to use PSKs when such confusion could create security

> I agree that the add-a-name stuff makes this harder.  A co-tenanted
> server with resumption keys across a bunch of names risks confusing
> itself if it allows resumption across certificates, depending on how
> much state it carries from the old session.  In doing add-a-name, then
> we need to be careful about that, but that's a problem for those of us
> who want to do add-a-name.

You can already get such confusion with wildcard certificates, no
changes needed..