Re: [TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)

Michael D'Errico <> Wed, 30 September 2020 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB7D23A0CBA for <>; Wed, 30 Sep 2020 15:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KfIlv_GJKOMl for <>; Wed, 30 Sep 2020 15:54:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FEA93A0962 for <>; Wed, 30 Sep 2020 15:54:01 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 18E53102D62 for <>; Wed, 30 Sep 2020 18:54:01 -0400 (EDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=7aDe5R/AfNrq 64PISuSmfOC6/+8=; b=hDAj+x9iKXRsw/znrBO0eXCsV0yzvivZm8UNOGmm3qrX DZmGiLyghRCz3kTQQWtArc88nEPks4k+Yyd3wbzwGm/RE3xaCXSfS67ka1vSumVl VLUt7dw3Cmvzq4hp4/TuS+LnLvh3GOk4z7aX3pClbT9Iqgs+dOlDZ8VWP3ji5eM=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=QjTROL ARgZRlAdQeA5Og/c5qU3xsUB2HNv5i6VSg2lxxa9XyD2b1BjReo139gKLRtINDJQ zEndBMRhgM4Jg68zCpYMGgywpwyuJBzzDTlQflxWdrttZSSJE9I65JOKacqAQq0w Jp88phZ1y6WilUgKIDuONNypWgTL0OaIbcDVo=
Received: from (unknown []) by (Postfix) with ESMTP id 11222102D61 for <>; Wed, 30 Sep 2020 18:54:01 -0400 (EDT) (envelope-from
Received: from MacBookPro.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E55F3102D60 for <>; Wed, 30 Sep 2020 18:53:57 -0400 (EDT) (envelope-from
References: <> <> <> <> <> <> <>
From: Michael D'Errico <>
Message-ID: <>
Date: Wed, 30 Sep 2020 18:53:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
X-Pobox-Relay-ID: D2F56F68-036F-11EB-B8EC-F0EA2EB3C613-38729857!
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)
X-Mailman-Version: 2.1.29
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: Wed, 30 Sep 2020 22:54:03 -0000

On 9/30/20 17:34, Benjamin Kaduk wrote:
> The HRR is presumed to be a deterministic function of the
> initial ClientHello, and as I discussed in my earlier message,
> the server can reconstruct the initial ClientHello from the
> second ClientHello and verify it against the hash in the cookie.

I don't believe you can reliably always reconstruct the
initial ClientHello1 from ClientHello2.  Maybe current
TLS 1.3 clients are sending simple enough ClientHello
messages so this is possible today, but what about
next week, next year, etc.?

RFC 8446 lists on pages 27-28 all of the ways the client
is supposed to (or allowed to) change the ClientHello
that gets returned after a HelloRetryRequest:

    -  If a "key_share" extension was supplied in the HelloRetryRequest,
       replacing the list of shares with a list containing a single
       KeyShareEntry from the indicated group.

    -  Removing the "early_data" extension (Section 4.2.10) if one was
       present.  Early data is not permitted after a HelloRetryRequest.

    -  Including a "cookie" extension if one was provided in the

    -  Updating the "pre_shared_key" extension if present by recomputing
       the "obfuscated_ticket_age" and binder values and (optionally)
       removing any PSKs which are incompatible with the server's
       indicated cipher suite.

    -  Optionally adding, removing, or changing the length of the
       "padding" extension [RFC7685].

    -  Other modifications that may be allowed by an extension defined in
       the future and present in the HelloRetryRequest.

The only way stateless HRR could work (I think) is if you sent
the entire ClientHello1 and HelloRetryRequest-minus-cookie
encoded in the cookie somehow, encrypted, integrity-protected.
But a hash of ClientHello1 by itself just won't do.