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

Eric Rescorla <> Sun, 13 March 2016 14:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C240412D522 for <>; Sun, 13 Mar 2016 07:50:27 -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 jhcaLewSsrVk for <>; Sun, 13 Mar 2016 07:50:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BAEA12D5B2 for <>; Sun, 13 Mar 2016 07:50:26 -0700 (PDT)
Received: by with SMTP id d65so140842746ywb.0 for <>; Sun, 13 Mar 2016 07:50:26 -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=HOnEjPXjqRvF7gaDsEP2xN4FII0wntEFXF3DTLKULzE=; b=tF+tMrqpyLtaq3poP5saKw+TYwpa7VASCjhVcwYF3ueQ/OYHz5y21u2hHSLjb6GkFf mhH3q5xYARAx9QZ2KI1z0HIXGywi8ynDcN/rRbQKsx4Hc0RD2XZ8ABaLAbNbBky1db4n jqV1Ez7nXqN476F1dMG9Qr979V676j3vP00rVmcy9Emch2EKbMMWOUHNl4Pif9kkZAXw FqMGbSfKESVKLS+Ok/Ja0Ryl6RgzTr6YN7ABzILOx8MDWsM/7udGbEvLBrvrRwsa/+64 uDSqZZzbBhcwf/lcZJHGRGthSmsWlBRtAQTRwNTd5HjNVl+F3aryHaD8LiU1Y6XaAe/b sxTA==
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=HOnEjPXjqRvF7gaDsEP2xN4FII0wntEFXF3DTLKULzE=; b=b0uAu2gsS61SK3dKmLrcSDf6FR99/txyWl4bX7/bv+5JmoS5POOwpwC96nYs4ZKU1t 8eOugcJ+hLsNhBojcMWwabBVePC6oYqZbP1iPG0HBIfnb8h5+fQKUG0RK92Lt7InJBuW BZGVeIiuzIxSj+zoz9Oyvss94dvwfuEzlCxoWhTuDvCcdBB29zbicNkWVrEnCAulDt7o WNzYL3mW8hJE7TqDZb3Y/5ZcdYezn6WlJhmciSDFD14NZ7VXvM1lEWIIPkZectJGMSQ0 lRfGBAqJIDM0ZBn3v8TF0DJRX5hiP5hCk31Kx7yx2pPDKAQAKDUq0LMggKmyRDyXcxOu Eubw==
X-Gm-Message-State: AD7BkJJn7i22BncxtYVy9t3KOfJ2FkdRd5bmpwbEWTjFi8KtCy67AlbtaigGe8s80MKKc/H/XmssoC/XZHVldA==
X-Received: by with SMTP id x8mr10745771ywx.223.1457880625401; Sun, 13 Mar 2016 07:50:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 13 Mar 2016 07:49:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Eric Rescorla <>
Date: Sun, 13 Mar 2016 15:49:45 +0100
Message-ID: <>
To: Stephen Farrell <>
Content-Type: multipart/alternative; boundary=001a114202f8cd8431052def484c
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 14:50:27 -0000

On Sun, Mar 13, 2016 at 3:41 PM, Stephen Farrell <>

> Hiya,
> On 13/03/16 14:01, Eric Rescorla wrote:
> >
> > This is not an accurate way to represent the situation. Those WGs can
> safely
> > move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*.
> I agree your 2nd sentence but not your 1st.
> I also think it is prudent to assume that implementers will turn on
> replayable data even if nobody has figured out the consequences.

That may well be true, but I don't believe that it allows us to make
We already know that there are conditions in which 0-RTT is unsafe. That's
the specification has extensive caveats around its use. Therefore, either we
(collectively) can:

- Not specify it at all.
- Specify it and provide warnings that people should only use it in certain
  circumstances and attempt to delineate these circumstances.

In my original message, I proposed that we restrict the use of 0-RTT to
settings where it has been explicitly profiled. Your response seems to be
that people will turn it on even if we do so. But if that's your position
there's no point in doing any analysis because we already know that there
are cases where it's not safe, which is why we are warning them against
using it in those cases.

In any case, I'm a little surprised by your assertion in a previous message
that WGs expect us to do this analysis. That's not been the relationship
we've have with WGs in the past; rather, we document the properties we
are providing and they have to determine whether those properties are
appropriate. Perhaps we could start by actually sponsoring some of those
reviews. Given that HTTP is the primary customer for 0-RTT, perhaps
Mark or Martin would be willing to start a review there?