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,

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.



> In terms of technical content, the concerns on which this draft
> focuses feel oddly out of place when set against many protocols we are
> designing today.
> 
> At a high level, many of the attacks listed here (especially in TCP)
> result from the reliance (potentially accidental) on unpredictable
> identifiers as a countermeasure against various forms of attack. For
> instance, TCP is subject to a variety of off-path injection attacks
> which are partly mitigated by randomizing sequence numbers and port
> numbers. However, the more modern practice is to cryptographically
> authenticate datagrams, thus preventing injection attacks even if the
> port and sequence number are predictable.

I don't think the two are mutually-exclusive. Nobody is arguing that 
randomizing numeric IDs is an alternative to cryptographic authentication.

What we mean is that predictable identifiers tend to have negative 
implications in a number of areas. In cases where (unfortunately) you 
don't have cryptographic authentication, they make attacks easier. In 
other cases, predictable IDs leak information.

And what we say is: you should analyze and state what are the 
interoperability requirements, and suggest an algorithm that meets those 
requirements, while making the IDs leaks as little information as possible.

That's simply being proactive. And I'd be very curious to see an 
argument against this principle in the context of security.




> 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"?




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

Clearly, anybody implementing a protocol needs to make a decision as to 
e.g. how to generate IDs (whether for this particular protocol, or any 
other one). I'm not sure why one would put every implementer in the 
position of having to select an algorithm on their own.  There's a very 
long history of this leading to problems whenever bad choices can lead 
to problems.



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



> On the specific topic of requirements and updating RFC 3552. While I
> understand the urge to list out some requirements for protocols, this
> level of specificity is a poor match for 3552, which is quite general
> in its requirements.

FWIW, this work was motivated when we realized that the same kind of 
problem had been plagued all sort of protocols from different layers.

If we experience the same problem in multiple specifications of 
different protocols, and multiple implementations of each of such 
protocols, I would expect that we should be doing something to at least 
prevent that same problem from continuing plaguing protocol 
implementations and specifications.

I'd note that while the topic might seem as very specific, the use of 
identifiers is actually quite general. Every single protocol that I can 
think of makes use of them.




> It's also odd to have a requirement for a privacy
> analysis for one particular type of data when the IETF has explicitly
> decided not to require a Privacy Considerations section (see RFC
> 6973).

Not sure what you mean.  Not requiring a Privacy Considerations section 
!= not requiring a privacy analysis (since such analysis could be placed 
in the Security Considerations section). For instance, RFC6973 says:

    The guidance provided here can and
    should be used to assess the privacy considerations of protocol,
    architectural, and operational specifications and to decide whether
    those considerations are to be documented in a stand-alone section,
    within the security considerations section, or throughout the
    document.


And this work doesn't target any specific type of data (e.g., the 
document is not about "sequence numbers" or "ephemeral ports", 
specifically). Quite the contrary, it is quite generic: it applies to 
everything ranging from transport protocol ephemeral ports and sequence 
numbers to IP-layer fragment identifiers, DNS TIDs, or IPv6 Interface 
Identifiers.




> I *would* be in favor of strengthening RFC 3552's requirements (for
> instance, at this point, I believe we should require formal analysis
> for cryptographic protocols) but I don't think that should happen by
> piecemeal adding requirements based on the interests of individual
> draft authors. I note that there is currently an effort open too
> revisit pieces of 3552, so perhaps something like this could be added
> there.

I would note that almost five years ago, when we first brought this work 
to the IETF, it was argued that the groups should work on a rfc3552bis 
effort, and that the work on predictable IDs should be part of that 
larger effort.

I noted at the time that I was afraid that such effort would take ages 
to complete (if ever!).

The first and last rev of that document (draft-nir-saag-rfc3552bis-00) 
was published in August 2016.

Since there, there have been yet more published vulnerability advisories 
related to predictable numeric IDs.

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.

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