[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