Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Colm MacCárthaigh <> Mon, 14 March 2016 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C40C12D633 for <>; Mon, 14 Mar 2016 09:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T_V8LgOSvun4 for <>; Mon, 14 Mar 2016 09:10:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2648912D63B for <>; Mon, 14 Mar 2016 09:10:06 -0700 (PDT)
Received: by with SMTP id g3so173293716ywa.3 for <>; Mon, 14 Mar 2016 09:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7oHZ6+u/tCB1dOx28rFbuG1jiDRuDZT3oLUXt1+TtH4=; b=vf88d5csUPUOulYEKCJQwJI44YzQ0IcJfTavzm6N109YZ1HRIxRYRFol9jQrvpEztX I9mxO44Blvh73polgAikTqPgBOYMtLxHcck3kCog8DqWOcdhrIHu/N0/68ijZnxOjur/ nkwjda3rLFHy7pq4WyoKxSFnKnf61FeJClj5N6i91mMI/CtKRt2bTF2LRkNoIvBZzGdm 3GFVUaV/OJUdE5lYKRGOY9JsGKRSeWUxlLENMlqD4E25YDP2L+nQon4wJ1vDptN8XMLf wqN4d4v0o6GkqJzOiP66HB3gjlLdP+QzgmziNqbRjJB7xKd2L1HWXkMjb9wgBOlkKyMV nhfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7oHZ6+u/tCB1dOx28rFbuG1jiDRuDZT3oLUXt1+TtH4=; b=iAtpdkfHmhsy0BgjejGur5+9oyNtpIl4BiZ1UXFBWKvvxENbW/odRjxmCk5rxx4kuu TFHJz0mI7h/UU7CPQMic1jfzkASv7Ox4trtIqJQ6sCs0RjBURcy4aGd+5g1f0vk1qPZa JHG0FN74ZNUfUS+voReMclIX/0W2JDtJ0aKzpoC7SZQjscaPD7yWQ2OL1oQiRYsjlPIg Q7r0C8htTCD9JxwZKbcVxhrv2pbBqiZzem+S3GRAGpmBtOgSSycpUnT/56WGYRSiIZDx aeYB+XCxPYXQiMMO+TCJsm+3WoyMBWO0QkfoOBdeSOBAUVuC5B8oPgAHCt80vX0kfvdl k8uw==
X-Gm-Message-State: AD7BkJLtu19YYEjuT+WKb8KXPVxiOmbQo34A/OgtkRqG2Pjdkq6r0PWdOQzqgR9983QwwXv4bl/FWONi/yJ9Ng==
MIME-Version: 1.0
X-Received: by with SMTP id b5mr12691657ywd.114.1457971805429; Mon, 14 Mar 2016 09:10:05 -0700 (PDT)
Received: by with HTTP; Mon, 14 Mar 2016 09:10:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Mon, 14 Mar 2016 09:10:05 -0700
Message-ID: <>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
To: Bill Cox <>
Content-Type: multipart/alternative; boundary=001a114e3f988ec47b052e04838d
Archived-At: <>
Cc: Scott Schmit <>, "" <>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
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: Mon, 14 Mar 2016 16:10:09 -0000

On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox <> wrote:

> As we all know, what matters most in security is the default mode.  I am
> suggesting making the default 0-RTT resumption mode stateful, with a
> documented session-ID (and let's bring back the timestamp, too, since we'll
> need it).

Having state would make things much more robust; but rather than the state
being around the channel itself (the TLS session), would it be more robust,
and more flexible, for the state to be around the action? like some kind of
hint cookie.

One of the problems with session resumption is that in order to be replay
safe; the sequence number has to restart where it left off. That requires
some kind of transactional store, and if you're doing all of this for
latency, you may end up eating all of the wins there.

Another way to go would be a token that represents an action, e.g.:

1. As part of a regular TLS session, post handshake, client sends a
hint_request request layer message type. This can be URL, or any arbitrary
data, and it's encrypted just as normal application_data is.
2. Server responds with a hint_response token; it's just an opaque token.
3. For future TLS connections; client is free to include the hint token
data in the 0RTT handshake data.

Some interesting advantages:

1. The hint is very distinct from from the application_data stream.
2. The server can choose to use the token ticket-style; encrypt the URL or
whatever directly in the hint.
3. The server could also choose to use the token session-ID style; store it
in a lookup table.
4. Either way; the server has explicit control over what may constitute a
hint and it can be checked and locked down; before the client can transmit
something that may turn out not to be safe.
5. A server could also defer returning the token until the end of the
application session. Hints could be used as application layer resumption or
continuation tokens.

Some downsides:

1. Transactional safety is very difficult; idempotence at the application
layer is a very difficult to achieve property and this doesn't solve that.
2. Similar to TLS tickets/ids: the user's on-the-wire forward secrecy is at
the mercy of the server.
3. Hints could be used as super cookies for user-tracking.
4. Complicated request-response semantics post-handshake (similar to
5. Doesn't seem worth the complexity to me.