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

Martin Thomson <> Wed, 30 October 2019 06:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 269B1120857 for <>; Tue, 29 Oct 2019 23:55: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 BfOV1hpYrDK3 for <>; Tue, 29 Oct 2019 23:55: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 C52011200C7 for <>; Tue, 29 Oct 2019 23:55:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9979A6E153F for <>; Tue, 29 Oct 2019 23:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572418533; bh=btrczv+bjLeAnLVkGRG9CxWdPoJDC+ojr9Fh+rjlWB8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yYWqZ/ssFlTJz+qqkFjOQsqLCGIJArnnjQGy+/o0Wj11sj3PP/JmeVhDySMYUijIf lH2W9DarlulEI2ROFAlANSzoxJ6Aapj3K1YFb2nyHdvOf69YPWh0eIXrKnpQ4+cQBL DHTL/dbT2CagKgOOJS0BgDWY4QOYRagWRQLtjgzg=
Date: Tue, 29 Oct 2019 23:55:33 -0700
From: Martin Thomson <>
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_5db933e58acae_609e3fc6d00cd95c1451ad"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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: Wed, 30 Oct 2019 06:55:36 -0000

> are there any cryptographic reasons not to do this?

If we did something like this, it would likely trigger completely new analysis of the protocol.  The thing that concerns me is that it would reduce or eliminate key separation between resumption keys and traffic keys, which is a concern.  We'd be better off creating a new "secret" with the same transcript being input to its expansion.  But that smells a lot like defining TLS 1.4 to me.

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