Re: [quicwg/base-drafts] Require RFC8470 (#2433)

Martin Thomson <notifications@github.com> Thu, 07 February 2019 02:13 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 3F33D130FB7 for <quic-issues@ietfa.amsl.com>; Wed, 6 Feb 2019 18:13:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 O7Zl1r5semVf for <quic-issues@ietfa.amsl.com>; Wed, 6 Feb 2019 18:13:35 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768F0130FAB for <quic-issues@ietf.org>; Wed, 6 Feb 2019 18:13:35 -0800 (PST)
Date: Wed, 06 Feb 2019 18:13:34 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549505614; bh=0ejst909wzkNW/y9bEVn7JxUKgELHi2isDAZrSq5gIU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=WcBCzMJuiyCj6605vBLDBI/N/e93JHl9yE3tyQxAi1KyvHYSniMDxktqEqPfrocGX iSMxf3tcuMiosOEZeyiZ4Df0S6NZZp1OGeNxelGCCI9AEv490VSEFLvfAxhZ1j34Zj /WLqlmtgAsgt4+fmVHhOgPuISIKeZ7ev51ZaVh70=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abccb4574567ad1f1711240af6683727cc27b1df5892cf000000011873564e92a169ce1849f243@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2433/review/200896072@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2433@github.com>
References: <quicwg/base-drafts/pull/2433@github.com>
Subject: Re: [quicwg/base-drafts] Require RFC8470 (#2433)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c5b944ea080b_72cd3f9b02ad45bc1219b8"; 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/wzau7E6uHtzqku2yaMPhwao6Np0>
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: Thu, 07 Feb 2019 02:13:37 -0000

martinthomson commented on this pull request.

This supercedes what I added in #2355. 

Not sure that we need the exposition, given the risk of getting things subtly wrong though.

> @@ -234,6 +234,17 @@ SETTINGS frame. After the QUIC connection is established, a SETTINGS frame
 ({{frame-settings}}) MUST be sent by each endpoint as the initial frame of their
 respective HTTP control stream (see {{control-streams}}).
 
+## Early Data and HTTP/3
+
+QUIC provides a facility for early data during the first flight of packets sent
+by the client.  Early data is not subject to the same security guarantees as
+data sent after the handshake completes.  In particular, this data can be
+replayed by an attacker able to capture the packets and the server will not know

This isn't entirely true.  Capturing and replaying packets is not sufficient, or even necessary for an attack.  I would instead point at TLS 1.3 and the discussion about what can happen there than try to repeat it.

-- 
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/pull/2433#pullrequestreview-200896072