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

Luke Curley <kixelated@gmail.com> Sun, 04 October 2020 20:35 UTC

Return-Path: <kixelated@gmail.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 7614A3A09F0 for <tls@ietfa.amsl.com>; Sun, 4 Oct 2020 13:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 Loa5IPtCkNzu for <tls@ietfa.amsl.com>; Sun, 4 Oct 2020 13:35:12 -0700 (PDT)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 8D25E3A09E9 for <tls@ietf.org>; Sun, 4 Oct 2020 13:35:12 -0700 (PDT)
Received: by mail-oi1-x22d.google.com with SMTP id t77so3329543oie.4 for <tls@ietf.org>; Sun, 04 Oct 2020 13:35:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xSRYRk1aecAqDzpoteq1OlJ6BjFYHaFmdzx5+gj52as=; b=jsovdOegGRVE8cW2urS0tEgDLjlcGEfWVg0Is/c0/JYX5n9TDoIpQkgLjRvTBrcfXy fBj12ahKGVnL5mjv+8K22EM2/HtfISmWwBeMOLTB+YEY0fVXpb3fvTm6TJlUjxoLrGuO QHtoZoDRhcnhpk3rAAejEww0CI8qR0BQyRc943A0gzdDs8CbiWn3dJVXWsgy2t0zg7Rk v7mG1Y3erNc16gtWftDNy1hVuoN1nyYvMcCTV/c8CkaPriXLPsRnq4pcz4i3c10x39r2 siTxKuGSazEa500YV14m2HPbPiqItGCRBFXBud7iey5radZeY7zVTmHyHcxjGkmWnp5Q 1CpQ==
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=xSRYRk1aecAqDzpoteq1OlJ6BjFYHaFmdzx5+gj52as=; b=J7Dpd/g+aqR1PZ5MpHureenPeiLXICHPPRDpHpp+4yFoKw10TKIAGOL4DXa0b4FEQj aqyfj77gK7w6xd+LFsQ65EE7q2RPdDWI75lqSCqvsrxmIpUiQ80DQLvtPu6y1JKJxOJq V+x4iVNKbfqNuQcvupbtqlPZkbJ/4x/By6pNwgbv+VtFMEZl0sbQqQULlJ6kY2ihYIia o08GvEe7DvXxEt4LL+cKKtxbzFcj8EaOFNYMxJd7A+64R32IBxGeWOOd1ddDe58lBscI JRWOQAeaZCw1WSYQAzlg5UJwOz+MLHaeKsCC3MpS4v7ngqppWXz+ZU9Cvh306SCjJry/ enOA==
X-Gm-Message-State: AOAM530J+9gpQ1RFpblmL45FUG+fa4p1I0nImZKmWwe6BtdO0LNcho5E q3oCrWRj93cgfu8w5Tgh+hcKe4m6FKJevKYiO6Q=
X-Google-Smtp-Source: ABdhPJzamJ2gy4bFjisq41RHyxyKuT4o1/4cecFRtJwNNz/6i+sT4kqXImt+SNh82fs66MHZr2vZWJYAbMUkYWeqGCw=
X-Received: by 2002:aca:1e08:: with SMTP id m8mr6479463oic.168.1601843711612; Sun, 04 Oct 2020 13:35:11 -0700 (PDT)
MIME-Version: 1.0
References: <0c31f2d6-5f8e-2fd6-9a1a-08b7902dd135@pobox.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> <CACdeXiKo37pUc9J+wMaM8119uMAUCqURRk+2qyGJi_v49twSCg@mail.gmail.com> <a574e534-235e-4202-9046-fb5cd18cce7c@www.fastmail.com> <20201003211257.31450138@totoro.tlrmx.org> <9d504880-72c4-e6bd-7d7b-e809d739b09d@pobox.com>
In-Reply-To: <9d504880-72c4-e6bd-7d7b-e809d739b09d@pobox.com>
From: Luke Curley <kixelated@gmail.com>
Date: Sun, 4 Oct 2020 13:35:00 -0700
Message-ID: <CAHVo=ZnHMnveSjiwwyB8ys8S2BejpFnBxRRPH=zVWzDgAuqPng@mail.gmail.com>
To: "Michael D'Errico" <mike-list@pobox.com>
Cc: Nick Lamb <njl@tlrmx.org>, tls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006a98d005b0de4de4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dPKZI5RXdAAb6mH8PhuOWnw1-1o>
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: Sun, 04 Oct 2020 20:35:16 -0000

