Re: [TLS] KeyUpdate and unbounded write obligations

Adam Langley <> Thu, 18 August 2016 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 143FE12B01C for <>; Thu, 18 Aug 2016 12:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Balo6kZx50SI for <>; Thu, 18 Aug 2016 12:42:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7E1312B012 for <>; Thu, 18 Aug 2016 12:42:48 -0700 (PDT)
Received: by with SMTP id l2so26703195qkf.3 for <>; Thu, 18 Aug 2016 12:42:48 -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=VPnM2ewi0sKE9Mxw/sTGsswAz7wRcE+u9IHvFXyaA74=; b=ABLf07Mqf2HE3RrOiQiOMaIShrhflZzGtt6a5MdPQ2s6NT29Uq6cyBGFYqJYRWztUf N4D8RJVsLcBKBPOHCgUD2zK6VlyKLD6RGpMsx9m769S+fN+usjxknYp5SOMkWRgTrB/j Ydp9cUKQiQ6833CPuOpghYSHZFdOaq3XPDVtlYI7BGX2gsmFCtImQ6ozYlEvrnkdEuSY Z7BWUpntoKyaNnVePLxaW5qiQMAHcDPA2IKN86PBrIwiqQ2apz7UeNPUYxfY2uOgLZoZ 965V/2VSirNjcWbmEbQoyq1h58x6/tbNPjsRx1gI5dosVxK7qIbc89KapTcjVW4/ZHH3 sMsg==
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=VPnM2ewi0sKE9Mxw/sTGsswAz7wRcE+u9IHvFXyaA74=; b=R6t6IAmE5A8UKfqXnwdKiz1Td7S07dZ+CSmFxHbSbU2hTiRsWLq0svNItmzcgc0G6G vqReJRnMX5d65eKVgjn0PGCZwYpJHNkQx++chYGkaYMA5wtL2mU9oQRzh+B/qLeu8H3N FxzAVmZjdvAweY3px9FRcr7wMwFX+CK41vKoqmW1wtKhjD0mEo0ijKGWZlhY/3G0gfCi BpAs+tYgD8F3QorD2KGnP7I/UxqVsDj69WUHdnt2jwzeUSF+tExj7tnK+5KclN/HTQQv NIaAwTffW9ZDSk5ae86TywjcLrVd0L+wev4uSUb/rf/DErz5frjsbAy8R1p0W0bY4Pt+ 3tSg==
X-Gm-Message-State: AEkoous2xGBn/1tRVknLLcA+OUAPzbEUbICMk5gCyN3kEE7DD6Ea2RR+FnYPcAJTiV8vFja3RtemXY/HNMgH4w==
X-Received: by with SMTP id z17mr4422160qkb.186.1471549367910; Thu, 18 Aug 2016 12:42:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 18 Aug 2016 12:42:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Adam Langley <>
Date: Thu, 18 Aug 2016 12:42:47 -0700
X-Google-Sender-Auth: 0cMBKw0-yCijCrik_n71B99HLHw
Message-ID: <>
To: Keith Winstein <>
Content-Type: multipart/alternative; boundary="94eb2c05ba545807c3053a5dc96b"
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 19:42:51 -0000

On Thu, Aug 18, 2016 at 12:20 PM, Keith Winstein <>

> 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.)