IETF Logo Mail Archive

Re: AD review : draft-ietf-quic-bit-grease-02

Martin Thomson <mt@lowentropy.net> Thu, 12 May 2022 23:32 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD60FC157B5F for <quic@ietfa.amsl.com>; Thu, 12 May 2022 16:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=O6vaouTZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VNFdKegg
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COWkrlVZmfH2 for <quic@ietfa.amsl.com>; Thu, 12 May 2022 16:32:36 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0ABC157B52 for <quic@ietf.org>; Thu, 12 May 2022 16:32:36 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DB63E5C0215 for <quic@ietf.org>; Thu, 12 May 2022 19:32:35 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Thu, 12 May 2022 19:32:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1652398355; x= 1652484755; bh=llVtt2XNU6Ko4BeyPcSe56Ewi7iGIb/aTnDXnb0gFTo=; b=O 6vaouTZc9RWKlSs5F6VjFXl3K7p+MDDyl3zAwfZArRI1UDogE6/wx367qW6U+cir IiU6BzirEbQC30X6LwYbLQXa3KSzYiFlgXXjSHTkH3T+L6VBGJXG2OrQBgNdwS7m Q4ClZAqpi9i0QXCMu2ywAFu6iJQYEp/XCizMDU1Bi7UXwPVcT0D1O4n9j45nfOuc d410hKvxk9zywRH1bGSPYKVNDerjH3DAOMcuh82E2FCCMxDkOGl/lJvYXEHU9aN1 X4TKgVKFi3CT05doPI92Xi4l4ZPxH+oWS6LISuCzWS+0VCp9AbO/VxfoT/A2xBOs LCJ97rwLkVPSH5P80ds5w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1652398355; x=1652484755; bh=llVtt2XNU6Ko4BeyPcSe56Ewi7iG Ib/aTnDXnb0gFTo=; b=VNFdKeggFxV8z+mqSh4tglgi65bEAHLQAjNN3y81ktDC 1s0USelGbQ46r67ZqlXrjpN6KOXMObNJN7g7nykdesxKJRZt9+SaIcNotpZv6ZWI kU7JyDiEGfpfOQ5tc3Utfy9xpET0C5gx8efPvXEQwJXfgM50TlLQGu81q2oaXzqk nIKM4JhehxTBKYpM/PWV9d9lb76ENUJNRNZnuBFyDyfD/Cbe0kLUrspgX493gzoi nEctkl8q9K2NMRvkg8oxOz7VrAucyqxDyOS9joaaZdVrbhku6IjoefwTwSAbfkaG 6mG0ikLpH/Rc/eENtVFr6dYc9d02ZvScW1GID6aQmw==
X-ME-Sender: <xms:E5l9YuVBsdY9F9Sq7Q_i1NLmJv2znkA75nPeQAiGHzaa3qfpvrFGyg> <xme:E5l9Yqnovkf3ZvM1H6zRb1IlW0myUPJrh7_GDRfiVrN2jYO-vm0ZMhqN8YArucJGE wqDDF0ZFAem6PvMifA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrgeekgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeeuheeghfeuveduveevfe eljedtgeduheehjeejgffgtdduuedvhfeileeiteektdenucffohhmrghinhepghhithhh uhgsrdgtohhmpdhfihhrvggvhigvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:E5l9YiY-fRLWPjmeMl_N21cyUoYW7uSzwqEoPVBVgNNHPh2xUk7-uw> <xmx:E5l9YlUGFelAEXPpfqUtHRDy-CALpos0RJp-sNedFG_7NpyBxM9_cA> <xmx:E5l9YonUQ-oS4Ln5qIPktUqQGQ4q1Ion-TXXM-w2V68iHchpal0D2g> <xmx:E5l9YkwkMBIfyFBMEaiWrnw1oLTAF2B8LidNdZKeI07SNh4v6LHg0Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8652F2340067; Thu, 12 May 2022 19:32:35 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27
Mime-Version: 1.0
Message-Id: <b2b70599-f0ce-4e71-a698-d024a63d55a0@beta.fastmail.com>
In-Reply-To: <1871AA6F-D8C2-4B49-BF5C-D4559BA8E7FA@ericsson.com>
References: <E622BA01-2890-498D-87CA-37EDB0F54F67@ericsson.com> <642ef7c0-82fc-4336-9300-caea2fb927aa@beta.fastmail.com> <1871AA6F-D8C2-4B49-BF5C-D4559BA8E7FA@ericsson.com>
Date: Fri, 13 May 2022 09:32:16 +1000
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: AD review : draft-ietf-quic-bit-grease-02
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8ogYdBh7SUGYb3CyeuAA9cPx34w>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2022 23:32:41 -0000

Hey folks,

David just provided some feedback on this that suggested a more comprehensive rewrite.  In case you looked already, you might want to take another peek.  One consequence of that change is that clearing the bit is now also possible on 0-RTT and Handshake packets, which might have been how people implemented this (that's what I did).

Cheers,
Martin

On Thu, May 12, 2022, at 16:58, Zaheduzzaman Sarker wrote:
> Hello all,
>
> Martin and me has chatted about the 7 day rule and it appeared that not 
> following the rule would actually lead to connection failure. Hence, 
> this actually should be a MUST. See the pull request 
> https://github.com/quicwg/quic-bit-grease/pull/24. 
>
> Please reflect on this change by the end of next week (20th May, 2022) 
> along with any thoughts regarding the 7 (day) number. Unless any 
> critical issue found, after that I will consider the AD review issues 
> are resolved and move the doc to IETF LC.
>
> //Zahed
>
>
>> On 28 Apr 2022, at 04:33, Martin Thomson <mt@lowentropy.net> wrote:
>> 
>> Thanks Zahed.
>> 
>> I've added references as you suggest and reworded some of the intro (fewer words!)
>> 
>> You asked about the 7 day thing, which is almost entirely arbitrary.  QUIC doesn't time limit NEW_TOKEN in any way, so this time is only necessary to avoid unbounded use of the mechanism (which might prevent a server from ever disabling greasing).  It's aligned with TLS requirements for session tickets, because that is likely natural for client implementations, but it is still ultimately an arbitrary value.  We can say that much, but I don't think we need to.
>> 
>> On Wed, Apr 27, 2022, at 20:09, Zaheduzzaman Sarker wrote:
>>> Hi,
>>> 
>>> Thanks for the short and nice draft.
>>> 
>>> I have done my AD review. I haven’t noticed any technical issues so 
>>> far. However, I have some editorial comments and I have created issues 
>>> for those (https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-bfd564275429d53b&q=1&e=47a1b565-597e-492d-a7c0-c2291d74fae4&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fquic-bit-grease%2Fissues). 
>>> 
>>> //Zahed
>>> Attachments:
>>> * smime.p7s
>
> Attachments:
> * smime.p7s

v2.23.0 | Report a Bug | By Email