Handshake-level vs record-level padding in TLS ECH

David Benjamin <davidben@chromium.org> Thu, 13 August 2020 18:04 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 B0A813A1034 for <quic@ietfa.amsl.com>; Thu, 13 Aug 2020 11:04:39 -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=unavailable 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 iwnqAvpI3-JB for <quic@ietfa.amsl.com>; Thu, 13 Aug 2020 11:04:37 -0700 (PDT)
Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 294213A102C for <quic@ietf.org>; Thu, 13 Aug 2020 11:04:36 -0700 (PDT)
Received: by mail-pf1-x442.google.com with SMTP id k18so3201587pfp.7 for <quic@ietf.org>; Thu, 13 Aug 2020 11:04:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=tQOvLgSflPsklOKaitWN8SbplvFZszQ9Ph3QMhsA5qI=; b=AmNWNYm0YrdHMVVnYZYhbrMAz5mPPUCDUrgdKWsXUH8piG+8njc7qEtVcKAzikAfWU ouwPGl8qEDPXPfSMsC9nXyIzGNpLz+xrF7VGX91Kf7m1i551XrLmLjYJbNuIBkf1Aqy1 jEN6YsqpujaDOqdN9D72LfwA4aXbXm6Zkfbw0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tQOvLgSflPsklOKaitWN8SbplvFZszQ9Ph3QMhsA5qI=; b=nuVaRWULECymke/mAOpIywn/8tPCM+hA10jOIKx+MNEmr9X3d+AMbbvoTEmsYbfbFQ Dqu7SjL9DVXRo3GLsxgHqqcDizdX+FDwN0TXtXOjBoeN3GHIkNqLxqc/AykQ1zmRE1EW vTgvGUmxwPqgewbhUsQ7umNPwriunqqZHRdAJvUABiegKcj9m2LrvEzlXJXaXiESf2S5 lgiL1EK3aBAm9JdIVo2OROfQnNPAA1LY94ziTtOb0EcEj65r+TsbF6bRg5L1gaV48XYK rVYRRXCwtM/fN6bWXt1EvGJ4pUTjjl/ZVgvjN18w7XMqrsrQkjP8KAAmGROvxPRsZCJi 7X6g==
X-Gm-Message-State: AOAM532rOqfjPMN3fFeqfLVQoCaz1I69xbnIku6zlPtduoZDNX+eOkN0 5tEs6eEubz89UEybGUysM13YrViHRyZb/VkSPAAX
X-Google-Smtp-Source: ABdhPJxm84I4z/qTmXx0oWSOTQ8ON8mQQk8ihUZAm1FL3CVzgl17VIXWCFboB08Xl4VasBlwwTTDhEWPI4RhVG4drM0=
X-Received: by 2002:a63:4381:: with SMTP id q123mr4661739pga.6.1597341876273; Thu, 13 Aug 2020 11:04:36 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Thu, 13 Aug 2020 14:04:20 -0400
Message-ID: <CAF8qwaCA_BSMNkHnHJM86VKgEivUUzk9gv5gKAi_-9RRtADxbA@mail.gmail.com>
Subject: Handshake-level vs record-level padding in TLS ECH
To: "<tls@ietf.org>" <tls@ietf.org>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001f29ef05acc623cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/5yOVgTG2S06dqtC7ouyLv9byF5c>
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: Thu, 13 Aug 2020 18:04:40 -0000

Hi all,

In discussing ECH (draft-ietf-tls-esni) with some QUIC folks, we identified
some places where the extension would not easily apply to QUIC unmodified.
One of them is ECH’s integration of handshake information (anonymity set of
certificates, etc.) with TLS record-level padding. Since QUIC both replaces
the record layer and runs over UDP, that means this padding crosses
TLS/QUIC public APIs and must be integrated into QUIC retransmission logic.

I wrote some notes up in the GitHub issue here:
https://github.com/tlswg/draft-ietf-tls-esni/issues/264

I wanted to find out both WGs’ thoughts on how to handle padding here, as
it seems we have a mismatch between the interfaces TLS assumes and QUIC
provides. The HTTP/3 draft briefly mentions a similar issue and has its own
stream-level padding story alongside the transport-level one.
https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-padding-and-traffic-analysi

We could match that in ECH, which would remove the need for TLS and QUIC to
coordinate here but adds another padding mechanism. Or we could leave
things as-is, which means ECH will require folks to add a parameter to
their TLS/QUIC APIs and then implement more complex retransmission logic
before usefully deploying ECH. (Something that should probably be reflected
in the QUIC spec.)

David