Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 13 March 2016 13:51 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D38A12D61A for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 06:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpmbBYnCx4pJ for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 06:51:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7106D12D620 for <tls@ietf.org>; Sun, 13 Mar 2016 06:51:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47564BE32; Sun, 13 Mar 2016 13:51:48 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO0QszcHV3O0; Sun, 13 Mar 2016 13:51:46 +0000 (GMT)
Received: from [10.87.49.100] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 220E5BE33; Sun, 13 Mar 2016 13:51:46 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; 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 <ekr@rtfm.com>
References: <56E54B85.4050204@cs.tcd.ie> <CABcZeBNTEB4FxSN=rCZBE02UMn1kDRh83Qob5K2Yf9JTdCQP9A@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56E5706C.4020804@cs.tcd.ie>
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: <CABcZeBNTEB4FxSN=rCZBE02UMn1kDRh83Qob5K2Yf9JTdCQP9A@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms060105000005020407000804"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/d_f2IqHe1dtXHE2nRNa2MDXYYbM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Mar 2016 13:51:51 -0000
Hiya, 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. Cheers, S.
- [TLS] analysis of wider impact of TLS1.3 replayab… Stephen Farrell
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Stephen Farrell
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Stephen Farrell
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Salz, Rich
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Yoav Nir
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Salz, Rich
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Stephen Farrell
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Kurt Roeckx
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Salz, Rich
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ilari Liusvaara
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Andrei Popov
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Scott Schmit
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Erik Nygren
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Harlan Lieberman-Berg
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ilari Liusvaara
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Nikos Mavrogiannopoulos
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Kyle Nekritz
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Viktor Dukhovni
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Subodh Iyengar
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Watson Ladd
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Subodh Iyengar
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ilari Liusvaara
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Geoffrey Keating
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ryan Hamilton
- [TLS] Splitting all stateless 0RTT into its own d… Dave Garrett
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Salz, Rich
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] Splitting all stateless 0RTT into its o… Eric Rescorla
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Geoffrey Keating
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ryan Hamilton
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Ryan Hamilton
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Colm MacCárthaigh
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Kyle Nekritz
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Bill Cox
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Eric Rescorla
- Re: [TLS] Splitting all stateless 0RTT into its o… Ilari Liusvaara
- Re: [TLS] Splitting all stateless 0RTT into its o… Viktor Dukhovni
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Hubert Kario
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Martin Thomson
- Re: [TLS] analysis of wider impact of TLS1.3 repl… Hubert Kario