On Sun, Dec 13, 2020 at 12:40 AM Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
Hello, Eric,
Thanks for your comments! In-line....
On 12/12/20 18:44, Eric Rescorla wrote:
> I do not believe this document should be published as a BCP. I'm
> slightly negative on publishing it as Informational. I would be
> somewhat more positive on Informational if there weren't also a number
> of other drafts on this topic by the same authors. Perhaps they could
> all be folded together into one piece of really solid guidance.
The three documents you are referring to were originally published as a
single document at the time (draft-gont-predictable-numeric-ids), when
we first brought this work to the IETF (almost five years ago), and it
was split into three documents based on the feedback we got from SAAG.
I'm sorry you feel that you are getting inconsistent feedback, but that doesn't really change my opinion about the disposition of this document.
> Turning to specific examples, Section 4 lists a number of practices
> that are described as "common flaws". Out of these, QUIC and
> DTLS both arguably do the following:
>
> o Employing trivial algorithms (e.g. global counters) that result in
> predictable identifiers
>
> o Initializing counters or timers to constant values, when such
> initialization is not required
>
> And potentially:
>
> o Employing the same increment space across different contexts
>
> However, due to their design, QUIC and DTLS are intended to be
> resistant to attacks based on these choices. In particular, they:
>
> 1. Cryptographically authenticate datagrams in order to prevent
> injection attacks.
>
> 2. Encrypt the packet/sequence numbers so that they are not exposed on
> the wire (QUIC all the time and DTLS 1.3).
>
> Of course, it might be the case that these defenses are insufficient
> (that would be useful to know!) but this document does not provide
> much assistance in making that evaluation.
I'd argue the other way around.
For example, if you don't need the ID to share the same increment space,
then, when you are sharing the same increment space, you're potentially
leaking information (resulting from the increments) from one context to
the other, without any requirement to do so.
And my question would be: why do it, when you don't need to? If this
information turned out to be of use for an attacker, would the argument
be "Well, we knew we were unnecessarily leaking information, but even
when we had choices not to, we did it anyways, because we thought it was
harmless"?
Let's take the specific case of QUIC and DTLS packet/sequence numbers.
In both cases, the packet/sequence numbers start from zero and increment
monotonically (arguably violating the first two points) and regardless of path
(violating the second two points). Now, either this is an OK practice because
of header encryption (the position that both QUIC and DTLS take) or it is
a bad practice (the position that this draft seems to take). But we shouldn't
be simultaneously publishing documents which take both positions.
To address your substantive point: I don't think this is leaking information to
the attacker because the headers are encrypted, and having some other
structure would be more complicated in a number of ways.
> Moving to the requirements in S 5, I note that neither QUIC nor DTLS
> recommends an algorithm for generating connection IDs, which would
> violate requirement #3.
>
> 3. Recommend an algorithm for generating the aforementioned
> identifiers that mitigates security and privacy issues, such as
> those discussed in [I-D.irtf-pearg-numeric-ids-generation].
>
> Instead, QUIC provides requirements for how CIDs must work but not an
> algorithm
> (https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-32#section-5.1).
>
> Connection IDs MUST NOT contain any information that can be used by
> an external observer (that is, one that does not cooperate with the
> issuer) to correlate them with other connection IDs for the same
> connection. As a trivial example, this means the same connection ID
> MUST NOT be issued more than once on the same connection.
I believe that not recommending a good/safe choice for generating IDs
has been proved to be problematic. If a protocol is successful enough,
it's very likely that you will see multiple independent implementations
(from folks that are not involved in the protocol design, etc.), and
that bad choices will be made if there is no recommendation.
As noted above, QUIC connection identifiers are opaque and indeed are
specifically not intended to be interpreted by the other side. Thus if
the structure of those identifiers is relevant, something has gone wrong.
> I'm not saying that cryptographic protocols don't need to take care in
> identifer selection, but the guidance in this document does not seem
> very helpful in that respect. It's no doubt the case that the IETF
> will in the future design some non-cryptographic protocols where this
> kind of guidance will be on-point, but I don't think that in 2020
> we should publish a document as BCP which ignores so much of current
> practice.
Could you please elaborate?
We did evaluate what has happened to multiple protocols from different
layers. And the findings seem to converge for all of them.
I don't think you can claim that what has been done in one specific
protocol from one specific layer is "current practice".
My position is that modern practice is to design protocols that have encryption
(this is strongly encouraged by RFC 7258 and also is just what we're doing)
and this document neither (a) engages with that nor (b) provides particularly
helpful guidance for encrypted protocols.
Almost four years have passed. I wished we could do something to prevent
these issues from continuing to happen in our protocols and their
corresponding implementations. And I'd certainly prefer not to try to
boil the ocean once more.
As I noted, such an effort is already underway, so this work could feed
into it. As your documents are already out there and available in the
drafts repo, I don't feel that there is any rush to have this in RFC form.
-Ekr
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
