[TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)
Michael D'Errico <mike-list@pobox.com> Wed, 30 September 2020 21:03 UTC
Return-Path: <mike-list@pobox.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173093A0B90 for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 14:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=mike-list@pobox.com header.d=pobox.com
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 RbxZ_Imgq4gU for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 14:03:14 -0700 (PDT)
Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8453A0B8E for <tls@ietf.org>; Wed, 30 Sep 2020 14:03:14 -0700 (PDT)
Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 112421021F8 for <tls@ietf.org>; Wed, 30 Sep 2020 17:03:12 -0400 (EDT) (envelope-from mike-list@pobox.com)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=D9SnDrG/AeAe v0bOvlbZ12TKVGI=; b=mYtXD+X5y40+EnkbgU7p+ogV/OcUWCkMqrsdheZl2PMX r52e/zcjzTmaoMtVC1vYzp5vWTyPdr10aloAQOW1AXXcwzlHEvgrhwiRJUceAFls NwOoP/kdBnwVJnI/CWiow/ftZ+MRjsZKh/zW8nPqxnSeOZAKULz0nC1dfl+W0V4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Ug1ooO 2PiwG1cGlWTtot3ditv38WW8GRHv1nBpLNhvn0P9cPo+nIEC903T9LHur9ouMNzO syklDqQQ3zhrkiR/VS9xvEx+Yo01cicXsucXvWc6tFVkVdhNQs2X0h92Xxj1wPcT CLv8vP5qmxfd8SwRQ5MdPB5/eAzF26I4d3Lpc=
Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 0B57C1021F7 for <tls@ietf.org>; Wed, 30 Sep 2020 17:03:12 -0400 (EDT) (envelope-from mike-list@pobox.com)
Received: from MacBookPro.local (unknown [72.227.128.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 419A21021F3 for <tls@ietf.org>; Wed, 30 Sep 2020 17:03:09 -0400 (EDT) (envelope-from mike-list@pobox.com)
To: TLS List <tls@ietf.org>
References: <0c31f2d6-5f8e-2fd6-9a1a-08b7902dd135@pobox.com> <AM0PR08MB37164F2D0E0CE5FB6D62D461FA350@AM0PR08MB3716.eurprd08.prod.outlook.com> <1c7e2f31-8a9e-4bd8-9e80-ab18ebeb609f@www.fastmail.com> <CACsn0cmbDz3ML8o5moAacqfXqYQo-Hqi53XQL6UoGYcZBwy-Mg@mail.gmail.com>
From: Michael D'Errico <mike-list@pobox.com>
Message-ID: <5af9219e-8a61-bd3f-caf9-39c169ae4539@pobox.com>
Date: Wed, 30 Sep 2020 17:03:05 -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: <CACsn0cmbDz3ML8o5moAacqfXqYQo-Hqi53XQL6UoGYcZBwy-Mg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
X-Pobox-Relay-ID: 580A8888-0360-11EB-980B-F0EA2EB3C613-38729857!pb-smtp20.pobox.com
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QbteFvnk1H2K9OjfHGosuG9e9Rk>
Subject: [TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)
X-BeenThere: tls@ietf.org
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." <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: Wed, 30 Sep 2020 21:03:16 -0000
>> Anyway, back on the topic of stateless HelloRetryRequest, I >> don't see how this can work given that the client can make >> several modifications to the ClientHello which will invalidate >> the hash sent in the "cookie" (even if the client echos it back >> as required without modification). > The hash isn't used for validation, but for continuing the running > hash of the transcript to ensure that the negotiation isn't interfered > with. See section 4.4.1. There may be a problem here if you try to implement the stateless HelloRetryRequest the way the spec. implies (by sending a hash of ClientHello1 in the "cookie" extension). A non-conforming client can send an initial ClientHello1, which both client and server know so they can compute the hash correctly. The server puts the hash in the cookie of a HelloRetryRequest and sends that to the client. The client can then put together any ClientHello2 it cares to and include the cookie from the HelloRetryRequest. If the server is "stateless" and throws away ClientHello1, there's no way for it to know that the second ClientHello2 it receives doesn't properly relate to ClientHello1. The handshake can still go all the way to completion even with a bad ClientHello2, I think. Also the server can't be actually stateless since it needs to know the HelloRetry- Request message for the transcript hash, right? There are a number of changes allowed to be made to the ClientHello1 that will make it impossible for the server to recreate the hash sent in the cookie field, even when there is nothing malicious happening. Simply changing the padding extension is one of them. Pruning the key_share list is another, as is updating the pre_shared_key list. So it can't reject any ClientHello2 which it doesn't hash to the cookie value. I don't know what the implications of this are (I've only spent about 30 minutes reading the spec.) but there appears to be some room for mischief if a server is "stateless." Maybe this should not be allowed out of prudence? What does this mean for DTLS 1.3? Putting a pseudo-session-ticket in the cookie as NSS (?) does might solve this problem to some extent, but I doubt the extra processing is worth the tiny amount of memory saved by tossing the ClientHello1 under normal conditions. (When being actively attacked this may be necessary, though I don't have experience working in a data center so I can't really say.) However, the RFC should probably not be implying that you can do stateless HelloRetryRequest by sending a cookie with just a hash of ClientHello1 (even if the server uses some integrity protection mechanism on the hash value). Mike
- [TLS] TLS 1.3 Problem? Michael D'Errico
- Re: [TLS] TLS 1.3 Problem? Ben Smyth
- Re: [TLS] TLS 1.3 Problem? Michael D'Errico
- Re: [TLS] TLS 1.3 Problem? Richard Barnes
- Re: [TLS] TLS 1.3 Problem? Michael D'Errico
- Re: [TLS] HelloRetryRequest question (was Re: TLS… Michael D'Errico
- Re: [TLS] TLS 1.3 Problem? Hannes Tschofenig
- Re: [TLS] TLS 1.3 Problem? Michael D'Errico
- Re: [TLS] TLS 1.3 Problem? Watson Ladd
- Re: [TLS] TLS 1.3 Problem? Rob Sayre
- Re: [TLS] TLS 1.3 Problem? Martin Thomson
- Re: [TLS] TLS 1.3 Problem? Michael D'Errico
- Re: [TLS] TLS 1.3 Problem? Ben Smyth
- Re: [TLS] TLS 1.3 Problem? mrex
- Re: [TLS] TLS 1.3 Problem? Martin Thomson
- Re: [TLS] TLS 1.3 Problem? Michael D'Errico
- [TLS] Is stateless HelloRetryRequest worthwhile? … Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Martin Thomson
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Nico Williams
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Hannes.Tschofenig
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Salz, Rich
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Benjamin Kaduk
- [TLS] HelloRetryRequest question (was Re: TLS 1.3… Michael D'Errico
- Re: [TLS] HelloRetryRequest question (was Re: TLS… Michael D'Errico
- Re: [TLS] HelloRetryRequest question (was Re: TLS… Benjamin Kaduk
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Rob Sayre
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Salz, Rich
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Nick Harper
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- [TLS] Client attacks on stateless HRR? (was Re: I… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Nick Lamb
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Luke Curley