Re: [Last-Call] Last Call: <draft-gont-numeric-ids-sec-considerations-06.txt> (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice

[Eric Rescorla <[e-mail]>]

On Sun, Dec 13, 2020 at 12:40 AM Fernando Gont <[e-mail]>
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