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

Eric Rescorla <> Sun, 13 March 2016 12:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FB3512D59A for <>; Sun, 13 Mar 2016 05:38:46 -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 EB_yy-LG85Sa for <>; Sun, 13 Mar 2016 05:38:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AFE212D598 for <>; Sun, 13 Mar 2016 05:38:43 -0700 (PDT)
Received: by with SMTP id g3so138952524ywa.3 for <>; Sun, 13 Mar 2016 05:38:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WxoRnlrCr4rsg7sVa6R11fBs3kxgAWzFB3U+Gjdu+fk=; b=jYemGoVQBvAV1VGTqsnzlXNl6OZrCaXqsdzc7omaFu5C4sIgKaMAJVftTQESDA5EjQ zBn3McpqfLx5esKOVPkQKu/m0l3S2OdBujHfCeFQbFsUSvzdMRy/YrC5jFlXeaaYk3q+ y0AdwrU/copHiN8Uw2AbL2Rp5j+iGJpo3wbStgLcDJ2/Ds0N150/wbY8ytt8pKd2NnWh r1A3Uem2K9favS2nCLQhIsbjj3dtgpm/v+ueaWLKGqtyDiB36TgZpEObqODngiTSycE0 ZLU5HCcJHW16DgBB7HcP9Nzeh/C+XOdaqyMTLTVjtGlGibQ9rFenzWsuu/KCTVPG8Dof 09JA==
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:from:date :message-id:subject:to:cc; bh=WxoRnlrCr4rsg7sVa6R11fBs3kxgAWzFB3U+Gjdu+fk=; b=ac9NemU/fVMshOKQaJ8YOCmLc5KXiibZoniXDm7XiHOJAXFeBmbS0zM90JZvR1skMW vR9MUA3BzJtqYdzUJBTZnDxaAYPUxhoIH15UdBSAS1VNMtPHS+7Cufydoo5eG3BCzRTO ehJNsCiETOZOH6cHNKSV7T18uNhIVgSzC3wPiCBC9uB/RVzaWLwpUFTBADjFaQCZbhRN a8p96MTSjPF5kGqlkFjRSXhmJl3BiQ4bp/8rdnM7CDV9viBD8F02DgiPgjoe8iQVpjOu 5NfGdtu8z4QtTCbolRBi/6SSM3j4+wFVuDMbMs8C8UHa/wqZzAAcau0zsEFYjhcPpaiD 0t1Q==
X-Gm-Message-State: AD7BkJL8sw9BbZRlX1zaiBcPxccO6ybmc7+u1Ib8zl3RkGY6vJjC3xZIV3RMKn3ImuZTd1ZSIerl4SicI5Bi3A==
X-Received: by with SMTP id u84mr9511370ywu.129.1457872723249; Sun, 13 Mar 2016 05:38:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 13 Mar 2016 05:38:03 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Sun, 13 Mar 2016 13:38:03 +0100
Message-ID: <>
To: Stephen Farrell <>
Content-Type: multipart/alternative; boundary=001a114140bacc6c0b052ded7139
Archived-At: <>
Cc: "" <>
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: Sun, 13 Mar 2016 12:38:46 -0000

On Sun, Mar 13, 2016 at 12:14 PM, Stephen Farrell <
> wrote:
> However, if I'm in the rough about the above, (which seems
> to me to be the case now) then my job as AD when I get a publication
> request that includes 0rtt, will include figuring out if that's
> safe or not. And I've no clue how I'll do that unless the WG
> have already done some analysis of the many, many protocols
> that use TLS. Note that I do not consider "use a different API"
> to be a sufficient answer here (it is necessary, but not
> sufficient).

It seem to me that there are several important mitigating factors here.

1. Nothing requires applications to use this feature at all. First, servers
need to advertise it and are free to (a) not offer clients the ability to
0-RTT data and (b) refuse to accept it if clients send it. Moreover,
I know of who is considering building a 1.3 library intends to provide
that data to the server via a separate API, so the server will have to work
to get it.

2. The replay issues are mostly problematic in cases that trouble
maintaining consistent state (primarily distributed machines).
systems can maintain a replay cache and refuse to accept traffic which
appears to be a replay. This does not reduce the risk to zero but it
reduces it to state loss issues, which are easier to control for. So it
probably be useful to document some anti-replay mechanism based on the
ClientHello fo such protocols.

I've been worried about this for a while now, but the recant
> thread started by Kyle Nekritz [3] prompted me to send this
> as I think that's likely just the tip of an iceberg. E.g., I'd
> be worried about cross-protocol attacks one might be able to
> try with JS in a browser if the JS can create arbitrary HTTP
> header fields which I think is the case.

It's not generally the case without server consent. CORS prohibits the use
of any
non-simple headers in CORS requests without preflight. See:

> I'm also worried about
> things like EAP-TLS and RADIUS/Diameter if used via TLS etc
> where we don't necessarily have the right people active on this
> list.

Yes, this might be the case, though as above, I note that nothing is making
those protocols use this feature, and the specification is quite clear about
the risks involved here. Rather than requiring some open-ended exploration
of the impact on every protocol of this feature, I think it would be far
sensible to require that protocols not use 0-RTT absent some specific
application layer profile describing when and why it is safe. That allows
experts in those protocols to do their own analysis, rather than somehow
making it the responsibility of the TLS WG. I agree that this is a sharp
and I'd certainly be happy to have such a requirement in 1.3.