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

Kazuho Oku <> Tue, 29 October 2019 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1F2A120119 for <>; Tue, 29 Oct 2019 14:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Status: No, score=-6.382 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_24=1.618, 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 vfRYkbxTvEPx for <>; Tue, 29 Oct 2019 14:20:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25E2012006D for <>; Tue, 29 Oct 2019 14:20:35 -0700 (PDT)
Date: Tue, 29 Oct 2019 14:20:34 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572384034; bh=1pWJ2DQXQ3oUtnCN3iQ23HVLQwFFEkaWd5BWaJx0mb8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VOQyEXCqc4HjZBSQT7eVjHWBpDxOMoeW/cPos0vO4lxDwv+TKO0KIZgoAG3s6+0mh qcWv2+zPuScnTbaxiqMxKxIWOsD1JffkjtRbAxi53unlU0D8rbNjU7IzC2nMuJiPhj BhPhz4OJ7QWK4NZE9sxGB1eEmiTpoiSVyZmzTmIY=
From: Kazuho Oku <>
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_5db8ad22568e9_1b1a3fc80bccd96460024"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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:20:37 -0000

@ad-l Thank you for sharing the results. This is very interesting. FWIW, I do not think QUIC stacks using picotls would have the issue, as picotls hands out the 1-RTT read key only after processing ClientFinished... but I can see that the API might vary between the TLS stacks.

Though, if we are to have a protocol design that enforces the server to wait for CF, just bundling CF in every 1-RTT packet is not enough. I'd argue that CF should include some bits that is unpredictable by the server.

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