Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
Eric Rescorla <ekr@rtfm.com> Sun, 13 March 2016 12:38 UTC
Return-Path: <ekr@rtfm.com>
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 6FB3512D59A for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 05:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 EB_yy-LG85Sa for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 05:38:44 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFE212D598 for <tls@ietf.org>; Sun, 13 Mar 2016 05:38:43 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id g3so138952524ywa.3 for <tls@ietf.org>; Sun, 13 Mar 2016 05:38:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.129.46.87 with SMTP id u84mr9511370ywu.129.1457872723249; Sun, 13 Mar 2016 05:38:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Sun, 13 Mar 2016 05:38:03 -0700 (PDT)
In-Reply-To: <56E54B85.4050204@cs.tcd.ie>
References: <56E54B85.4050204@cs.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 13 Mar 2016 13:38:03 +0100
Message-ID: <CABcZeBNTEB4FxSN=rCZBE02UMn1kDRh83Qob5K2Yf9JTdCQP9A@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="001a114140bacc6c0b052ded7139"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Eiv9gM9lN2faq2p3oT1LtzDv940>
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 12:38:46 -0000
On Sun, Mar 13, 2016 at 12:14 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie > 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. 2. The replay issues are mostly problematic in cases that trouble maintaining consistent state (primarily distributed machines). Non-distributed 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 significantly reduces it to state loss issues, which are easier to control for. So it would 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: https://fetch.spec.whatwg.org/#concept-main-fetch and https://fetch.spec.whatwg.org/#simple-header > 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 more sensible to require that protocols not use 0-RTT absent some specific application layer profile describing when and why it is safe. 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. -Ekr
- [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