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
- Handshake-level vs record-level padding in TLS ECH David Benjamin