Subject: Re: [art] Artart last call review of draft-ietf-quic-manageability-14

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 22 Mar 2022 13:29:11 +0100

Hi Peter,

Many thanks for the review! Apologies for the delay in getting back to you on this, as this fell through the cracks a bit. The comments here not addressed in other changes suggested by other reviews are currently in https://github.com/quicwg/ops-drafts/pull/462 <https://github.com/quicwg/ops-drafts/pull/462>, and will make it into a published copy of the draft soon.

A couple of points, inline...

> On 15 Feb 2022, at 00:30, Peter Saint-Andre via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Peter Saint-Andre
> Review result: Ready with Nits
> 
> ARTART review for draft-ietf-quic-manageability
> Author: Peter Saint-Andre
> Date: 2022-02-14
> 
> Overall this document is in good shape (in particular, I welcome its neutral,
> explanatory tone). I have only small comments.
> 
> In Section 2, the phrase "this document describes version 1 of the QUIC
> protocol" could be slightly misleading, because presumably the protocol itself
> is described in the QUIC specifications. I suggest changing "describes" to
> "addresses".
> 
> It might be helpful to mention that QUIC-specific terminology (e.g., "spin
> bit") is defined in the QUIC specifications.
> 
> Is there a difference between "long packet headers" and "long header packets"?
> Both phrases are used.

There’s a tiny difference — a long packet header is the header itself, and a long header packet is a packet containing a long header. I’ve reviewed the uses in the document and I think, stylistically, we’re using each appropriately everywhere.

> The phrase "cryptographically obfuscated" (used in Section 2.1 and elsewhere)
> is strange. Typically, to obfuscate something means to make it obscure,
> unclear, or unintelligible; this verges on "security by obscurity". It would be
> more accurate to say that constructs like the packet number and key phase are
> cryptographically protected or, even better, that the QUIC protocol ensures
> data confidentiality (e.g., as that term is defined in RFC 4949).
> 
> Can we provide a citation for the term 5-tuple?

I couldn’t find a reasonable one here that didn’t come with other baggage, so I defined it on the first use instead.

Thanks again, cheers,

Brian

> In Section 2.4, I had to read this sentence several times in order to parse it:
> 
>   The content of Initial packets is encrypted using Initial Secrets,
>   which are derived from a per-version constant and the client's
>   destination connection ID; they are therefore observable by any on-
>   path device that knows the per-version constant and considered
>   visible in this illustration.
> 
> I suggest saying "and are considered" to reduce the possibility of confusion.
> 
> 
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Mar 2022 07:58:07 -0600

On 3/22/22 6:29 AM, Brian Trammell (IETF) wrote:
> Hi Peter,
> 
> Many thanks for the review! Apologies for the delay in getting back to 
> you on this, as this fell through the cracks a bit. The comments here 
> not addressed in other changes suggested by other reviews are currently 
> in https://github.com/quicwg/ops-drafts/pull/462 
> <https://github.com/quicwg/ops-drafts/pull/462>, and will make it into a 
> published copy of the draft soon.
> 
>> On 15 Feb 2022, at 00:30, Peter Saint-Andre via Datatracker 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
> There’s a tiny difference — a long packet header is the header itself, 
> and a long header packet is a packet containing a long header. I’ve 
> reviewed the uses in the document and I think, stylistically, we’re 
> using each appropriately everywhere.

Would it make sense to describe this in the text or, perhaps, to 
hyphenate "long-header packet"? (I think the latter is good.)

>> data confidentiality (e.g., as that term is defined in RFC 4949).

I think you missed some instances in your edits:

    Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation
    (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or
    obfuscated in any way.  For other kinds of packets, version 1 of QUIC
    cryptographically obfuscates other information in the packet headers:

and

    The payload of the Initial packet
    is obfuscated using the Initial secret.

and

    The Server Initial datagram also exposes version number, source and
    destination connection IDs in the clear; the payload of the Initial
    packet(s) is obfuscated using the Initial secret.

and

    The packet number length
    is defined by the seventh and eight bits of the header as described
    in Section 17.2 of [QUIC-TRANSPORT], but is obfuscated as described
    in Section 5.4 of [QUIC-TLS].

> I couldn’t find a reasonable one here that didn’t come with other 
> baggage, so I defined it on the first use instead.

Yes, I ran into the same baggage problem when I started to look around; 
defining it on first use is good.

Thanks!

Peter

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 22 Mar 2022 15:04:41 +0100

> On 22 Mar 2022, at 14:58, Peter Saint-Andre <[email-masked]> wrote:
> 
>>> On 15 Feb 2022, at 00:30, Peter Saint-Andre via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> Would it make sense to describe this in the text or, perhaps, to hyphenate "long-header packet"? (I think the latter is good.)

I like the hyphenation fix; I’ll make that change.

>   in Section 5.4 of [QUIC-TLS].

Ah.. I was trying to fix the clearly-odd construct “cryptographically obfuscated”, although in the first instance I did miss one.

The use of “obfuscated” elsewhere is meant to make it clear that, while there are cyptographic operations in use, the secrets are known, so this is really “obfuscated”… However, that detail might not be as relevant here, so “protected” is probably better in all these case. I'lll make that change as well.

Thanks, cheers,

Brian

> Yes, I ran into the same baggage problem when I started to look around; defining it on first use is good.
> 
> Thanks!
> 
> Peter