Re: [TLS] ECH and resumption - what to put in SNI?

David Benjamin <davidben@chromium.org> Sat, 26 June 2021 02:24 UTC

Return-Path: <davidben@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 AA7313A197C for <tls@ietfa.amsl.com>; Fri, 25 Jun 2021 19:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.448
X-Spam-Level:
X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 TpgQ8bBu0xa2 for <tls@ietfa.amsl.com>; Fri, 25 Jun 2021 19:24:35 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 E43463A1979 for <tls@ietf.org>; Fri, 25 Jun 2021 19:24:35 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id u2so5664519plf.3 for <tls@ietf.org>; Fri, 25 Jun 2021 19:24:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aG/GYlxhsjqXmrNa01ZMh0m9eDLev1apkevXGClqnqU=; b=KHmGc4AmfWAX63OTD06VbBeGExrmDsAO/IFaEmrMHAGeUMsPnIR+r/4eNfyNBVOSX5 Q5j9hJ2ebfMc5Sh6N4dJKEBn7lhSHTUpLQkQu+S20jGvLFFLFd6JIvfZHwqOy34CKey+ 5lHUrVvG30i/fVm6t6L6DJdnGU86e/QU1afv8=
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=aG/GYlxhsjqXmrNa01ZMh0m9eDLev1apkevXGClqnqU=; b=pCTCg8O0xSalWYXLLvvpR/fQSUwjIFhaPzw3qRDswYq5C111FRshCTpaL3c941Rb9R tuy4eedJ6KJ/R3behAdMU30Vlw/3sTcbNv0GTzCMXQ3ejTvMF4QngzEMCL8AryV+0IKK kYOKqdxVXIELA5zfiu9zfuwFzJI61djhaOtse0/EflARjQx2JgfCxUSGYeO43w5lCKjv LI6TK+Bl8MPWLu79o6BYygUKJDjAQNNqVyNxKtMFwo8ofM6F9xz7fYPgix3awpFau1Tf nchrMrq/4A9Iw6Iex1MpZ3W9S+LsquSL81LlcD8mI1jJ+cVsVG9u+DX1SZugJ2OdLFM+ fvIg==
X-Gm-Message-State: AOAM531JOjSgi2waOYywQ00hx2fzjYmebzgCIx10jlGNGAb0xdg3uMDK AVYONP1QBqQIQAsfIejLja/1VpBk2H7E95qlhOkUuAT6EQ==
X-Google-Smtp-Source: ABdhPJx2JG5xTff9aCe8y73xugm8d3pCylQw+sL0Kkj6i9JIryoh+TNxaFN2+L3DcouWYZb385gmbPogXZC+D2CHGwM=
X-Received: by 2002:a17:902:b203:b029:127:16e0:286a with SMTP id t3-20020a170902b203b029012716e0286amr11923743plr.0.1624674274266; Fri, 25 Jun 2021 19:24:34 -0700 (PDT)
MIME-Version: 1.0
References: <062ba89f-15fb-669e-b1fb-cf6c71fc88a8@cs.tcd.ie> <CABcZeBOFZN4Ra5d6pc9Eu-JjTWP7OaRivsTTjhWoK7aq68bMeA@mail.gmail.com> <CAF8qwaBFYtk0oSKPShKqzfs-XkQzUzwsHB-Sj17B0PqaijjNXg@mail.gmail.com> <e709ae08-55cf-18cd-f883-335c28339ba3@cs.tcd.ie>
In-Reply-To: <e709ae08-55cf-18cd-f883-335c28339ba3@cs.tcd.ie>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 25 Jun 2021 22:24:17 -0400
Message-ID: <CAF8qwaDHn5K93YX=Q5yGGLKS1bsT_xYYHoQYD_GiTcQfaVpmwA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fec18c05c5a1f417"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NS6OpV9RxNQ6DheCzHI28V_2Xns>
Subject: Re: [TLS] ECH and resumption - what to put in SNI?
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: Sat, 26 Jun 2021 02:24:41 -0000

On Fri, Jun 25, 2021 at 8:45 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> So I guess we're landing on "if the client got a ticket via
> a session that successfully used ECH, it MUST send a fresh
> ECH when using that ticket"? That's ok I guess, but maybe
> some more detail is needed...
>
> On 25/06/2021 17:01, David Benjamin wrote:
> > 1. Either this layer knows how to set up TLS, but doesn't know how to
> > establish connections. Low-level TLS APIs look like this. This layer must
> > take both the transport connection and ECHConfigList as an external
> > parameter. Resumption works orthogonally: the layers above run through
> the
> > same connection establishment procedure independent of resumption, so you
> > won't have any more stale of ECHConfigList for resumption as full
> > handshake. If this layer doesn't know how to establish connections for
> full
> > handshakes, it doesn't know how to do it for resumption handshakes
> either.
> >
> > 2. Or this layer knows how to establish a connection*and*  set up TLS.
> > Maybe this is a higher-level TLS API. Maybe this is the
> > MakeHTTPSConnection() portion of your HTTP stack. In this case, the layer
> > is responsible for DNS lookup, evaluating HTTPS/SVCB queries, and using
> the
> > ECHConfigList. Resumption is equally orthogonal: whenever you make a
> > connection, you do the DNS lookup, possibly using a cached record. Then
> you
> > check your session cache. Use ECH if you have an ECHConfigList. Offer
> > resumption if you have a session. Do both if you have both.
> >
> > In both cases, resumption doesn't affect ECHConfigList availability.
>
> I'm not sure yet that OpenSSL matches either 1 or 2, (I've
> only done some basic tests) but in any case it seems like
> the client could have a ticket cached but get an entirely
> different SVCB RR with a different public_name the 2nd time
> so I'm not sure that things work well in all cases.
>

The main uses of OpenSSL are (1). TLS stacks typically will be (1) because
connection establishment has all kinds of application-specific bits. E.g.
connection establishment in general needs to integrate with proxy logic for
HTTP CONNECT proxies, and interpreting the HTTPS/SVCB record needs to
integrate with Alt-Svc, and deciding between TCP and QUIC.

There's some stuff that's partially shaped like (2) with connect BIOs and
such, but most applications don't use it. I've not thought very hard about
how an HTTPS/SVCB embedding of that API would look like. But either way,
the point about resumption being orthogonal stands.

David