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

[Fernando Gont <[e-mail]>]

Hello, Eric,

On 13/12/20 18:52, Eric Rescorla wrote:
> On Sun, Dec 13, 2020 at 12:40 AM Fernando Gont <[e-mail] 
> <mailto:[e-mail]>> wrote:
[....]
>      > 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). 

This is what our document says:

    1.  Clearly specify the interoperability requirements for the
        aforementioned identifiers (e.g., required properties such as
        uniqueness, along with the failure severity if such properties
        are not met).

    2.  Provide a security and privacy analysis of the aforementioned
        identifiers.

    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].

I'm not sure how what you describe is violating points #1 and #2, 
because #1 is essentially what a proper specification should have anyway 
(interoperability requirements) and you might argue that you should be 
doing #2 anyway (most implementations don't, but should).




> 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.

The attacker could certainly be the remote endpoint you are 
communicating with -- it need not be an off-path or on-path attacker.
*If* employing such identifiers was leaking information about other 
network activities you're performing, would allow for tracking, or any 
variation of this, that'd still be information leakage in by book.


[...]
> 
>     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.

Nobody argued about structure in the connection IDs, but generating them 
in a way that they are unpredictable.

e.g., what if connection-ids were generated from a global counter? 
According to the QUIC spec, that'd be one possible implementation.



>      > 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.

You seem to be referring to mitigating data injection attacks, or to 
provide confidentiality to the data stream via crypto. Nobody is arguing 
against that.

In that context, what we are arguing is that even if you encrypt, if you 
use improper identifiers you could leak information to the other 
endpoint -- which can read and analyze the identifiers, because its the 
intended destination of your packets.

You also seem to focus on the particular case of data injection against 
transport protocols. I'd note that there are identifiers such as IPv6 
Fragment Identifiers, transport protocol ephemeral ports, IPv6 Interface 
Identifiers, and others, where use of crypto as for the specific case 
and protocol that you're referring to does not apply.



>     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.

We seem to disagree in this respect.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492