Re: [TLS] KeyUpdate and unbounded write obligations

Keith Winstein <> Fri, 02 September 2016 09:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5550F12D531 for <>; Fri, 2 Sep 2016 02:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 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, 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 T2ugzVwHVYKU for <>; Fri, 2 Sep 2016 02:24:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6C7812B046 for <>; Fri, 2 Sep 2016 02:24:27 -0700 (PDT)
Received: by with SMTP id g192so8201642ywh.1 for <>; Fri, 02 Sep 2016 02:24:27 -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=YyKPk9JpTYmZ3/R7uLtPPCKjOrLBlORaAib7Fb6XFLs=; b=PmjCu1iaE6DQMqcUu4QKFwZ8xsf5Ec5pJRFm8YqkMjT/u+0rFsXhEPNaLsLyFlLDCm iPeA1BpJUrnLNoVl8pdOFmULJvYWsX4sKd6MoY1bfRUeuO3LrBomjd/cT4gU6RQCFsPJ Te+x1bSnr56OgvVJqNWGRxOsHfj2o6Wl1Sr3NbXfT/pFTuxEOzF/oeAH2QV7XO6cAgp0 /FzlKL19bMGKPMsFjwkmydCJ0wZgCW/YDQu5XudGuj3cIHIsOyxjBVgUMCInpPvLPts9 u3RATtEdsRmAye9dBc4lCCKZ2eT7jvpQWB9g/hwduZ98reuaZNERiE1xFLLRwbmvcpIc huAA==
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=YyKPk9JpTYmZ3/R7uLtPPCKjOrLBlORaAib7Fb6XFLs=; b=GS+7oC4hnoVDtadtXEMTG4SlNCqMcvWCDYcnGAx/JIRrThXhgxmZGTxDYe8qr7rTIN aPoEYfsx/dd3kuBGWeOXTdHcnUYvupISHNHmZRZYJLX/I1R6jPh5UEdt/nahnylZFAEx V6CGEMTosgnvMRgHK56YD5OTihVJf08h8XJGD2HS7+KMm8x6ikv77sisrEz3S+5jsCnr i3x0C5BkegzpkFk7xxkrU2jYH0KZvAl4gdKBVSLAsv379byhd5/qeSyhcck0B1nSmLF4 d6qtq/Md01MwjuMT7TfkIyC1tnrWwassHMdws1DmhCHawd0+c5ogUgPgYodqwsIMJ3kF umvg==
X-Gm-Message-State: AE9vXwPH9q3ALbO78EOIg5F6rNJmwFhDUW4/587wfJpkJYT0+u9jwk/JYUsEy9DL4daSq1zJWdfWixJDg0zeHw==
X-Received: by with SMTP id q190mr18486526ywe.26.1472808267053; Fri, 02 Sep 2016 02:24:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 2 Sep 2016 02:23:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Keith Winstein <>
Date: Fri, 02 Sep 2016 02:23:46 -0700
X-Google-Sender-Auth: uMOxxLIbnOPvmqUK6-KJUlJ6gdY
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
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: Fri, 02 Sep 2016 09:24:30 -0000

You seem to be raising a complaint with my option #1, the "1-bit" option.

You're correct -- in that scheme, a node can only assume that the
other side has read as many KeyUpdates as it has gotten in response.
If the client decides to send KeyUpdates every 5 minutes, but the
other side is only writing every 10 minutes and coalescing its
responses, the client's knowledge that its KeyUpdates have been read
will get further and further behind. In the interests of compromise, I
think we would say that in situations where the other side is only
writing very infrequently, we would just give up on trying to get
assurance that a KeyUpdate got read, since it was probably not very
useful anyway. (The other side might never write to its socket ever
again! Then it really is hopeless under any scheme.)

Obviously if we had our choice, we'd prefer a 7- or 8-bit field
(options #2, #3, and #4) or a 64-bit field (as in PR #426/580), all of
which address your concern. But, trying to get to consensus here.


On Fri, Sep 2, 2016 at 1:42 AM, Ilari Liusvaara
<> wrote:
> On Thu, Sep 01, 2016 at 02:11:13PM -0700, Keith Winstein wrote:
>> I think we have to oppose a change to KeyUpdate that adds P4 (bounded
>> write obligations) but not P3 (ability to learn that a KeyUpdate was
>> read by other side). These are orthogonal and easily achievable with a
>> pretty small tweak. Here are four options that would work for us:
> Unfortunately, one can get into situations like this (saw this
> in testing):
> 1) Client send KeyUpdate[req=true] (and continues blasting data)
> 2) Server receives the KeyUpdate[req=true]
> 3) Server queues a KeyUpdate[req=false], it gets stuck.
> 4) Client send KeyUpdate[req=true] (and continues blasting data)
> 5) Server receives the KeyUpdate[req=true]
> 6) Server quenches the KeyUpdate, since it has fresh keys.
> 7) Client send KeyUpdate[req=true] (and continues blasting data)
> 8) Server receives the KeyUpdate[req=true]
> 9) Server quenches the KeyUpdate, since it has fresh keys.
> 10) Server sends something, the KeyUpdate gets unstuck.
> 11) The client receives the KeyUpdate[req=false]
> Considering those KeyUpdates are triggered every ~5min (by volume
> trigger[1]), effective RTT was something like ~10-15min (despite sub-
> millisecond transport latencies). And the 1 server-sent KeyUpdate
> was in reaction to first client KeyUpdate, not the last...
> [1] Set at 10,000,000 records (even for 0x1303, which can handle
> far far more).
> -Ilari