Mike,

The server receives a ClientHello from a prospective client. In the case of
DTLS and QUIC, this path has not yet been validated, so the server may want
to verify the remote address prior to continuing the handshake. This is
incredibly important as generating key_shares and signing the transcript
are not trivial operations and make for a very easy DDoS attack.

The server hashes the ClientHello message and generates a random cookie. In
a connection-oriented setup, the cookie is just a random challenge. In a
semi-stateful environment, there's a lookup table from the cookie to the
ClientHello hash and no other state is stored. In a stateless environment,
the cookie might be an encrypted payload, containing the ClientHello hash
plus any additional information.

This is primarily designed with load balancers in mind. The connection is
validated by front-line load balancers that mitigate DDoS attacks and
distribute "safe" connections to backend servers. These load balancers deal
with an enormous amount of traffic and must be simple: 1) reply to
ClientHello messages with a HelloRetryRequest and 2) assign and forward
valid ClientHello retries to a backend server.

The original ClientHello does not need to be stored, as the HRR contains
the information required to continue the handshake. The backend service can
use the cookie to either lookup the CH hash in a shared database, or even
better decrypt the cookie using a shared secret to get the CH hash. Now the
handshake can be completed like normal.

I definitely agree that the benefits of HRR are not made obvious in the RFC
and I thought it was weird too. I wouldn't have hashed the hash of the
ClientHello, but it makes sense given most languages don't allow storing
the state of a hash. The design decisions make sense for services at scale
and require minimal effort for hobby TLS 1.3 implementations (including
mine).

On Sat, Oct 3, 2020 at 2:05 PM Michael D'Errico <mike-list@pobox.com> wrote:

> On 10/3/20 16:12, Nick Lamb wrote:
> >>>> You can't possibly implement [stateless HelloRetryRequest] the
> >>>> way the spec suggests with just a hash in a HRR cookie extension.
> > Lots of people have and it works just fine, so it seems to me that "You
> > can't possibly" here means something closer to "I still don't
> > understand how to" and as such would be more appropriate to some sort
> > of programming Q&A site like Stack Overflow than an IETF working group.
>
> StackOverflow has only one result if you search for HelloRetryRequest
> and it is about jdk.disabledAlgorithms.
>
> When you say it "works just fine" I think you are saying that the
> handshake will complete.  But is it secure?  This is the important
> parts of "works" and I'm not sure it's possible to do it correctly
> without a lot of work, and am certain that a hash is not enough
> information even if it's integrity-protected.
>
> > The client MUST use the same value for legacy_session_id in its retried
> > ClientHello. As a result this value will be available alongside the
> > cookie.
> >
> > Section 4.4.2 is clear that a hash used this way in the cookie should be
> > "protected with some suitable integrity protection algorithm". For
> > example some implementations use an HMAC construction, but you could do
> > other things here successfully. So in fact this is not especially
> > optimistic.
>
> All the integrity protection bytes tell you is that the server did in fact
> generate the cookie at some point in the past.  You don't even know
> how old the cookie is if it just contains a hash, unless you are
> frequently changing the key (and keeping the previous key around for
> a bit to cover the case that the key rollover happened within the life-
> time of an old cookie).  A client could possibly exploit this by making
> many connections and sending a second ClientHello on each one with
> the same legacy_session_id_echo and cookie.  A stateless server might
> not be keeping track of whether a cookie is being reused, and why
> would it if it's actually stateless?  If it's going to go through the
> trouble
> of keeping track of previously-used cookies, possibly across several
> distributed machines, why not just be not-stateless and avoid all of
> the hassle?
>
> And, yes, it is optimistic to trust a client to do the right thing. It's
> also
> dangerous.  I used the word optimistic to downplay the significance.
>
> Rebuilding the beginning of the transcript hash based solely on what
> the client sends in its second ClientHello message is fraught with peril.
>
> Mike
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>