Re: Andrew Alston's Discuss on draft-ietf-quic-bit-grease-04: (with DISCUSS)

Lucas Pardue <lucaspardue.24.7@gmail.com> Fri, 01 July 2022 00:57 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
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 B5784C157901; Thu, 30 Jun 2022 17:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.854
X-Spam-Level:
X-Spam-Status: No, score=-1.854 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 uzlf1Lvd2GVa; Thu, 30 Jun 2022 17:57:58 -0700 (PDT)
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 00655C14F72A; Thu, 30 Jun 2022 17:57:57 -0700 (PDT)
Received: by mail-qv1-xf2c.google.com with SMTP id cs6so2372820qvb.6; Thu, 30 Jun 2022 17:57:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t/GxH91JshQp2XPKTDzWlNmW+jA14HV+WNAOkJoF4zk=; b=DcpXvgSSeiVR1B/j4HPDCWfyESVplAuVX1dtO8J4cka+Z9tk6GzG0RsDC/zRVD7I6I O1UQO62C5JWOnuthHTaMEWC58OpsSQ4gJPI43anxUKR2AsGr1/KDocLFrwn1Ql5OKpZj rJnNxUMqWgOlyXHJC/En3Tuksak8GRPmqU4rS38rtCmxjeykgw4I6ZPKPC0eKuCFcTEL YYIWMzciJESAeRDdHzXYjuCFy9m0FNfy4fDqTGsJlbHnE9V8+6HeG/8PQK6iMsZzaN5o VwVu083fdAPnXfHios3mer+h4mkLd3DE967A2P+zdwnkZDrEcSbNF0zN+rSsEhEibUsK rNHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t/GxH91JshQp2XPKTDzWlNmW+jA14HV+WNAOkJoF4zk=; b=oo7OpGCt6F5b/f4q4zMEXwyFK/XZ/K2r/7wGesV1+ImnwyFBqexnWjrpz26fTAKpU9 DArqP+E8XrMFnwvB3mdGigLydyrytrNxmxThd9mq3FY6FChtKlu9ayx/jvJERN5j+F+a 86Oy8mG+IasZjsrSZEDQ9bZF4eBJtijY5lB2xMeXe5pZ5KCEcpQW2T06xaB578RW/NBX gd/krHS5bzCI31RWXlqFKXrkGlZJMULJnebE4FwHcG6UFb8i69V5K7cw812toQBW90Qk VztMl7cgeCoZ7Pj0/qrq97SWApra1I3F0EeusFshGqBGgi8MG2h+U5tX7SK1PDN9YxS5 84gg==
X-Gm-Message-State: AJIora/whC3VE7HxSOeCYrYtjvl58wAKepaBeZID7rU8VdfOlgohypTH 5KX3rcmiFAYw+eKozOxI3s2fctQGuFFgcylofUk=
X-Google-Smtp-Source: AGRyM1sSBB3wisbL7dNYPnGSZzvqgytLSx/s7bbAYJ2Sx8jWhVfVYsBTuvh6yFLekc+Q/kcKG228pNQULBLfnOEFidQ=
X-Received: by 2002:ad4:5aad:0:b0:472:7486:31ac with SMTP id u13-20020ad45aad000000b00472748631acmr15559454qvg.75.1656637077038; Thu, 30 Jun 2022 17:57:57 -0700 (PDT)
MIME-Version: 1.0
References: <165659352834.26475.4217014570058234110@ietfa.amsl.com> <dc5b2368-f66e-4774-a972-68d93841549e@beta.fastmail.com>
In-Reply-To: <dc5b2368-f66e-4774-a972-68d93841549e@beta.fastmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 01 Jul 2022 01:57:46 +0100
Message-ID: <CALGR9oa_aqt52OPZSZi184QX1WCQZA3YhWmFygdGqzkfKgbMUQ@mail.gmail.com>
Subject: Re: Andrew Alston's Discuss on draft-ietf-quic-bit-grease-04: (with DISCUSS)
To: Martin Thomson <mt@lowentropy.net>
Cc: Andrew Alston <andrew-ietf@liquid.tech>, The IESG <iesg@ietf.org>, draft-ietf-quic-bit-grease@ietf.org, WG Chairs <quic-chairs@ietf.org>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007fa99e05e2b3e0af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7fhFR53H45mTlh0cTGd5X7Zvmsw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 01 Jul 2022 00:57:59 -0000

Hey Martin, all,

I think you're correct in pointing out that the term unpredictable is a
term of art within the context of QUIC that this draft operates. However, I
find also in RFC 9000 that supporting text for various unpredictable
elements usually provides a justification or some guidance. Arguably, the
justification _is_ the entire document, but in the context of other
grease-like mechanisms in the IETF, it seems a single bit might need a more
holistic approach beyond just the value itself.

The closest parallel, for me, is the spin bit text that goes so far as
saying

> [if your TPs let you randomize] It is RECOMMENDED that
   endpoints set the spin bit to a random value either chosen
   independently for each packet or chosen independently for each
   connection ID.

Stating explicitly that the unpredictability can be per connection or per
packet might be all that's need to make the intent crystal clear, while
leaving the actual decisions to implementations.

Cheers
Lucas


On Fri, Jul 1, 2022 at 12:45 AM Martin Thomson <mt@lowentropy.net> wrote:

> I'm surprised at this question.  We used the word "unpredictable" in RFC
> 9000 a few times, with exactly this meaning and had no issue.  See for
> example:
>
> > When an Initial packet is sent by a client that has not previously
> received an Initial or Retry packet from the server, the client populates
> the Destination Connection ID field with an unpredictable value.
>
> Or
>
> > To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
> containing an unpredictable payload on the path to be validated.
>
> Or
>
> Stateless Reset {
>   Fixed Bits (2) = 1,
>   Unpredictable Bits (38..),
>   Stateless Reset Token (128),
> }
>
> As you say, a bit can assume one of two values, 0 or 1.  Setting a bit to
> a predictable value would mean choosing 0 or 1 in a way that someone might
> be able to guess the next value.  Always 1, always 0, or alternating 0 and
> 1 are examples of predictable methods of selecting a value.  Setting a bit
> to an unpredictable value would mean setting it to either 0 or 1 such that
> someone else is unlikely to correctly guess the next value.  A random draw
> is unpredictable, but there are other methods that would also be
> unpredictable.
>
> On Thu, Jun 30, 2022, at 22:52, Andrew Alston via Datatracker wrote:
> > Andrew Alston has entered the following ballot position for
> > draft-ietf-quic-bit-grease-04: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> >
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-quic-bit-grease/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Thanks for the work on this document,
> >
> > Hopefully this discuss will be relatively easy to resolve - and may
> result from
> > a lack of understanding - but -
> >
> >    Endpoints that receive the grease_quic_bit transport parameter from a
> >    peer SHOULD set the QUIC Bit to an unpredictable value unless another
> >    extension assigns specific meaning to the value of the bit.
> >
> > Now, this is in reference to a bit - which can only be 0 or 1 - and the
> > document further goes on to clarify certain situations where this bit
> should be
> > set or unset - so I am not at all sure what this paragraph really means
> and
> > hoping this can be clarified because I'm not sure how this will be
> interpreted
> > on implementation.
>