Re: [TLS] KeyUpdate and unbounded write obligations

Keith Winstein <> Thu, 18 August 2016 20:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43E4012DB4B for <>; Thu, 18 Aug 2016 13:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WReD0l3t5OFM for <>; Thu, 18 Aug 2016 13:36:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 814F712D091 for <>; Thu, 18 Aug 2016 13:36:47 -0700 (PDT)
Received: by with SMTP id z10so9313175ybh.2 for <>; Thu, 18 Aug 2016 13:36:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jFELm4rta1M79ieJFAj06MO+/UqfbE34Srd3yOYNmdA=; b=DOHR84pcuBiuPYTbeAGOfEPaagxvYWXStvmnRtS4LMWz4JTK4BxNN6WpXWJSMZUtnc a2XbYOBuRwrS0NPndyHJy6pxI+JDZbJMAKOLjShzz6MQUfoC9LQ5sCUPAqwhBS5lwztK fzGCs5zmc9xv9tKB2zIVh79mvDaxFKUEDjoNZvOBWJHxEZ+e9vrIOowobKZjQEvlA1fD 8UkVwPnpTRiG1zRQPe6hFwyKAWzZCViXtQod4GT5Ad6YtroPgYbUYg5YZGzpcZfF8YoE MJSOnCZPoUKOyGsmsnLBmnYMF3/bXsH9JHw+6Hwm+IrxCnZ9A7ZH0+2E1NlPBjDXt2RA vn8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jFELm4rta1M79ieJFAj06MO+/UqfbE34Srd3yOYNmdA=; b=eRw2jP2Ju363RXikYxvPQ7U2Qj3pxS9bYeblmjSCVkMNBDFbiGaql8G97jym/TSj0B yPgcL6Kg0LG+gFbF+rDtG//diUDpaYFUuMF62g770RyZOvGVNygfQ0SqdA4DHKoBfhgw Lw2QRgBzx/e0+kWBxhR0m7yMBX8x0QJDh5R2etqIud5Sn9QR63Sh/eblkod+zIlheNMW so6nJZG8/u/OWhBpGsEKRzMEe3jp+3iE/lqJKsqWgW1g/Q1YiHuxRLPBTzCbfkRQrrg8 hAMu8RPeqBDSJnvCTmjV+mXfoQpUaL8yKfII+Li0xk/ZYTANNbgm+l5tX/vFG++Nit76 nc8Q==
X-Gm-Message-State: AEkoouvM9HchC7n2tqrT05C/XR/iOTQdV4UVY7gYVeAhBjIdIkDUuwa9sQoCPBtOOHEmE5zBfHpRNNGICfYWhA==
X-Received: by with SMTP id x32mr3199850ybh.156.1471552606697; Thu, 18 Aug 2016 13:36:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 18 Aug 2016 13:36:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Keith Winstein <>
Date: Thu, 18 Aug 2016 13:36:05 -0700
X-Google-Sender-Auth: 1wVraP9nk13uLvEm4HvjZLuu25U
Message-ID: <>
To: Adam Langley <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] KeyUpdate and unbounded write obligations
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: Thu, 18 Aug 2016 20:36:50 -0000

Okay, this is a different question -- whether P3 is a valuable property or not.

I made the case for this in my Monday thread[1] and in my Berlin



I'm happy to make the case for P3 here again but didn't want to hijack
David's thread. My claim here was that there are some simple designs
that satisfy everybody and grant P1+P2+P3+P4, and that David's
concern's and my concerns are "basically orthogonal issues."


On the value of P3, I think you're giving us a crimped reading. We
gave three use cases in Berlin and in my email:

- An embedded device may wish to fully rotate the session keys before
going to sleep.

- A paranoid device might fully rotate the session keys before closing
the session. (If confirmation is absent, the device might use a
higher-level mechanism to forcibly log out all open sessions from that

- An endpoint that wishes to permit a read-only virus scanner or IDS
will want to fully rotate the session before sharing the directional
keys with the middlebox.

On this last use case, I agree that incumbent IDS vendors may not be
eager to support it. But adoption would probably come from a different
direction. IoT devices today forbid anybody, including a middlebox
controlled by the device owner, from auditing their own traffic and
seeing what the devices are sending and receiving. (Unlike a browser,
they don't let the user add a private CA cert to be able to MITM.) In
my conversations with IoT device vendors, some expressed interest in
allowing device owners to grant read-only access to themselves. I
really do think this would be a good thing.

Unlike Heartbeat, we are not talking about an ack that would be
generated by something, and we're not really talking about altering
TLS's design. We're talking about piggybacking one field in a protocol
message that is going to be sent anyway, where the message (KeyUpdate)
is new in TLS 1.3 anyway.

As I said, it is orthogonal to David's issues here. Yes, it is
possible to get P1+P2+P4 by themselves -- P3 has to live or die on its
own merit. But it is really just one piggyback field to get it.


On Thu, Aug 18, 2016 at 12:42 PM, Adam Langley <> wrote:
> On Thu, Aug 18, 2016 at 12:20 PM, Keith Winstein <>
> wrote:
>> Yes, you need current_receive_generation, or something like it, to get
>> P3. This is the subject of our PR #426/580.
> The KeyUpdate messages are encrypted and thus sequenced with all the
> application data. Apart from the Heartbeat message (TLS 6520), which has not
> been significantly used in TLS (I think), we've never worried about a
> TLS-level ack before.
> PR 426 wants a way to retrospectively disclose keys to middleware and wants
> to make sure that the receive side is no longer going to trust those keys
> before doing so. Having spoken to several vendors of these products in the
> past and tried to persuade them to accept read-only access I don't think we
> should alter TLS's design for that unless there's a novel argument about why
> they would ever accept it. (Because they won't. Their competitive interest
> is to have as many "features" as possible, many of which would require
> modifying traffic.)
> Cheers