IETF Logo Mail Archive

Re: [TLS] Don't Split HelloRetryRequest

Christopher Patton <cpatton@cloudflare.com> Thu, 01 April 2021 18:20 UTC

Return-Path: <cpatton@cloudflare.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 559B13A1E0C for <tls@ietfa.amsl.com>; Thu, 1 Apr 2021 11:20:32 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=cloudflare.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 qncRPvtXA0vI for <tls@ietfa.amsl.com>; Thu, 1 Apr 2021 11:20:28 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 EFE3B3A1E08 for <tls@ietf.org>; Thu, 1 Apr 2021 11:20:27 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id y5so3108354qkl.9 for <tls@ietf.org>; Thu, 01 Apr 2021 11:20:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YvlWgJDJ6dp75+u0NH1kkgqmNqYUu6Z+r7oHR8Kuu1w=; b=Q0mM6D4plyYhcMWXt+JLK6bEOZ+01VWAHMxZu1BA16K5InCu1zxTHS11wNJwE37SH5 KakMvTqeyVzCmjV+byiAopKhxCq8CbFQiJWYRfJGaeGhMxpQ3wffsQ2XhtIsZn7sE/92 WhTuc1lQiCz+y0Z3yTox52UaE5X3V+lnUe+J8=
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=YvlWgJDJ6dp75+u0NH1kkgqmNqYUu6Z+r7oHR8Kuu1w=; b=Jo9ncAdJyIYYcBAHaATeZ7DGgLNCX/9X5SDLJI0+ndNVkU9VmYnNbWW9MNIlLgW/y4 JKZSbEQnrWo5squXNGtOAGySu49Vvf1mna7JV7i9CbuJtnyh6Tm7TUdgefknGnOdb4yz G/ueIWPV/sjpr2Y/MOVoo+Rz+ScRKyfHuZB1jCmLhkziZ76qI9bvMDw55FteuEQv0vcY xVQ9cjKxiWRJkk2o5sDWELIklSlgueZgQAST6JSKWcAJVzLZwCHnhpvJrV3Zt55JFi8r BfyT/Kt/CqQnDQQYvD0peRk0qBOJoVbwmnVjkIkVKL498PnnbZPjCiUc6BqQS4obKzLL CmhA==
X-Gm-Message-State: AOAM533T1+330iWNT/aqIfMFSoDZeID2cDT07VSD1cRsLueCuE75wa/n F1JcgC9bg/w4OqAZPyKqsiClo8zLAcay0+NeBdZcrw==
X-Google-Smtp-Source: ABdhPJwbbU5y+r4uXgbz7+aleXUbUQGq2oVY3KH5Z+8RnQzxFU7fP5yFqgXnQcmKDxUSmAoDrKqGwRdAlaGTqbznupU=
X-Received: by 2002:a37:a38e:: with SMTP id m136mr9623366qke.250.1617301226261; Thu, 01 Apr 2021 11:20:26 -0700 (PDT)
MIME-Version: 1.0
References: <d0758a0a-737b-40ac-8189-1b4168510859@www.fastmail.com> <CAG2Zi216sYnwmZFdHxnMC+8vP0Ewr7tBr0TBc2PKkpJsgRFjiA@mail.gmail.com> <8f69f37e-b011-85a3-cd76-75cff00156a2@cs.tcd.ie> <CAG2Zi229wAWC8NLuN_1h6KQiBRzxvA-NQN8obdoSbfAUL+713A@mail.gmail.com>
In-Reply-To: <CAG2Zi229wAWC8NLuN_1h6KQiBRzxvA-NQN8obdoSbfAUL+713A@mail.gmail.com>
From: Christopher Patton <cpatton@cloudflare.com>
Date: Thu, 01 Apr 2021 11:20:15 -0700
Message-ID: <CAG2Zi23GOs7KvvZ-digueTOARCZa87hXeKac22GbbPDgpdXF+Q@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Martin Thomson <mt@lowentropy.net>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001638b205beed49d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0R4OC6FrsdCoGzf_UErTmvGjVKE>
Subject: Re: [TLS] Don't Split HelloRetryRequest
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 Apr 2021 18:20:32 -0000

One way HRR is used is in case the client's and server's cipher suite
> preferences don't intersect. This feature is an essential part of TLS, as
> there's no a priori reason why the client and server will initially
> advertise overlapping preferences. (They usually do, hence the claim that
> HRR is rare.) I don't think aborting the handshake instead of HRR is an
> acceptable solution, as this would mean there are deployments with which
> TLS couldn't be used.
>

Slight refinement: David B. pointed out to me that "cipher suite
preference" isn't quite the right term here. The client provides key shares
in its CH that it guesses the server can use; if it's wrong, then the
server replies with HRR. A more accurate statement would be that "HRR is
essential for ensuring the client sends a key share the server supports."

v2.28.0 | Report a Bug | By Email | System Status