Re: [TLS] TLS ECH, how much can the hint stick out?

Eric Rescorla <> Thu, 10 September 2020 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 845673A0FE4 for <>; Thu, 10 Sep 2020 15:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id viP0A3Tak0WB for <>; Thu, 10 Sep 2020 15:12:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6FBE3A1043 for <>; Thu, 10 Sep 2020 15:12:18 -0700 (PDT)
Received: by with SMTP id r24so10246793ljm.3 for <>; Thu, 10 Sep 2020 15:12:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2qNhVTXIeh4xTXtUu0PtH+Vbq/EyuxH6pok9U/SLcX4=; b=YO4qCIf8Z5lYybtbabM+7EbdWcpzfQOoBR01T0GH1JLB0mVBzLw8M0LtLA+GUSrMTQ X+pPoTUPEnjnnPTCiUVMZBfZ+S56mc14jveD8XA0b+nVMWrTrhxzUCgGXVsA57jA+WJx U3hSYFg2U+2xobfXppAwn1UgQTQi4WGB9pglJl4aaBppdCSARuuVIFCoclUA90mgW3aL VPs+qcFzg5F9GHfaXHMwPH04mrBmB/K6ziz+8nE+CQyADpqYCV74IUUnqJXhZRZMOU4/ wQIfGL5kdtTGk2viABI6k0SPDUfvaucyZmhH9DXhQiJRQLHU2/+u2iDyCAHd+bcVZVoM Nf3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2qNhVTXIeh4xTXtUu0PtH+Vbq/EyuxH6pok9U/SLcX4=; b=iQFiGTDH57xb9AS+RVeu56Hv7i+ey4iOumokvg2elv+xae28LN/72tGrZh4mxKalUg 8bFLddh2i+Cd73BRaPq+52SF5PhgbnMCXINvIoCe4rBKJNeuT4OW706zxf7DoYuMoAPv 3EFMOKyQJis0+KiIrFcgn4EwjhUJCWWQVwf1Tzp3NTpIgEX2bZlfIjF0QgZSW5rJmnRw Qk9+x1yz0PVIAy1LVIgxe+cFlEoRMIXiBUQsjtx0I2WUrwaKHp52rhO1adl5OTp5/UUV cCKpO8mXCIJ0IFIhqxCVvC6bApmnZ/N02M7Uh35ouizNrd/vg/IRe7yqdoYI1Mm6SHyo TR0g==
X-Gm-Message-State: AOAM532pUA0uxLvlfWZfm2Ov7zPFqVyYjb/DVDoY7Vkznz8aS6bRLIq/ A9dCjQwL9r28lVn358M2FAmLto68oudgOLDrLcEuVKX7tOIznlsz
X-Google-Smtp-Source: ABdhPJzYdZ+6+pHSstb/rOy2gnd/SLthXmF5aQkCZxTdJA6olGAjlq6T6L5Nr9iNy/2WJM2rCDU/vxcqKwr+yco5/HU=
X-Received: by 2002:a2e:2241:: with SMTP id i62mr6137619lji.265.1599775937059; Thu, 10 Sep 2020 15:12:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Thu, 10 Sep 2020 15:11:40 -0700
Message-ID: <>
To: Mike Bishop <>
Cc: Christopher Patton <>, Christian Huitema <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000072f6b905aefcdc64"
Archived-At: <>
Subject: Re: [TLS] TLS ECH, how much can the hint stick out?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Sep 2020 22:12:32 -0000

On Thu, Sep 10, 2020 at 2:21 PM Mike Bishop <> wrote:

> Certainly it’s better for the server if it can be consistent, especially
> if it expects multi-packet first flights.  If the same back-end sees both,
> it can discard the second, and that’s what I’d expect most of the time.
> But here’s what I think is possible:
> The client sends an Initial packet (randomly selected Destination CID),
> PTOs, then sends another Initial packet to the same Destination CID.  On
> the server side, the infrastructure assumes that Initial packets whose CIDs
> aren’t issued by them can be routed to a random back-end, and that back-end
> will set a new DCID that routes to it in the future.
> The client will receive either of the Server Initial packets, switch to
> the new DCID, and will reject the other because attempts to change the
> server’s CID a second time.  The connection succeeds because whichever
> server’s ServerHello is used also has its DCID used, so all subsequent
> packets go to that back-end.

OK, this can't happen in DTLS because the CID management works differently.

While it's not clear to me that QUIC explicitly prohibits this (it would be
prohibited if CRYPTO frames were STREAM frames because of
draft-ietf-tls-quic-transport S 2.2, it seems like it's  quite bad practice
because the result will be that the losing server has a pending handshake
which it continues to retransmit on until the client times out.