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

Nikos Mavrogiannopoulos <> Mon, 14 March 2016 12:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDB6E12D572 for <>; Mon, 14 Mar 2016 05:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qcZFU0XOHn4J for <>; Mon, 14 Mar 2016 05:10:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D203612D55F for <>; Mon, 14 Mar 2016 05:10:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id E3B0B6E78D; Mon, 14 Mar 2016 12:10:36 +0000 (UTC)
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id u2ECAWVQ007881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Mar 2016 08:10:35 -0400
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Eric Rescorla <>, Stephen Farrell <>
Date: Mon, 14 Mar 2016 13:10:32 +0100
In-Reply-To: <>
References: <> <>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on
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: Mon, 14 Mar 2016 12:10:40 -0000

On Sun, 2016-03-13 at 13:38 +0100, Eric Rescorla 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 send
> 0-RTT data and (b) refuse to accept it if clients send it. Moreover,
> everyone
> 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.

It is important to see how protocols are perceived. For many people TLS
1.3 with 0rtt will be the same as TLS 1.3. The first publication of an
attack against TLS 1.3 with rtt, will be perceived as an attack against
TLS 1.3 protocol. Even if the published attack against TLS 1.3 with
0rtt was an expected one (i.e., replay of data), if the attack impact
is high, that may not be sufficient to stop the avalanche of bad
publicity. In turn that will lead several people losing confidence to
TLS 1.3 as a protocol, even TLS and the IETF process overall.
My suggestion, if you need 0rtt, publish it as a different document,
don't mix it with TLS 1.3. The security requirements from TLS are
vastly different from the security requirements of a 0rtt protocol.