IETF Logo Mail Archive

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

Martin Thomson <notifications@github.com> Wed, 30 October 2019 06:55 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269B1120857 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 23:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 BfOV1hpYrDK3 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 23:55:35 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52011200C7 for <quic-issues@ietf.org>; Tue, 29 Oct 2019 23:55:34 -0700 (PDT)
Received: from github-lowworker-292e294.va3-iad.github.net (github-lowworker-292e294.va3-iad.github.net [10.48.102.70]) by smtp.github.com (Postfix) with ESMTP id 9979A6E153F for <quic-issues@ietf.org>; Tue, 29 Oct 2019 23:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; 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 <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5M7FPIQFCKGSMCTFN3YZTGLEVBNHHB5FZ3ZY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3159/547763004@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3159@github.com>
References: <quicwg/base-drafts/issues/3159@github.com>
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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/cOGUrKlZKEf227nx644e39w9jHU>
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: 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:
https://github.com/quicwg/base-drafts/issues/3159#issuecomment-547763004

v2.23.0 | Report a Bug | By Email