[TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field
Judson Wilson <wilson.judson@gmail.com> Fri, 26 February 2016 09:27 UTC
Return-Path: <wilson.judson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F397E1A0110 for <tls@ietfa.amsl.com>; Fri, 26 Feb 2016 01:27:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 oCv3FVl77y8x for <tls@ietfa.amsl.com>; Fri, 26 Feb 2016 01:27:49 -0800 (PST)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 684611A010B for <tls@ietf.org>; Fri, 26 Feb 2016 01:27:46 -0800 (PST)
Received: by mail-io0-x22e.google.com with SMTP id g203so116542705iof.2 for <tls@ietf.org>; Fri, 26 Feb 2016 01:27:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=gsv/IgNYRm72ERo5v7M6ZFpTptbiQO4g3HRFxat6apg=; b=m7BaF/RP2/nMGPHhHFOnSsFLluTCkfjbKVIXvOZvMz5+EGMWQ2V0rNfbyEXNFOCvHP jvoTCy+WM7DBu5lPwbLPknInQKq9Z8DIomQO2voL0Qm5r4WkzfL/MX7irqk3u5tjOVNF Sh2Dv7LSi1ghNL3qF3rizh7FMcEdwIW108aWpXYx7q8Ij9fMF000nvh3hOoo3rRbXKxh oCoc3s09oyQMFQMYev7Uoo0IfJRKPM1q6QEv67zEXw0RgIn+bQQ7LpSRydA/6Nk912n8 FTVuHhumX02PXK/OOHT/+McMwPKZvzq7hPf1CwTCdqP9yP6NFT2edBUyPKNvbJLacs5f l5gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=gsv/IgNYRm72ERo5v7M6ZFpTptbiQO4g3HRFxat6apg=; b=cuvzO8nsiMQwl4J9BPj+6Gp49TYzH6/6f2rSA776FPwxHemTiAH7Yz7OIEdtUYcTd6 7En5BkFMANRTTv51eBFGV+nnL217lCuIIJb7re1sDIGgI5kuFNuvZ2nN1UVMF3C6a58F zMjCPF+spxhXOxCDgPA8tgozKn3xiNTqUIBD2sPywUZnrXwtVrdETUq1MMqGxwayCDO5 T69GY3P8XMpL+gE7LaZDW5Tw5zp48R8uLjvSSY3xxXGwegNLX2kd6oqqnkKAnh0oyKFn 9q5jSl7iez5huYXuHdWgv+ZzetYWyWYI9027kvwPoA/4AmFVhV0XJ+15cFlkh8spuLPO k5Rw==
X-Gm-Message-State: AG10YOTP1sEUovrqekgW/gB+ia/SdThHnsFNSMv0EZZ8EYb51mumo4Gg65yVONzBhqo9LLRP/8xT6CKAYFxGyA==
MIME-Version: 1.0
X-Received: by 10.107.131.206 with SMTP id n75mr7168082ioi.189.1456478865813; Fri, 26 Feb 2016 01:27:45 -0800 (PST)
Received: by 10.64.156.234 with HTTP; Fri, 26 Feb 2016 01:27:45 -0800 (PST)
Date: Fri, 26 Feb 2016 01:27:45 -0800
Message-ID: <CAB=4g8Jp-04RQKSXDpos5PczdFfMU8bEv242qzf1HnC=aP0F2Q@mail.gmail.com>
From: Judson Wilson <wilson.judson@gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a113ed3586b770d052ca8e9d5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/r6mqLr5SilIxRFGZbt4UMGleTno>
Cc: Dan Boneh <dabo@cs.stanford.edu>, Philip Levis <pal@cs.stanford.edu>, Judson Wilson <judsonw@stanford.edu>, Keith Winstein <keithw@cs.stanford.edu>, Henry Corrigan-Gibbs <henrycg@stanford.edu>, "Riad S. Wahby" <rsw@cs.stanford.edu>
Subject: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 26 Feb 2016 09:27:51 -0000
Hello folks, We'd like to add a field to the KeyUpdate message that represents the generation of receive traffic keys in use by the sender of the KeyUpdate message. (Our pull request: https://github.com/tlswg/tls13-spec/pull/426) How this helps: In the current draft, an endpoint that sends a KeyUpdate message and later receives a KeyUpdate message cannot know whether the other side has actually updated its receive keys. The two messages may have been generated independently and crossed in flight. Putting a receive_generation field in the KeyUpdate message lets an endpoint confirm that the other side has received and acted upon an earlier KeyUpdate message. Why we want this: We've been researching how to restrict corporate middleboxes like intrusion-detection systems and virus scanners. Today, these scanners generally demand man-in-the-middle access to TLS traffic and require users to install a private root CA. We think it would be better if they only had "read-only" access and didn't MITM the traffic. One way for a client to grant delayed read-only access in TLS 1.3 is with a "rotate and release." The client starts by sending a KeyUpdate. Later, after all traffic keys from the previous generation have been superseded on both sides, the client releases the (superseded) traffic keys to the middlebox. The middlebox can use the keys to decrypt the previous generation of ciphertext, without danger of compromising the integrity of the session. The challenge is that an endpoint can't safely release its old send keys until it knows that the other side has updated its receive keys. Hence the receive_generation field. We think this is a pretty lightweight way to resolve the ambiguity from KeyUpdates crossing in flight; it doesn't add any blocking, waiting, or extra rounds or messages. Thanks in advance for any feedback. Sincerely, Judson Wilson (+ Henry Corrigan-Gibbs, Riad S. Wahby Keith Winstein, Philip Levis, and Dan Boneh) Stanford University
- [TLS] TLS 1.3 PR #426: KeyUpdate message: add rec… Judson Wilson
- Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Ilari Liusvaara
- Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Eric Rescorla
- Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Philip Levis
- Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Ilari Liusvaara