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

[Benjamin Kaduk <[e-mail]>]

Hi Ekr,

On Sat, Dec 12, 2020 at 01:44:29PM -0800, 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.

Perhaps you could review the recording of the SECDISPATCH session at IETF
104 and discuss what was missed at that time?  (Sadly, there do not appear
to be minutes posted, for which I share some of the blame.

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

I'm not entirely sure that it does...

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

So, I think that QUIC and DTLS (perhaps QUIC moreso than DTLS are actually
making use of the type of reasoning that this document attempts to instill.
The consequences of failure are reduced by the use of cryptographic
protections (since they are only accessible to the endpoints as opposed to
being visible to on-path attackers and attackable from off-path), but there
is still benefit from considering the situation and specifying exactly what
is needed for interoperability and no more.

For example,
https://tools.ietf.org/html/draft-ietf-quic-transport-33#section-21.4
discusses an "optimistic ACK" attack and allows an endpoint to skip packet
numbers when sending, to discover such scenarios.  This preserves the
needed property of ordering but weakens the identifier away from being a
strict counter.  (I don't think DTLS 1.3 currently covers this ... perhaps
it should.)  The QUIC behavior matches up quite nicely to the text from
this draft:

   At times, a protocol needs to convey order information (whether
   sequence, timing, etc.).  In many cases, there is no reason for the
   corresponding counter or timer to be initialized to any specific
   value e.g. at system bootstrap.  Similarly, there may not be a need
   for the difference between successive counted values to be a
   predictable.

The encryption of the counter on the wire does seem to be an okay
justification for starting the counter at zero, though -- we should update
the relevant discussion in this draft to account for that class of
behaviors.

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

As was noted downthread, using a single global counter for connection IDs
would probably be a bad idea.  My understanding is that we generally expect
CIDs to be picked as unpredictable values (and for good reasons), though
not necessarily to be entirely random; documenting that property, as
suggested by this draft, seems to be in order.  And mea culpa for not
thinking about it during AD review!

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

RFC 3552 is quite general in its requirements, yes, but as I noted to Russ,
it provides a great deal of variety in its listing of "Common Issues".  Are
you arguing that the issues this document raises relating to transient
(numerical) identifiers do not qualify as "Common Issues" in that sense?

> 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 can only assume that you refer to the IAB Model-T program, here.
However, that activity is explicitly not chartered to produce an update to
3552, but rather to (I think I am paraphrasing) produce some advice that
the IETF might consider in a potential effort to revisit 3552.  Whether or
not such an actual effort to revise 3552 would materialize in practice
remains unclear, so I'm opposed to use the potential existence of such
future work as a reason to not do something that's currently under
consideration.  (To be clear, there might be other valid reasons for not
doing the thing under consideration, but the Model-T program's future
output is not one of them, to me.)

Thanks,

Ben

> On Mon, Dec 7, 2020 at 7:09 AM The IESG <[e-mail]> 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
> > [e-mail] mailing lists by 2021-01-04. Exceptionally, comments
> > may
> > be sent to [e-mail] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> >

> -- 
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call