Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)

Nick Harper <nharper@google.com> Thu, 01 October 2020 21:09 UTC

Return-Path: <nharper@google.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 044633A097A for <tls@ietfa.amsl.com>; Thu, 1 Oct 2020 14:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Nw2kq_7eS9bI for <tls@ietfa.amsl.com>; Thu, 1 Oct 2020 14:09:08 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FA83A0975 for <tls@ietf.org>; Thu, 1 Oct 2020 14:09:07 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id m12so153282otr.0 for <tls@ietf.org>; Thu, 01 Oct 2020 14:09:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FU2YcU128V3QPhSMdMI8Vic37085FT42kjv/uSpfVJU=; b=eJfBQ1Zji/fwkMaOno3DUGloILZ3gNnfLo7qM5nf+y5z0Z9r2GZQLv+Tuhgx3GudDp X2pdGSVJZMtjR5MKGXNEAHW4DuBLDS9Vr6cGX/krm82KcFztTc36PfUl/w8A4NeapqUX b5cd1eTnYCB0aO4seVoWXYaKB7JOX1zLuNwMtzcYyzjniX5B6n1hlhmGixhVI3eKrica TUHPMJ0d7QR+P/815FQCAI20u1ya7+WyImpu2zliAYQXWHsN3tNlHuXwT5R4+4434yAf 7MbSuteJZXI/wggDemOaJbt98+LrhWt1fOBAqE3edsu1Fu4crbEIUX2nDyvyHft/zd3b qZVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FU2YcU128V3QPhSMdMI8Vic37085FT42kjv/uSpfVJU=; b=qJmKUwQRZDQFesA32CrpbxGQLQP6vjasF8Luc9ZHlwafI99if5MPtuoeuFIvQ1sPRv B5nTFMEIrxBlePZDM9EaaTt/sFybZqyhmHCFsJnC6wNkD84kiArMd4UKUV+FedXeDSiu /CrDZ3qVe++VqUY8Q34Vx+VXoq6PlLoWve+xHLOqXP9H931z92Wv0vQesY8OKWFTFFKL QoD14FZfdV2Uc/cDzrYYdeyX3lA29qerHC8Z9D9QY0XTvLonwxQBa4VNPhX0eqAi4kU9 aPjUjAFrAITr3axNMEbNV4agOdFhOBjmSvfr/3Dxg6+rbHk3Ky/Z4sGzhyVUTHd7Tf4+ eN/Q==
X-Gm-Message-State: AOAM530t/jggbqNTfvHkHRLId5cjY4IVibowlcgqpgve1JzdGcn7z3Ee JT8sh5pYnirgVPGW7GLj+FwtGQ1n/2jY9a4UdWkBBHpjmR/vhMN4
X-Google-Smtp-Source: ABdhPJxMTK+xY8vKcr4M5ubMrCEJ2ircwOIm4xkunm8CmIUY7csffFFAVP/NFuHNo43FYbFCzNjB0+xiEmrazILqFMs=
X-Received: by 2002:a9d:5a0b:: with SMTP id v11mr6300049oth.347.1601586546859; Thu, 01 Oct 2020 14:09:06 -0700 (PDT)
MIME-Version: 1.0
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> <96777977-7707-4311-9876-ca3d53f57f3e@www.fastmail.com> <9b2bb784-5895-bc8a-fae5-1c2056972f97@pobox.com> <eaace566-4fe2-4e86-8382-e0583ce43435@www.fastmail.com> <24f5cd7e-4fff-ce47-f9d9-840dff3f23aa@pobox.com> <3b48fa2d-f923-40ee-a93f-e0896a96fc1b@www.fastmail.com> <ba70c2ba-9023-4cc8-974a-01a64a60de2d@www.fastmail.com> <82488341-a4c6-2ed9-d8e2-6479151a5f90@pobox.com> <03ba01d6974e$ffaefe30$ff0cfa90$@gmx.net> <76c30176-f3bf-cc8f-74fb-b875d66e636f@pobox.com> <ABC80E3E-4C18-4290-B13E-50EDC129566B@akamai.com> <bc6251b7-681f-407a-9e30-dc2a430edeaa@www.fastmail.com> <CAChr6Sy_UG2Z1sOvvQSOetkJ5HGUea2SaSAN+kEJu4X-5MeQJg@mail.gmail.com> <2d9ee8e6-892b-4070-8e87-4902e53a5f70@www.fastmail.com>
In-Reply-To: <2d9ee8e6-892b-4070-8e87-4902e53a5f70@www.fastmail.com>
From: Nick Harper <nharper@google.com>
Date: Thu, 1 Oct 2020 14:08:55 -0700
Message-ID: <CACdeXiKo37pUc9J+wMaM8119uMAUCqURRk+2qyGJi_v49twSCg@mail.gmail.com>
To: "Michael D'Errico" <mike-list@pobox.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000034373305b0a26dca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UFsXQttMxev8rPsKqM8QZ1NsXIQ>
Subject: Re: [TLS] Is stateless HelloRetryRequest worthwhile? (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: Thu, 01 Oct 2020 21:09:16 -0000

On Thu, Oct 1, 2020 at 7:05 AM Michael D'Errico <mike-list@pobox.com> wrote:

> > I am having a difficult time understanding the tradeoffs you're facing.
>
> This is the first time I'm reading the TLS 1.3 RFC.  I have
> implemented SSLv3, TLS 1.0, 1.1, and 1.2.  You may have
> used my test server at https www dot mikestoolbox dot
> org or dot net to test your own code.  It's kind of old now
> since it doesn't do ECC and the DHE_RSA key exchange
> I focused on has been disabled by most clients so you
> end up getting a regular RSA handshake now.
>
> I have gotten caught by the stateless HelloRetryRequest
> and can't get past it.  You can't possibly implement it the
> way the spec suggests with just a hash in a HRR cookie
> extension.


The only thing the server needs to know is the hash of the ClientHello (so
it can restore the transcript hash) and that the server has already sent a
HelloRetryRequest (which it can detect by presence of the cookie). The only
argument I've seen made for what the spec suggests not working is being
able to verify which fields changed between ClientHello1 and ClientHello2.
I see no language in RFC 8446 that the server MUST enforce that the
ClientHello2 is conformant with respect to ClientHello1. Thus, I think what
the spec suggests should work.


> If it can be done at all, the stateless server
> should probably just put the ClientHello1 and HRR (minus
> the cookie) into the cookie extension.  If this is how it
> should be done, then the spec should say so -- exactly
> how to do it so everyone does it the same (correct) way
> and not just hand-wave it and say figure it out yourself.
>
> Getting the cookie right isn't enough because of the
> potential for resending an old cookie by a mischievous
> client.


The cookie serves as an alternative way for the server to remember the
ClientHello1 sent by the server. If the client is trying to perform some
sort of attack on the server by re-sending an old cookie, I assume that a
prerequisite for this attack is that the TLS handshake succeeds. For the
handshake to succeed, the client needs to know the ClientHello1 that
corresponds to the cookie so that it can compute the transcript hash
correctly. Regardless of the source of that client hello, the client can
equivalently send that ClientHello, get a real HelloRetryRequest from the
server, and send its ClientHello2, or it can send a ClientHello with the
cookie, bypassing the step of waiting for the HRR. A client attempting to
do something malicious with an HRR cookie is equivalent to behavior that
does not depend on a cookie.

>
> Mike
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>