A couple of small notes inline below.
I have to say that I remain concerned about the thin-ness of section 9. I'm not on the IESG but if I were, and a draft spec for a pretty central piece of Internet infrastructure came in without threat analysis or in-depth security discussion, I would find it very difficult to be happy. Your call.
On Wed, Oct 5, 2022 at 3:46 PM David Schinazi <dschinazi.ietf@xxxxxxxxx> wrote:
Section 2.3 paragraph 4, this is arguably part of the definition of what
"Compatibility" means: that such a document exists with a description of the
server-to-client signaling mechanism. Thus, the definition of "Compatible" at
the start of section 2.2 is arguably incomplete: 'A is said to be "compatible"
with B if it is possible to take a first flight of packets from version A and
convert it into a first flight of packets from version B.'Could you say more about the definition being incomplete please?More specifically, what do you think is missing from the definition?
Well, it's self-evidently incomplete because in 2.3 it's clear that for versions to be compatible, a document needs to exist and you say useful things about what that document has to contain. So I think the spec would be cleaner if you mentioned the document up there in 2.2.
Section 4 paragraph 5 is really hard to understand for this non-QUIC-expert.
An example of the situation where the client might (invalidly) make a choice
incompatible with its knowledge of what the server supports would be useful.That's fair. I couldn't easily find a way to make this clearer, I'll think about it some more.
Suggestion: Add a couple of examples. I'm a huge fan of examples in specifications. I often find that when I have to write them, it forces me to clarify my thinking and has regularly led to improvements in the explanatory text.
Section 9, Security Considerations, seems very short for such a foundational
piece of protocol. I would have hoped to see some discussion of threat models.
(There seems to be good attention to security issues in the body of the
document.)The document defines and mitigates version downgrade attacks, the main concernin any version negotiation, but that's in the body of the document. I don't think movingtext to make the security considerations longer would improve clarity.
Okay, that's useful. If you believe that the major threat scenario is downgrade attacks, and that there aren't any others that are worth addressing in this RFC, it would be useful to say so. Is it a fair assumption that anyone who's going to read this will understand what a "downgrade attack" is, so there's no benefit from describing the scenario?
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
