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

[Martin Thomson <[e-mail]>]

I've prepared two versions:

Something like what Lucas said: https://github.com/quicwg/quic-bit-grease/pull/30
Minimal: https://github.com/quicwg/quic-bit-grease/pull/29

I'll leave this to those that had more trouble with the language to let me know what they prefer.


On Mon, Jul 4, 2022, at 19:07, Andrew Alston - IETF wrote:
> Sorry for the delayed response,
> 
> I think Lucas’s statement is fair here – so if we can agree on t hat – 
> I’d be ok with clearing my discuss on this one 
> 
> Thanks
> 
> Andrew
> 
> 
> *From:* Lucas Pardue <[e-mail]> 
> *Sent:* Friday, July 1, 2022 3:58 AM
> *To:* Martin Thomson <[e-mail]>
> *Cc:* Andrew Alston - IETF <[e-mail]>; The IESG 
> <[e-mail]>; [e-mail]; WG Chairs 
> <[e-mail]>; QUIC WG <[e-mail]>
> *Subject:* Re: Andrew Alston's Discuss on 
> draft-ietf-quic-bit-grease-04: (with DISCUSS)
> 
> 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 <[e-mail]> 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.