IETF Logo Mail Archive

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

Christian Huitema <notifications@github.com> Wed, 06 November 2019 00:23 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 E0E211200E9 for <quic-issues@ietfa.amsl.com>; Tue, 5 Nov 2019 16:23:36 -0800 (PST)
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 d1Jg2LMCAgyY for <quic-issues@ietfa.amsl.com>; Tue, 5 Nov 2019 16:23:35 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814CD1200C3 for <quic-issues@ietf.org>; Tue, 5 Nov 2019 16:23:35 -0800 (PST)
Received: from github-lowworker-edec459.ac4-iad.github.net (github-lowworker-edec459.ac4-iad.github.net [10.52.18.32]) by smtp.github.com (Postfix) with ESMTP id A28E01C1601 for <quic-issues@ietf.org>; Tue, 5 Nov 2019 16:23:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572999814; bh=kRDrdjsJBFlTUlerQ5yQUB2CzapB/29K5n8RBqYb+ig=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZdOX1Od5dOu5T84Yji6/AqswWBakcsqtt6iH3hMCLQwkte98gPVPt/1HDT0Qwy+Pz UQZqIllGgJ+EbEQni4mlgEbruZVbWptcULamWqsPXFgnwv+eDSOMTWJivgyFphDawV 0BNdFS/YdHBUkpzCE6YlW+dV/bXqNskUR3Qvr4qA=
Date: Tue, 05 Nov 2019 16:23:34 -0800
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4HLJG2BAKPV6NZFPN3Z5CQNEVBNHHB5FZ3ZY@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/550084676@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_5dc2128693ac8_4db73fb709ecd95c2995b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/yeDGPjzDVmjsEVE4ulxFixzrmQk>
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, 06 Nov 2019 00:23:37 -0000

This feels like a great idea for Quic V2. Instead of just having 0-RTT and 1-RTT packets, also define 0.5-RTT packets that the sender can emit before the handshake is complete. (Or maybe call them sender side 0-RTT.) Use different key derivations for 0.5-RTT and for 1-RTT, and make the 1RTT key dependent on some nonce carried with the client finished message. Add parameters somewhere (TLS or Quic TP) explaining whether the client will accept 0.5RTT packets or discard them. 

But no, not today please, not when we are finishing V1. For V1, we should just stick with the spec we have.

-- 
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-550084676

v2.29.0 | Report a Bug | By Email | System Status