Re: [quicwg/base-drafts] Server should not accept 1-RTT traffic before handshake completion (#3159)

martinduke <> Tue, 29 October 2019 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1646E12006D for <>; Tue, 29 Oct 2019 14:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q7P-mVMAeOQB for <>; Tue, 29 Oct 2019 14:55:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4782512001E for <>; Tue, 29 Oct 2019 14:55:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 606998C050B for <>; Tue, 29 Oct 2019 14:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572386100; bh=9HnVWfri+/ylkH4IwXORQ4GzKG5g+Zgu9Znb+Y/c37g=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Q3d5ohRJTAajZNwsmRgg0PwaOELmxo/OQg3Za21B9xpwGyr9ZLE3+8jTPnG4wqx/j ou9ljBHzX55+aKXmgrPzusnfSxPcDEvaB9QgKlK9KzctTS0v2rA6nrlo6K+A2WD0jC 3JrIf6iy0rCS+Y5SqEANG4fe7yJO6utdVGRLJJpI=
Date: Tue, 29 Oct 2019 14:55:00 -0700
From: martinduke <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3159/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Server should not accept 1-RTT traffic before handshake completion (#3159)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db8b534516b9_71b33fd88b0cd96c1394bd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Oct 2019 21:55:03 -0000

Like @kazuho, our TLS doesn't even deliver the receive keys until it gets Finished. Rather than mess with the spec or rely on various QUIC implementations to do it right, I think it's best to fix the various TLS implementations (or, more specifically, their QUIC-facing secret export API) to do this correctly. There are relatively few of these and it's a problem specific to TLS 1.3.

The ability to coalesce sent packets is optional and the spec goes to great pains to not require sending them at any point, which has caused much suffering for @ianswett. Moreover, I am not at all convinced that coalescing Finished solves the problem.

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