Fwd: [TLS] ECH usage indication: alternatives to trial decryption?

David Benjamin <davidben@chromium.org> Mon, 17 August 2020 21:35 UTC

Return-Path: <davidben@google.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8983A1203 for <quic@ietfa.amsl.com>; Mon, 17 Aug 2020 14:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.498
X-Spam-Level:
X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 bxqocR_20G_Q for <quic@ietfa.amsl.com>; Mon, 17 Aug 2020 14:35:18 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 BCDF73A1200 for <quic@ietf.org>; Mon, 17 Aug 2020 14:35:18 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id i92so8430913pje.0 for <quic@ietf.org>; Mon, 17 Aug 2020 14:35:18 -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; bh=E7lwNShg7ws1bHxLscZkjvOJk4/nHdgWDvOe4/+8D2Q=; b=gRKjKNAeggDchqH04FjR30R/IwFZ5KbqjeoNIc0vd93paMhAfvDUd8u+2RQgNiyrt3 CV4YVQJVTw8CHH7XDNv4qOOaWW0JLXpVea4z6m14jTvdIL2GfzaXvWh/pd8CvxR5JO8P pC6xAVGXaevf/6x+dPeL+YR9vohaxLLYuRXzQ=
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; bh=E7lwNShg7ws1bHxLscZkjvOJk4/nHdgWDvOe4/+8D2Q=; b=nQnQrt/SjAF7e0EA2OnU9eh+kRKbR1kaeqB0MOeBEELGhwMwHSlVtoVG8N5d8G/oLz s/k0ka4E8531SU/SuRwUcG3Ajcsyeh5eaaEQkt0grfCId2NqL0g42EecM5QzzbnPWexh pqx8xWBWNfaiNh+318phj7qTxNMc/tQ64J1v9jcX6j5IchdvFWEh48ycERQhqN6YPNbY vhUQwzvSKIcAIYvkv1jFyLRs77lCmH1WpqEDslBRcnk9P8cXhrLaRJxtP90uU7fz/B5F 4TAWu4xzxVV6cIEvYHf300vJ7erof6fuUW6GrAkdoKu49EIGrElt/SOKzs4Tntn8HKn1 4VCw==
X-Gm-Message-State: AOAM531qZZuSsICjxPxUxyB7geNI1H3+Ui3FxIvIO6fWjNpufFiRfq4f LMrT1lXi33yiOUDZk9BU1kB1bPc38Y37XgAneCcMq5ZrMHN0
X-Google-Smtp-Source: ABdhPJz0XN8dK/2an7KF6Qgqvxc0FOYlDfQtXdp7OImIDifyIX2iA0ECp2qYTYgmbIKAUGjKxyy5EiwQg0t6zQH/4x8=
X-Received: by 2002:a17:902:9787:: with SMTP id q7mr13331200plp.0.1597700116305; Mon, 17 Aug 2020 14:35:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAG2Zi22-L3j8ha4bgE3tjqdUVAMsOUVvW79UEhKSydrZ=mY6PA@mail.gmail.com> <CAF8qwaBV73tTC-ht-U_Oi0=totju0mGK7Mf_=e2=hswewmPypg@mail.gmail.com>
In-Reply-To: <CAF8qwaBV73tTC-ht-U_Oi0=totju0mGK7Mf_=e2=hswewmPypg@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 17 Aug 2020 17:34:59 -0400
Message-ID: <CAF8qwaDd=LjnGkVsmYpcebO_xm3GhuP7cYsBQuxis20q-_7U9A@mail.gmail.com>
Subject: Fwd: [TLS] ECH usage indication: alternatives to trial decryption?
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e43ab205ad198b27"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ZodthhvHltA021DaLfGBrBNqqpk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2020 21:35:21 -0000

Hi QUIC folks,

To follow from the padding email from last week, there's a second point of
the TLS ECH (Encrypted ClientHello, formerly ESNI) extension which crosses
the TLS/QUIC boundary, which folks in this WG may be interested in.

The GitHub discussion link is
https://github.com/tlswg/draft-ietf-tls-esni/issues/274.

David

---------- Forwarded message ---------
From: David Benjamin <davidben@chromium.org>
Date: Mon, Aug 17, 2020 at 5:21 PM
Subject: Re: [TLS] ECH usage indication: alternatives to trial decryption?
To: Christopher Patton <cpatton=40cloudflare.com@dmarc.ietf.org>
Cc: <tls@ietf.org> <tls@ietf.org>


Thanks for writing this up! We've been pondering this subject as well, as
part of identifying places where ECH and QUIC interact interestingly. (The
other being the padding issue in
https://github.com/tlswg/draft-ietf-tls-esni/issues/264.)

As with the padding issue, QUIC replaces the record layer, so all the
handshake/record-layer coordination here must cross the TLS/QUIC public
API. TLS must configure two different keys for QUIC, then QUIC must trial
decrypt and report back to TLS which keys were used. In contrast, something
that lives entirely in the handshake should apply to QUIC without
modifications.

I think in essence we’re running into QUIC sandwiching itself between the
TLS handshake and records layer, despite that “interface” not being quite
fully understood yet.

(I'm not sure what's IETF email etiquette for joining related WGs to an
existing thread, so I'll forward this separately to the QUICWG, so they can
join the discussion.)

David

On Mon, Aug 17, 2020 at 4:55 PM Christopher Patton <cpatton=
40cloudflare.com@dmarc.ietf.org> wrote:

> Hi list,
>
> In the current ECH specification (draft-ietf-tls-esni-07), the server
> provides no indication of whether the inner or outer ClientHello (CH) was
> used. This means the client must do trial decryption to make this
> determination, which creates implementation complexity and potentially
> raises security concerns. I was hoping to get your thoughts on a couple
> alternatives, which strike different balances between implementation
> complexity and other design considerations for ECH. Follow along here:
>
> https://github.com/tlswg/draft-ietf-tls-esni/issues/274
>
> Thanks,
> Chris P.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>