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

Stephen Farrell <> Sun, 13 March 2016 13:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D38A12D61A for <>; Sun, 13 Mar 2016 06:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jpmbBYnCx4pJ for <>; Sun, 13 Mar 2016 06:51:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7106D12D620 for <>; Sun, 13 Mar 2016 06:51:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47564BE32; Sun, 13 Mar 2016 13:51:48 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NO0QszcHV3O0; Sun, 13 Mar 2016 13:51:46 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 220E5BE33; Sun, 13 Mar 2016 13:51:46 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1457877106; bh=POQHJ+UWGK1/Gx4VN1x0tVbumTGY7sI7uQ2qClDbXfc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=UrCCP2tDd3OI5eSsXISlPqlNIXBLdzIvRLNZ50HWaYTmhiSF/KPstrBU3xmVrHu2m phz3qXzMSjnUdAzY6s53zFwAhfGl1uBQGvpTDWZHVOe7y7M3p8jE/lgNurOkbdy3NO 1+w66KIKQbgTIQpttieA6iYlJS6/ppfVApXBOOGA=
To: Eric Rescorla <>
References: <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Sun, 13 Mar 2016 13:51:40 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060105000005020407000804"
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 13:51:51 -0000


I mostly agree with what you wrote about specific mitigating factors
for specific potential threats.

For this thread though, maybe we're better talking about how we might
get to where we can be confident that replayable data in TLS1.3 won't
cause significant harm. I'm happy to talk more about the specifics as
well but maybe better to try figure out what are a good set of goals
first (or in parallel).

I think this bit maybe captures where you and I might most come from
different perspectives:

On 13/03/16 12:38, Eric Rescorla wrote:
> Yes, this might be the case, though as above, I note that nothing is making
> those protocols use this feature, 

Sure. Except we *know* that people will see a new API and will use
that to go faster, even if they ought not. TBH, I really don't think
the API approach is sufficient by itself.

> and the specification is quite clear about
> the risks involved here. Rather than requiring some open-ended exploration

"requiring open-ended" doesn't match what I'm asking for. I can
understand your concern though.

I'm trying to figure out how we (the IETF) get to where we are
confident that we understand the important impacts of introducing this
dangerous implement. As I said, I am puzzled as to how we get there and
am asking that the WG help figuring that out before we get to when
tackling issues we find gets harder.

> of the impact on every protocol of this feature, I think it would be far
> more
> sensible to require that protocols not use 0-RTT absent some specific
> application layer profile describing when and why it is safe. 

I think some such statement would help for sure. I'm not sure though if
it's really sufficient. Even if 0rtt was to be in a separate RFC (I
forget if the WG considered that) the issue is that libraries will all
include it (as it'll make the web go faster) so implementers are liable
to turn it on anywhere really.

> That allows
> the
> 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
> object
> and I'd certainly be happy to have such a requirement in 1.3.

So again, I totally understand the reluctance to consider all of the
foo/TLS options within the TLS WG. And I don't even know how one
might get that done if one wanted. (Hence my asking the WG.)

However, it is the TLS WG that is introducing the dangerous implement
and as part of a protocol revision that is mainly intended to improve
security. It seems fair to say that that may be a surprise for folks
who just want to use TLS.

My guess would be that if we say to all the WG's doing foo/TLS that
they need to write a new document before they safely can move from
TLS1.2 to TLS1.3, they'll answer back that the TLS WG should have done
some or all of that before introducing the dangerous implement.

There are at least two bad approaches here I think. One is "higher
layers need to do all the work to figure out if moving from TLS1.2 to
TLS1.3 is safe." Another is "the TLS WG needs to figure out and say if
foo/TLS1.3 is safe for all <foo>."

My issue is that I don't know what middle-ground here is reasonable
and gives us sufficient confidence that TLS1.3 with the dangerous
implement is safe enough.