[quicwg/base-drafts] Lift single-packet ClientHello requirement? (#2928)

David Benjamin <notifications@github.com> Tue, 23 July 2019 17:39 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 43FC0120712 for <quic-issues@ietfa.amsl.com>; Tue, 23 Jul 2019 10:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wkOqborLV2e0 for <quic-issues@ietfa.amsl.com>; Tue, 23 Jul 2019 10:39:17 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058861206F5 for <quic-issues@ietf.org>; Tue, 23 Jul 2019 10:39:16 -0700 (PDT)
Date: Tue, 23 Jul 2019 10:39:16 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1563903556; bh=RLnyVwK/G5kziRmA2E5rzj5DyYiJL7TUwKJ8qZ+Ieds=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=cXOao4mAJ9U+gxVvvxZkd3hcXexl9u5+GOjNAzHZiH9zSBq+ntQ8N1IC14a37NQ61 oO5uKRJ/9DFp1M7bwoZ9Idmm5jVdNFqpVNW/RAWE0bjPuc/fWHWDnF59nXAKx7wmfB VkvTru/pC5t6l9S9iyLzROiphcayV3d9c1BpYzl8=
From: David Benjamin <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2GD7VZDWM4KYHI3WN3IR4MJEVBNHHBYH45I4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2928@github.com>
Subject: [quicwg/base-drafts] Lift single-packet ClientHello requirement? (#2928)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d374644183ba_557a3fa993ecd96c689e9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: davidben
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/499rYFSEoTaZEt0q--3wJJjF26w>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 17:39:31 -0000

draft-ietf-quic-tls says "QUIC requires that the first Initial packet from a client contain an entire cryptographic handshake message, which for TLS is the ClientHello."

My (possibly incorrect) understanding is this was needed so the server can, in the old QUIC/TLS embedding, statelessly send a HelloRetryRequest without having to statefully assemble a ClientHello out of multiple packets. In the new QUIC/TLS embedding, this concern no longer applies because the stateless rejects are entirely external to TLS. Thus, should we simply delete most of the #clienthello-size section?

This avoids a number of awkward pitfalls because the ClientHello size is a function of many factors, with both client and server considerations that change over time. Perhaps we add a new TLS extension or key share type and some SNIs work but larger SNIs were closer to the limit and this brings them over. Or perhaps the server's NewSessionTicket is large[*] and breaks subsequent connections from some client. Perhaps that server tested it against one client, but another client has a larger baseline ClientHello and then it breaks.

Finally, post-quantum key exchange candidates tend to come with [large keys](https://www.imperialviolet.org/2018/04/11/pqconftls.html). The current text prevents QUIC from experimenting with or deploying such schemes. This is particularly fun because QUIC clients typically also speak TLS over TCP, so the security of connections to a server is bound by the weaker of TLS over QUIC and TCP.

[*] Client certificates are often inserted into the ticket, so now we have a client-specific limit being influenced by a server-specific implementation decision which is, in turn, dependent on client/CA-controlled size of client certificate. Additionally, draft-ietf-quic-transport#zerortt-parameters implies servers may wish to remember QUIC transport parameters in the ticket.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: