[TLS] Closing on 0-RTT
Eric Rescorla <ekr@rtfm.com> Sun, 11 June 2017 15:18 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 36E9912441E for <tls@ietfa.amsl.com>; Sun, 11 Jun 2017 08:18:48 -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 tgP3Fuz2cifK for <tls@ietfa.amsl.com>; Sun, 11 Jun 2017 08:18:46 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 98F37127011 for <tls@ietf.org>; Sun, 11 Jun 2017 08:18:44 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id 63so30457472ywr.0 for <tls@ietf.org>; Sun, 11 Jun 2017 08:18:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6SWnNl436DSyxubacVFKb+zPzE9NFdRwUSRCjo4nEpQ=; b=rspS9rwWtgZYZNhhLalvpvGekp3VP6Al/OVQvZy0JIO68qtcX/NIoBRuCKtC8qQ7sH H6mxuKRBX0OAox+/CH8X9eY63E5n1Mpv5PDct7UupVqaVYKid54bsKrzMYgIjXKOQSm5 rWEC7E1WAXCavBFvHCrPDvPgd7IuLZURrCbwMYbbgSaibilbVQdNYqMqDe6cV2Rkrmli 9qjGmMmrdJE9FbBX+dv/YBRT31IXPRrZPom01I17Y5Ch3j5mLJyW849jecdA+QStJh7l ZoZh55rreAt64EWW34h2zTcnJt6F3j4CAwSR6biV9JXFixFG4g7z+wukm+EZfiHRGYRU V9/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6SWnNl436DSyxubacVFKb+zPzE9NFdRwUSRCjo4nEpQ=; b=AsIbbRb66I5sCkz2gdXCv2tjmqRI6AB6xBDAb1hw1AoGL2X8zFNX0GZ+ubFck7liaB chu8mJf+WYv7p6WHmtr4fPu73OZA2U+wkVgMUQ1pQgVUCXPcDNr4ntGwpsRAzN8Gv/aK 79yvo7LY7vcRHIg3aAq8ZBn9EEN8FMxbiRHH3Akx4nj3IQ3pkOOEt9BU+Rlj6nin4v5w nd1COaToa6WTsAdN6sPQpfsZK1qv30jIHn5i8nS0RyYIWyacLO242mf0cxuscQPd3nFD 6z0Lt2AuWx7/8FFrYrCx4TTemTe9Gw3rSYK6vCB9AYA1Ur4pVsXmc9Aecrn1FjpInR6k 3Bjw==
X-Gm-Message-State: AODbwcDd+EsX7ZZGnSljN3hwg1BJi3MpIWeTWAOGLzRevraT00uNom63 n9zFtHZGmRodTE41gsCYV+e70DjIFJgFyPdX/g==
X-Received: by 10.129.146.9 with SMTP id j9mr21168680ywg.283.1497194323557; Sun, 11 Jun 2017 08:18:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.215.144 with HTTP; Sun, 11 Jun 2017 08:18:03 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 11 Jun 2017 16:18:03 +0100
Message-ID: <CABcZeBNLo51y4-MYS6NTQn9OWg5jTYYpwxn1fiKKNL5bWA37TA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0928d4d0e4f50551b0b740"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HUUpDl7KUOGhcY_W_IC2vWRAot0>
Subject: [TLS] Closing on 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Jun 2017 15:18:48 -0000
Hi folks, We've had a phenomenal amount of discussion around 0-RTT anti-replay, and based on my recent summary e-mails I think we generally agree about the technical facts, so it's time to finalize the PR and land it in the specification. Here's what I propose to do: - Describe the attacks that Colm described. - Distinguish between replay and retransmission - Mandate (SHOULD-level) that servers do some sort of bounded (at-most-N times) anti-replay mechanism and emphasize that implementations that forbid replays entirely (only allowing retransmission) are superior. - Describe the stateless mechanism as a recommended behavior but not as a substitute for the other mechanisms. As Martin Thomson has pointed out, it's a nice pre-filter for either of these other mechanisms. - Clarify the behavior you need to get PFS. - Require (MUST) that clients only send and servers only accept "safe" requests in 0-RTT, but allow implementations to determine what is safe. Note: there's been a lot of debate about exactly where this stuff should go in the document and how it should be phrased. I think these are editorial questions and so largely my discretion. Here's what I do not intend to do. - Mandate (MUST-level) any anti-replay mechanism. I do not believe there is any WG consensus for this. - Design a mechanism to allow the server to tell the client that it either (a) enforces strong anti-replay or (b) deletes PSKs after first use. Either of these seem like OK ideas, but they can be added to NST as extensions at some future time, and I haven't seen a lot of evidence that existing clients would consume these. I recognize that nobody will be entirely happy with this, but I believe it most closely represents consensus. Assuming the chairs agree, I'd like to suggest a brief period of discussion on this proposal, followed by a consensus call, and then I'll generate a PR that enacts it. People will still have time to review that, but in order to avoid an endless round of dicussion, the idea will be able to review it for conformance to these principles, not to re-litigate these. -Ekr
- [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Dave Garrett
- Re: [TLS] Closing on 0-RTT Colm MacCárthaigh
- Re: [TLS] Closing on 0-RTT Salz, Rich
- Re: [TLS] Closing on 0-RTT Colm MacCárthaigh
- Re: [TLS] Closing on 0-RTT Colm MacCárthaigh
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Bill Cox
- Re: [TLS] Closing on 0-RTT Victor Vasiliev
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Bill Cox
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Joseph Salowey
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Colm MacCárthaigh
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Mark Nottingham
- Re: [TLS] Closing on 0-RTT Ilari Liusvaara
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Benjamin Kaduk
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Benjamin Kaduk
- Re: [TLS] Closing on 0-RTT Erik Nygren
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Sean Turner
- Re: [TLS] Closing on 0-RTT Benjamin Kaduk
- Re: [TLS] Closing on 0-RTT Eric Rescorla
- Re: [TLS] Closing on 0-RTT Salz, Rich