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.
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.
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).
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'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.
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. 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).
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.
-Ekr
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.
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.
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.
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'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.
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. 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).
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.
-Ekr
On Mon, Dec 7, 2020 at 7:09 AM The IESG <iesg-secretary@xxxxxxxx> wrote:
The IESG has received a request from an individual submitter to consider the
following document: - 'Security Considerations for Transient Numeric
Identifiers Employed in
Network Protocols'
<draft-gont-numeric-ids-sec-considerations-06.txt> as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2021-01-04. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
Poor selection of transient numerical identifiers in protocols such
as the TCP/IP suite has historically led to a number of attacks on
implementations, ranging from Denial of Service (DoS) to data
injection and information leakage that can be exploited by pervasive
monitoring. To prevent such flaws in future protocols and
implementations, this document updates RFC 3552, requiring future
RFCs to contain analysis of the security and privacy properties of
any transient numeric identifiers specified by the protocol.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-gont-numeric-ids-sec-considerations/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
