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: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
