Re: [quicwg/base-drafts] Specify behavior for post-handshake CRYPTO messages (#2524)

Marten Seemann <notifications@github.com> Tue, 19 March 2019 14:36 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 AB9D1131201 for <quic-issues@ietfa.amsl.com>; Tue, 19 Mar 2019 07:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.002
X-Spam-Level:
X-Spam-Status: No, score=-8.002 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 v6ghBOu-ujNU for <quic-issues@ietfa.amsl.com>; Tue, 19 Mar 2019 07:36:54 -0700 (PDT)
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 4C2AB13131D for <quic-issues@ietf.org>; Tue, 19 Mar 2019 07:36:47 -0700 (PDT)
Date: Tue, 19 Mar 2019 07:36:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1553006205; bh=5gUVIG9sa1k6sdpxL1+TSNBpCt5PX6H0gprJtjhxMMk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EgRPFt6ZxwTuTdPxgPYwfsKPrOSdPmie0Lrkg4AhCda/6mQnaqocYRvuSxMAt/OAc WiFbi7/DrOLri5hqAg78GZLQ8lhafjXOQ6i2sqEce6pi3QxzL6UMVVFetRGFSwqNQ7 x+f53HWkkrntOq8b7GcRdCG5Bbr3jkNkCwVL3lHI=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abd52982d999883e60683a99091f4eba43ed7b84c792cf0000000118a8c07d92a169ce192348df@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2524/c474398859@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2524@github.com>
References: <quicwg/base-drafts/pull/2524@github.com>
Subject: Re: [quicwg/base-drafts] Specify behavior for post-handshake CRYPTO messages (#2524)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c90fe7de5564_793c3fec0a6d45bc2767e8"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/A4U4jP68af5f1rj_s_9TIO8Clrw>
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: Tue, 19 Mar 2019 14:36:57 -0000

> I don't think that this breaks a rule of acknowledging packets means that the peer has processed all frames in that packet. For example, if an endpoint receives a packet containing stream data that is a retransmission of previously received data, that endpoint in effect is dropping that STREAM frame. 

I don't think this is a fair characterization. For the sender, it doesn't really matter if it was this copy of the data, or an earlier STREAM frame containing exactly the same data. The ACK signals that the data was delivered to the application, and that's all that matters.

> Here, the CRYPTO frame is being processed (and the endpoint is immediately choosing to do nothing based on it).

Exactly the opposite. Processing the CRYPTO frame would mean to deliver it to the TLS stack. Here it's dropped one layer below that. Everywhere else in the spec, we use "processing" in the sense that the data has been acted upon, not in the sense that the frame was merely parsed.

-- 
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/2524#issuecomment-474398859