Subject: 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

From: Russ Housley <[email-masked]>
Date: Wed, 9 Dec 2020 16:09:07 -0500

I have to comments.

1) I do not see this document as a BCP.  Despite the inclusion of the boilerplate, there is not a single MUST in the document.  I have no objection to an Informational RFC.

2) The document is really about transient identifiers.  It does not only apply to ones that are numeric.

Russ

> On Dec 7, 2020, at 10:08 AM, The IESG <[email-masked]> 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
> [email-masked] mailing lists by 2021-01-04. Exceptionally, comments may
> be sent to [email-masked] 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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Dec 2020 13:14:55 -0800

Hi Russ,

Thanks for the comments.

> 1) I do not see this document as a BCP.  Despite the inclusion of the boilerplate, there is not a single MUST in the document.  I have no objection to an Informational RFC.

The assumption/expectation was that this would become part of BCP 72 along
with RFC 3552.  Do you think it should be a standalone document, or can you
propose normative language that would make it more appropriate as a BCP?

> 2) The document is really about transient identifiers.  It does not only apply to ones that are numeric.

That's probably true.  Numeric identifiers have some additional
properties/structure that have specific considerations, but the core
concerns do apply to non-numeric identifiers as well.  (Proposed text would
be wonderful, of course.)

Thanks again,

Ben

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 9 Dec 2020 16:24:46 -0500

> On Dec 9, 2020, at 4:14 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Russ,
> 
> Thanks for the comments.
> 

I'd advise an Informational document.  I think an additional section with normative text would be needed or additional normative paragraphs after each of the problem descriptions would be needed.

> be wonderful, of course.)

I looked at several sentences, and I think that just dropping "numeric" is a fine solution.

Russ

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Dec 2020 21:53:24 -0300

Hi, Russ,

Thanks a lot for your feedback! In-line....

> 1) I do not see this document as a BCP.  Despite the inclusion of the boilerplate, there is not a single MUST in the document.  I have no objection to an Informational RFC.

FWIW, version -04 had the following text:

---- cut here ----
5.  Security and Privacy Requirements for Identifiers

    Protocol specifications that specify transient numeric identifiers
    MUST:
---- cut here ----

This was changed in response to feedback we got. But we could add some 
text in that line, whether "MUST" or "SHOULD"

I believe it would be a shame for us to be unable to do a BCP on the 
topic, given the bad track the IETF has had with respect to transient 
identifiers, and given that, for multiple reasons, this effort has taken 
about 5 years so far....

> 2) The document is really about transient identifiers.  It does not only apply to ones that are numeric.

That's probably the case. However, the ones we assessed are all numeric 
identifiers. And those are the ones that we have analyzed in the 
companion document draft-irtf-pearg-numeric-ids-generation

Just curious: what are the non-numeric transient identifiers you had in 
mind?

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Dec 2020 22:09:39 -0300

Hi, Russ,

On 9/12/20 18:24, Russ Housley wrote:
[....]
> I'd advise an Informational document. 

FWIW, our intent is to have a BCP document that is part of (i.e., 
updates) BCP72.  Given that flawed transient identifiers have plagued 
most IETF protocols we can think of, we believe the topic deserves a BCP.

> I think an additional section with normative text would be needed or additional normative paragraphs after each of the problem descriptions would be needed.

Could you please elaborate?

What we mean is that specs should spell out the interoperability 
requirements, perform a security and privacy assessment of the 
identifiers, and suggest an algorithm for them.

That's essentially the three requirements.

Thanks!

Regards,

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Dec 2020 09:34:12 +0100

Hi Fernando and others,

This is a pretty good document, and on the whole I applaud your focus on improving the resiliency of the overall architecture.

I have but one issue.

There is brief mention of TCP ports in the introduction, and a misstatement in the bullet list referred to on the top of page 3 - “predictable transport protocol numbers” where I think you mean transport protocol port numbers.  You refer also to TCP ports in Section 3.  You may well be right that there was no security consideration given initially to these numbers (I don’t know- I wasn’t there).  You may also be right that services can be the subject of various forms of attack based on these numbers.

However, the document doesn’t really go into enough detail to discuss the tradeoffs that are necessary around to be helpful in the context of this registry.  In many cases, it would be perfectly fine for clients to make use of QUIC or HTTPS, and indeed that happens to such an extent that we can’t easily measure it (a testament to LetsEncrypt, the TLS WG, and QUIC, I suppose).  As a port reviewer, I see two continuing challenges for implementations:

Service discovery and autonomic configuration.  Put more simply, plug and pray.  A great many of our requests are focused on just that, requiring a UDP port for multicast and a TCP port to get through enterprise firewalls.
Supervisory architectures in which more than one entity may be responsible for a service.  Not everything can run on port 443 in these instances, and yet the tooling wants to discover those functions.

This is a lengthy discussion, and as Mirja should have been reminding me (yes, it’s of course your fault Mirja), I am remiss in writing up a draft about this.  My suggestion is that you drop the topic of TCP/UDP port numbers, except to perhaps suggest that some consideration is needed about their utility versus the risks, and that this needs to be further explored.  No need to otherwise hold up this good work.

When we get around to that document, we can update again RFC 3552 but also RFC 6335.

IMHO we can do a lot better on improving privacy and resilience wrt discovery.

Eliot

> On 11 Dec 2020, at 01:53, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Russ,
> 
> This was changed in response to feedback we got. But we could add some text in that line, whether "MUST" or "SHOULD"
> 
> I believe it would be a shame for us to be unable to do a BCP on the topic, given the bad track the IETF has had with respect to transient identifiers, and given that, for multiple reasons, this effort has taken about 5 years so far....
> 
> 
> That's probably the case. However, the ones we assessed are all numeric identifiers. And those are the ones that we have analyzed in the companion document draft-irtf-pearg-numeric-ids-generation
> 
> Just curious: what are the non-numeric transient identifiers you had in mind?
> 
> Thanks!
> 
> Regards,
> --
> Fernando Gont
> SI6 Networks

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Dec 2020 08:04:37 -0300

Hello, Eliot,

Thanks a lot for your comments! In-line....

On 11/12/20 05:34, Eliot Lear wrote:
> Hi Fernando and others,
> 
> This is a pretty good document, and on the whole I applaud your focus on 
> improving the resiliency of the overall architecture.

Thanks!

> I have but one issue.
> 
> There is brief mention of TCP ports in the introduction, and a 
> misstatement in the bullet list referred to on the top of page 3 - 
> “predictable transport protocol numbers” where I think you mean 
> transport protocol port numbers. 

Indeed! We should fix this. (thanks!)

> You refer also to TCP ports in Section 
> 3.  You may well be right that there was no security consideration given 
> initially to these numbers (I don’t know- I wasn’t there).  You may also 
> be right that services can be the subject of various forms of attack 
> based on these numbers.
> 
> However, the document doesn’t really go into enough detail to discuss 
> the tradeoffs that are necessary around to be helpful in the context of 
> this registry.

FWIW, in the context of this document, the mention of transport protocol 
port numbers (or any other ntransient numeric ID, for instance) is for 
illustrative purposes.  The discussion of specific I-Ds is in 
draft-irtf-pearg-numeric-ids-generation . And, when it comes to 
transport protocol port numbers in particular, that document references 
RFC6056 (which I co-authored), since it covers all the relevant details.

That is, draft-gont-numeric-ids-sec-considerations focuses on the BCP 
stuff to analyze transient numeric IDs in new specs.  Whereas 
draft-irtf-pearg-numeric-ids-generation analyzes different categories of 
transient numeric IDs, and proposes algorithms for each.

> In many cases, it would be perfectly fine for clients to 
> make use of QUIC or HTTPS, and indeed that happens to such an extent 
> that we can’t easily measure it (a testament to LetsEncrypt, the TLS WG, 
> and QUIC, I suppose).  As a port reviewer, I see two continuing 
> challenges for implementations:
> 
>   * Service discovery and autonomic configuration.  Put more simply,
>     plug and pray.  A great many of our requests are focused on just
>     that, requiring a UDP port for multicast and a TCP port to get
>     through enterprise firewalls.
>   * Supervisory architectures in which more than one entity may be
>     responsible for a service.  Not everything can run on port 443 in
>     these instances, and yet the tooling wants to discover those functions.

Please note that when we refer to "transport protocol port numbers", 
service ports are excluded from those. (maybe it would be more clear if 
we said "transport protocol ephemeral port numbers"?) (since I realize 
that "transport protocol port numbers" could also be interpreted as 
server-side service ports, too)

[...]
> IMHO we can do a *lot* better on improving privacy and resilience wrt 
> discovery.

Note that we do *not* target service ports. Those ports are not 
"transient numeric identifiers", because the server-side port has 
overloaded semantics (it identifies the service) -- so it *has* to be a 
specific value. Only if, say, a system were using something ala e.g. SRV 
records, servers could use "transient numeric identifiers".

(i.e., think of this document as a bcp to have spec authors write down 
what the interoperability properties that they need in the transient 
numeric IDs they use, do the associated analysis, and then propose an 
algorithm for them.  e.g., you could say that if we were to specify e.g. 
TCP/SCTP today, the spec should include something like what's in RFC6056).

Please let me know if the above clarifies the intent of the document.

Thanks!

Regards,
Fernando

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Dec 2020 13:23:06 +0100

Hi Fernando,

Thanks for your quick response.  I’d say that we are pretty much in line.  One additional comment:

> 
> Note that we do *not* target service ports. Those ports are not "transient numeric identifiers", because the server-side port has overloaded semantics (it identifies the service) -- so it *has* to be a specific value. Only if, say, a system were using something ala e.g. SRV records, servers could use "transient numeric identifiers”.

Along with considering perhaps a tweak or two based on the previous message, I hope we can collaborate over time on the privacy aspects of service discovery that might further reduce the need for the port registry.

Eliot

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Dec 2020 09:36:27 -0300

Hi, Eliot,

THanks a lot for your timely response! In-line...

On 11/12/20 09:23, Eliot Lear wrote:
> Hi Fernando,
> 
> Thanks for your quick response.  I’d say that we are pretty much in 
> line. 

Just double-checking: should we note "transport protocol ephemeral port 
numbers" to avoid the possible confusion?

> One additional comment:
>> overloaded semantics (it identifies the service) -- so it *has* to be 
>> a specific value. Only if, say, a system were using something ala e.g. 
>> SRV records, servers could use "transient numeric identifiers”.
> 
> 
> Along with considering perhaps a tweak or two based on the previous 
> message, 

Please do let me know if suggested tweak would make the document more 
clear. And also if there are others to apply. -- I'm all for improving 
the document if possible!

> I hope we can collaborate over time on the privacy aspects of 
> service discovery that might further reduce the need for the port registry.

Definitely!

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Dec 2020 11:30:36 -0300

> propose normative language that would make it more appropriate as a BCP?

The most straightforward way seems to be to introduce the three numbered 
items from Section 5 as:

    {MUST,SHOULD}:

I guess either "MUST" or "SHOULD" would do.

> be wonderful, of course.)

I'm not sure I can come up with transient identifiers that are not 
numeric -- in the worst case, they might be represented e.g. via 
"characters", but at the end of the day an implementation would be 
processing them as numbers.

That aside, "transient numeric identifiers" is very focused on a topic 
that's well-studied, etc. While it's generally nice to generalize 
concepts as much as possible, as noted I cannot think of transient 
identifiers that are not numeric -- and if there were, I'd be very 
curious how draft-irtf-pearg-numeric-ids-generation would apply to them 
since all the algorithms work on numbers.

Thoughts?

Thanks!

Regards,

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Dec 2020 11:52:43 -0500

Fernando:

> FWIW, our intent is to have a BCP document that is part of (i.e., updates) BCP72.  Given that flawed transient identifiers have plagued most IETF protocols we can think of, we believe the topic deserves a BCP.
> 
> 

It is not a Best Current Practice if the document does not provide MUST and SHOULD statements for implementers to follow.

The current document provides information for implementers to consider in making their design choices, but it falls short if a BCP in my view.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Dec 2020 11:58:06 -0500

> I believe it would be a shame for us to be unable to do a BCP on the topic, given the bad track the IETF has had with respect to transient identifiers, and given that, for multiple reasons, this ef…

My previous message addresses this point.  I won't repeat myself here.

> Just curious: what are the non-numeric transient identifiers you had in mind?

You missed my point.  I would not want someone to think that the guidance here in to relevant because the implementation uses a string variable.

Russ

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Dec 2020 14:17:46 -0300

Hi, Russ,

> The current document provides information for implementers to consider in making their design choices, but it falls short if a BCP in my view.

This document is meant to update RFC2552/BCP72, which was published as a 
BCP. I've just scanned BCP72 for all "MUSTs" and "SHOULDs", and the 
document is written in exactly the same way as the one we have authored 
-- provided we were to intruduce the numbered list in Section 5 with a 
"MUST" or "SHOULD".

Am I missing something?

Thanks,

---

From: Iván Arce (Quarkslab) <[email-masked]>
Date: Fri, 11 Dec 2020 14:33:03 -0300

Hello Russ

> You missed my point.  I would not want someone to think that the guidance here in to relevant because the implementation uses a string variable.

I've missed it as well. Did you mean that the recommendations apply to
any type of protocol object/field used as a transient identifier ?
or that any transient identifier can be mapped to a number (its just a
bit sequence after all) and therefore the "numeric" term is redundant ?

/ivan

-- 
Iván Arce
CTO - Security Analysis
Quarkslab

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Dec 2020 12:43:30 -0500

> On Dec 11, 2020, at 12:33 PM, Iván Arce (Quarkslab) <[email-masked]> wrote:
> 
> 
> Hello Russ
> 

Again, I suggest: s/Transient Numeric Identifiers/Transient Identifiers/

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 12 Dec 2020 13:44:29 -0800

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

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.

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

On Mon, Dec 7, 2020 at 7:09 AM The IESG <[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Fernando Gont <[email-masked]>
Date: Sun, 13 Dec 2020 05:38:40 -0300

Hello, Eric,

Thanks for your comments! In-line....

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

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

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

> (https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-32#section-5.1).
> 

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.

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

> 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

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.

> revisit pieces of 3552, so perhaps something like this could be added

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,

---

From: Iván Arce (Quarkslab) <[email-masked]>
Date: Sun, 13 Dec 2020 18:03:22 -0300

Hello Eric, Fernando

> On 12/12/20 18:44, Eric Rescorla wrote:
..
> randomizing numeric IDs is an alternative to cryptographic authentication.

Indeed. I would further argue that use of authenticated encryption is
not warranted on all protocol designs so dismissing the need for
security and privacy considerations for transient IDs on the basis that
"we encrypt and authenticate the packets anyway" is not a good stance in
general.

>> much assistance in making that evaluation.

The intend of the document is not to provide cryptoanalysis guidance to
evaluate specific protocol designs but to provide general guidance on
how to deal with use of transient numeric identifiers in protocol design.

Indeed, the two protocols that you singled out do not follow our
guidance (they hardly could as the document we are reviewing is not yet
officially published) and assessing if the lack of precision for the
generation of transient IDs weakens the protocols would be a matter for
the respective authors to deal with.

IMO, in the case of QUIC, the Connection ID section specification is
sufficiently complicated to warrant more in-depth analysis.

> has been proved to be problematic.

Indeed, that has been the case even in documents that describe the use
of cryptographic algorithms in protocols.

See, for example, the case of "RFC 25288 - AES Galois Counter Mode (GCM)
Cipher Suites for TLS" which in section 3 states:
(https://tools.ietf.org/html/rfc5288#section-3)

   The nonce_explicit is the "explicit" part of the nonce.  It is chosen
   by the sender and is carried in each TLS record in the
   GenericAEADCipher.nonce_explicit field.  The nonce_explicit length
   (SecurityParameters.record_iv_length) is 8 octets.

   Each value of the nonce_explicit MUST be distinct for each distinct
   invocation of the GCM encrypt function for any fixed key.  Failure to
   meet this uniqueness requirement can significantly degrade security.
   The nonce_explicit MAY be the 64-bit sequence number.

The case below is quite similar and even more specific (it hints at a
particular way of implementing it) than the QUIC example and yet it lead
to discovery 8 years later of at least 4 vulnerable implementations
deployed on the Internet, as described by Bock at. al. in
"Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS"
(https://eprint.iacr.org/2016/475.pdf)

Note that in the AES-GCM in TLS case the need for a counter was
warranted but not explicitly called for and such underspec'd text lead
to flawed implementations. In other cases, a random nonce/ID is better
than a numeric sequential value, we argue that authors should assess
what is appropriate in their particular case and write their spec and
rationale for it accordingly.

> If a protocol is successful enough,

See my preceding paragraph as an example case of that.

>> very helpful in that respect. 

I'd like to dig deeper into that feedback. In which way do you think it
does not seem helpful. What would you expect it to say to be helpful?

Suggested text would be welcomed.

Baring a more detailed proposal I propose to include text that
explicitly calls out that in cases where protocols require cryptographic
algorithms to provide confidentiality and integrity (ie. authenticated
encryption) of the transient identifier fields some of the inherent
weaknesses in transient ID generation may be mitigated.

Does that sound like a sensible caveat?

Note however that even authenticated encryption over transient Id fields
would not prevent some possible attacks, for example privacy leaks where
reuse of an ID sequence across different contexts enables a peer to
reveal information about the other peer.

An example of the above issue motivated "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms"
(https://tools.ietf.org/html/rfc7721)

>> It's no doubt the case that the IETF

>From this commentary I understand that what the BCP ignores is the use
of authenticated encryption over transient ID fields in modern protocol
design. As proposed above, we could call that out explicitly.

Are there any other things of current practice that we ignored ?

> implementations and specifications.

Our intent is to provide general guidance to protocol designers/authors
so the issues we pointed out, commonly seen at different protocol
layers, are addressed proactively early on. If such general guidance is
heeded, that would minimize the effort of assessing the security and
privacy implications of transient IDs on a protocol by protocol basis.

> 
>> I *would* be in favor of strengthening cc's requirements (for
>> draft authors. 

We drafted our document with the intention of addressing what we
perceived as a reoccurring, yet overlooked problem, in protocol design
or implementation, not to serve our personal interests.

Requiring formal analysis of cryptographic protocols would be a
significant improvement for future protocol design and I believe its a
topic that has been discussed on IETF mailing lists, I am looking
forward to such a change.

In the meantime, I argue that our recommendations for transient IDs do
not prevent other recommendations.

regards,
/ivan

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Dec 2020 13:52:46 -0800

> was split into three documents based on the feedback we got from SAAG.

I'm sorry you feel that you are getting inconsistent feedback, but that
doesn't really change my opinion about the disposition of this document.

> when we had choices not to, we did it anyways, because we thought it was

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

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

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

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

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Dec 2020 14:06:39 -0800

> "we encrypt and authenticate the packets anyway" is not a good stance in

Fortunately, that's not the position I am taking. Rather, I am saying that
authenticated encryption is an increasingly common practice and that we
should not publish a set of recommendations in this area which does not
engage with that properly.

> the respective authors to deal with.

This is an odd argument, as the authors of these documents could certainly
have read your documents and adopted your recommendations. But my
point here is different. As I said to Fernando, we are about to publish
these
protocols as PS and yet they appear to violate the guidance here, which
seems
like a bad situation if we are about to publish this guidance as BCP. As
above,
I think the problem is that the guidance is not well suited to this type of
protocol,
which means that this document ought to be adjusted. However, if you
have an argument that it is these protocols that should be revised, that
would
be very good to know.

> rationale for it accordingly.

Well I'm certainly not arguing that it's not important to describe good
practices for cryptographic protocols, but: it seems to me that this RFC
did precisely what your document recommends in S 5.

- It specified the interop requirements (none)
- It provided the security and privacy analysis (they must be unique and
it's bad if they're not)
- It recommended an algorithm (the sequence number)

I would note that the eventual outcome in this case in TLS 1.3 was to
remove the explicit nonce entirely and to replace it with a value generated
from the sequence number.

> does not seem helpful. What would you expect it to say to be helpful?

See above for a specific example.

> Does that sound like a sensible caveat?

Not really, no. I believe substantial rework is needed to address the role
that identifiers work in cryptographic protocols.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Sun, 13 Dec 2020 14:47:25 -0800

> On Dec 13, 2020, at 1:54 PM, Eric Rescorla <[email-masked]> wrote:
> 
> My position is that modern practice is to design protocols that have encryption
> and this document neither (a) engages with that nor (b) provides particularly
> helpful guidance for encrypted protoco

+1

I don’t like the idea of over-specification to provide partial privacy or security. 

If we want or expect that, encryption is required, not these methods. These only make implementations that properly employ security needlessly complex. 

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sun, 13 Dec 2020 23:45:24 -0300

Hello, Eric,

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

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

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.

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

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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 13 Dec 2020 18:55:10 -0800

Hi Russ,

> The current document provides information for implementers to consider in making their design choices, but it falls short if a BCP in my view.

RFC 3552 is pretty sparing with normative language, with most of the key
requirements living in its Section 5 ("Writing Security Considerations
Sections"), which boil down to "you are obligated to accurately depict the
security properties of your protocol, and here are a list of specific
things that are extra-mandatory to consider".  However, RFC 3552 also has a
substantial list of "Common Issues" in its Section 4 and subsections.  My
question to you, is what mechanism(s) you would consider appropriate to add
to the list of "Common Issues".  I think it's pretty clear that a full-on
"bis" document should be able to add to (or or remove from, I suppose) the
list, but what else?  Please consider that as a separate question from
whether these issues would merit inclusion in the RFC 3552 §5 list of
mandatory-to-consider topics -- we may well need to consider that question
as well, in the course of this IETF LC, but I would prefer to hear answers
to the first question at this point.

Thanks,

Ben

---

From: Fernando Gont <[email-masked]>
Date: Sun, 13 Dec 2020 23:51:53 -0300

> I don’t like the idea of over-specification to provide partial privacy or security.

Our document says:

"1" asks specifications to spell out the interoperability requirements 
for the IDs.

"2" explicitly  asks specifications to do an appropriate analysis of the 
security and privacy implications of the IDs.

"3" means: "based on the analysis you did in #2, recommend an algorithm 
that mitigates the identified issues" (i.e., "do what you need to do, in 
the best way you can").

I'm kind of surprised this is being contended.

Thanks,

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 13 Dec 2020 19:46:04 -0800

Hi Ekr,

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

> focuses feel oddly out of place when set against many protocols we are

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

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

> we should publish a document as BCP which ignores so much of current

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!

> decided not to require a Privacy Considerations section (see RFC

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?

> revisit pieces of 3552, so perhaps something like this could be added

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Dec 2020 00:41:31 -0300

Hello, Eric,

On 13/12/20 19:06, Eric Rescorla wrote:
> 
> 
> On Sun, Dec 13, 2020 at 1:03 PM Iván Arce (Quarkslab) 
> <[email-masked] <mailto:[email-masked]>> wrote:
[....]
> Fortunately, that's not the position I am taking. Rather, I am saying 
> that authenticated encryption is an increasingly common practice and 
> that we should not publish a set of recommendations in this area which 
> does not engage with that properly.

The use of proper IDs is pretty orthogonal to the use of encryption.

That said, I wouldn't mind myself incorporating text like Ivan 
suggested, something ala:

    "in cases where protocols require cryptographic
     algorithms to provide confidentiality and integrity (ie.
     authenticated encryption) of the transient identifier fields some of
     the inherent weaknesses in transient ID generation may be
     mitigated."

And/or, something along the lines of:
  "Use of appropriate transient numeric IDs is not a replacement for
   cryptographic methods of protecting a transport-protocol. Rather,
   the use of appropriate transient numeric identifiers results in data
   minimisation [RFC7258] and could, in some cases, increase the
   difficulty to perform some attacks"

> like a bad situation if we are about to publish this guidance as BCP.

I must say that I find it odd that the argument against publishing 
appropriate guidance is "well, we have a document in the pipeline that 
does not go along with such guidance", rather than whether the guidance 
is appropriate or not. Even more when, at the end of the day, the 
recommendations apply to *future* protocol specifications and 
implementations.

That said, the guidance in our document is:

    When a protocol specifies transient numerical identifiers, it is
    critical for the protocol specification to:

A proper spec should always spell the requirements in #1. In fact, the 
biggest reason for which we have recurrently screwed up with numeric 
identifiers is that most specs fail to spell out the interoperability 
requirements for the IDs.

#2 should probably be part of the security considerations anyway. For 
the most part, this has not been the case, and I have not checked the 
QUIC spec in this respect. But given past issues with numeric I-Ds, and 
given the push for data minimization (RFC7258), I'd expect this to be 
part of the security considerations.

Then there's #3. which comes as a natural consequence of #2.

I do believe that all protocol implementations should do steps #1-#3 
above. It could be the case that if one were to do such exercise against 
the QUIC spec, one might find out that some quick implementations might 
be unnecessarily leaking information to the remote endpoint.

In such case, the proper outcome would be to publish a protocol update, 
rather than to thwart appropriate guidance on the topic.

> As above,
> I think the problem is that the guidance is not well suited to this type 
> of protocol,
> would be very good to know.

The answer to this question comes from following steps #1-#2 above.

I haven't done that for QUIC, specifically. But I have added that to my 
TODO list. If it turns out that something is leaking, of course the next 
step will be an updating I-D and a vulnerability advisory. Wished I had 
done that before -- I just haven't.

[....]
> - It recommended an algorithm (the sequence number)

Without having read the referenced paper, it would seem that recomended 
a predictable sequence after assessing that "it's bad if the IDs are not 
unique" highlights were the flaw is. i.e., they failed in step #3 of our 
recommendations.

Thanks,

---

From: Iván Arce (Quarkslab) <[email-masked]>
Date: Mon, 14 Dec 2020 06:38:09 -0300

Hola

> does not engage with that properly.

What do you mean with "does not engage with that properly". What do you
consider proper engagement ?

Is acknowledging the use of authenticated encryption and recommending
its use as a way to mitigate weaknesses associated to transient IDs
proper engagement or do you think there isnt any textual formulation
that would engage properly and therefore the document should not move
forward?

On the specific topic of transient identifiers in authenticated
encryption (or "deterministic encryption") we could refer to the work of
Bellare et. al. (https://eprint.iacr.org/2019/624.pdf) but I doubt that
would be appropriate for a guidance document.

But I am much more concerned about providing guidance to authors of
protocols that are not using or mandating authenticated encryption. It
may be an increasingly common practice but its certainly not a
requirement or a universally adopted practice yet.

> have read your documents and adopted your recommendations. 

I dont see any oddity in pointing that authors of drafts are not
necessarily aware of nor follow the guidance of other draft an different
stages of publication process. They could have or not have read our
document, I am not privvy to what they did, but I guess that isnt
relevant to our discussion.

> But my

I don't understand this rationale for not publishing the draft as BCP.

Some protocols are about to be published as PS and they do not follow
the guidance in our draft therefore the draft should not be published ?

On one hand, I think is evident that protocols published before the BCP
is published may not follow its guidance, I don't see anything wrong
with that, I-D authors aren't constantly monitoring every other I-D to
see if they should revisit their draft based on other drafts that will
be potentially published.

On the other hand, I think that perhaps the authors of said protocols
should check the guidance of our draft and figure out if and how it
applies to their work.

> As

I have not looked into the two specific protocols that you brought up,
but after a quick glance at the excerpt you quoted from the QUIC
document, to me it appears to be insufficient to cover potential
security & privacy issues. In fact, in my previous email I wrote that my
cursory read of section 5.1 of the QUIC spec indicates me that
Connection ID seems sufficiently complex to require more in-depth analysis.

..

> - It recommended an algorithm (the sequence number)

It did not recommend any algorithm, it merely indicated that the nonce
MAY be the 64-bit sequence number but did not mandate it. Clearly, that
was insufficient to prevent broken implementations.

> remove the explicit nonce entirely and to replace it with a value
> generated from the sequence number.

Indeed, which effectively mandated a specific algorithm (section 5.3 of
RFC 8446) thus fulfilling requirement #3 of Section 5 of our draft.

> See above for a specific example.

The specific example I wrote about (AES-GCM in TLS) followed by the
correction in TLS 1.3 that you pointed out seem to support the case of
the 3 requirements of section 5 of our draft.

> Not really, no. I believe substantial rework is needed to address the
> role that identifiers work in cryptographic protocols.

what is the substantial rework that you would expect for a guidance
document ?

/ivan

-- 
Iván Arce
CTO - Security Analysis
Quarkslab

---

From: Joseph Touch <[email-masked]>
Date: Mon, 14 Dec 2020 08:51:32 -0800

> On Dec 13, 2020, at 6:51 PM, Fernando Gont <[email-masked]> wrote:
> 
> "1" asks specifications to spell out the interoperability requirements for the IDs.
> 
> "2" explicitly  asks specifications to do an appropriate analysis of the security and privacy implications of the IDs.
> 
> "3" means: "based on the analysis you did in #2, recommend an algorithm that mitigates the identified issues" (i.e., "do what you need to do, in the best way you can").

#3 jumps to an algorithm. In your other post, you say that:

   mitigated.”

MAY - really? So basically you’re comfortable recommending these pseudo-obfuscation methods, but refer to cryptographic algs as MAY?

What it ought to say, first line of the doc, is “if your protocol expects or uses cryptographic protection means, stop reading here; you’re fine.”

Joe

---

From: Iván Arce (Quarkslab) <[email-masked]>
Date: Mon, 14 Dec 2020 14:28:40 -0300

Hello

On 12/14/20 1:51 PM, Joseph Touch wrote:
>> "3" means: "based on the analysis you did in #2, recommend an
>> algorithm that mitigates the identified issues" (i.e., "do what you
>> need to do, in the best way you can").
> 
>    the inherent weaknesses in transient ID generation *may* be
>    mitigated.”
> 
> MAY - really? So basically you’re comfortable recommending these
> pseudo-obfuscation methods, but refer to cryptographic algs as MAY?
> 

What pseudo obfuscation methods are you referring to?

Sorry ut specifying an algorithm for generation of IDs is not obfuscation.

As for cryptography, yes it MAY or MAY NOT help depending on the
specific protocol on which it applies, how it is applied and what
properties are supposed to be warranted by its application.

Cryptography is not magical dust that fixes everything.

> What it ought to say, first line of the doc, is “if your protocol
> expects or uses cryptographic protection means, stop reading here;
> you’re fine.”

That would be bad guidance, in this thread I've shown at least one
example of how that failed.

-ivan

-- 
Iván Arce
CTO - Security Analysis
Quarkslab

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Dec 2020 14:40:44 -0300

Hello, Joe,

On 14/12/20 13:51, Joseph Touch wrote:
[...]
>> "2" explicitly  asks specifications to do an appropriate analysis of 
>> the security and privacy implications of the IDs.
>>
> #3 jumps to an algorithm.

Of course! What's the point of having every implementer do the necessary 
work to come up with an algorithm to comply with the interoperability 
implications, without causing trouble?

Haven't we learned anything from history?

Every single ID I can think of has had a flawed recommendation in a 
spec, and/or a flawed implementation:

* ephemeral port numbers
* IPv6 IIDs
* IPv4 Frag ID
* IPv6 Frag ID
* TCP sequence numbers
* DNS TID

... you name them.

It's quite surprising that given the bad record, we are even discussing 
this. --  unless there's any interest in having vulnerable specs and/or 
implementations.

> In your other post, you say that:
> 

Yes, may -- as in possibility (i.e., "could", should I say?).

QUIC employs cryptographic methods. Yet the connection-IDs are not 
encrypted.  And even if they were, if an implementation were to generate 
CIDs based on e.g., a global counter, that would leak out (to the remote 
endpoint) the number of connections that have been established.

So yes, crypto does not necessarily solve all problems, as it should be 
evident.

> expects or uses cryptographic protection means, stop reading here; 

No. IMO, it needs to say what it says: "Do the right thing, because 
there's plenty of evidence that when you don't, you'll screw up. Allways 
fail on the safe side".

Thanks,

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Dec 2020 13:34:10 -0500

> to the first question at this point.

I do not think the real message here is how to write security considerations regarding transient identifiers.

I also agree with EKR's position.

Russ

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Dec 2020 16:49:49 -0300

Hello, Russ,

On 14/12/20 15:34, Russ Housley wrote:
[....]
> I do not think the real message here is how to write security considerations regarding transient identifiers.

The whole point of this document is indeed to do an appropriate security 
assessment of transient numeric IDs that should be part of the Security 
Considerations section.

In general, transient numeric IDs are required to have specific 
properties (otherwise, we'd simply use a PRNG). Of course, these 
requirements constrain the extent to which an implementation may 
randomize the associated numeric ID.

In order to be able to do an appropriate security analysis, we first 
need to know what are the associated interoperability requirements that 
the IDs must comply to. That's the #1 thing to understand -- without 
these requirements being explicit, it's impossible to do an appropriate 
analysis (because we don't know the constraints). Given these 
interoperability requirements, one can do an analysis of the possible 
implications of these IDs (e.g., information that might leak). And given 
that analysis, a proper algorithm can to be suggested, and the selection 
can be backed with a proper analysis.

All this boils down to "We need to produce IDs with these properties. 
These are the possible issues that might arising from our identifiers. 
And we suggest to use this algorithm because, given the interoperability 
properties that they must have, that's the best we have been able to 
come up with, avoiding as many issues as possible".

The above is meant to be part of the "Security Considerations" section, 
and thanks to the appropriate analysis, will also result in more 
appropriate IDs being employed. And will also make it easier for 
reviewers to spot when inappropriate IDs are being employed.

Thanks,

---

From: Joseph Touch <[email-masked]>
Date: Mon, 14 Dec 2020 19:34:58 -0800

> On Dec 14, 2020, at 9:28 AM, Iván Arce (Quarkslab) <[email-masked]> wrote:
> 

It’s a LOT more rigorous than the “algorithms” suggested.

If you’re running protocols where these IDs are exposed and that creates a vulnerability, simply using these “algorithms” provides a false sense of safety.

Joe

---

From: Christian Huitema <[email-masked]>
Date: Mon, 14 Dec 2020 20:18:29 -0800

> I also agree with EKR's position.

I also think that EKR has a point.

I think there are two main issues in the document: it does not 
distinguish between identifiers that are "visible on the wire" and those 
that are only visible by the endpoints; and, it suggests an overly 
specific identifier generation algorithm. The document also suffers from 
trying to fit different kinds of protocol parameters in a single 
abstract category, the "Transient Numeric Identifier". This feels 
somewhat artificial.

Fixing the lack of distinction between "visible on the wire" and 
"visible by the end-points" would require fixing the section 3 regarding 
"issues". The current list of issues feels theoretical and detached from 
the actual attacks. It lists:

    o  Protocol specifications that under-specify the requirements for
       their identifiers

    o  Protocol specifications that over-specify their identifiers

    o  Protocol implementations that simply fail to comply with the
       specified requirements

That list of issues seems somewhat self-referential, another way of 
saying "protocols that do not comply with the recommendations in this 
document". If we want to provide guidance, we should instead look at 
categories of attacks enabled by classic mistakes, such as injection 
attacks, correlation attacks, or spoofing attacks. That's the point at 
which we can make a distinction between "visible on the wire" and not -- 
injection attacks, correlation attacks and spoofing attacks by third 
parties are mitigated if the identifier is not visible, but spoofing 
attacks by the connected peer are not.

EKR mentions how much the document is at odd with recent practice, like 
the design of QUIC. QUIC does use a number of identifiers: connection 
identifiers, packet numbers, stream numbers, data offsets within 
streams. If that document had been available before the design of QUIC, 
would it have help development? My personal opinion is no, it would not 
have make the protocol better. It might have created a hurdle during the 
last call reviews, forcing the developers to discuss why they would not 
comply with the recommendation in this draft, and creating additional 
delays in the process for little practical result.

I don't think that the document should be published as is.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Dec 2020 02:05:41 -0300

On 15/12/20 01:18, Christian Huitema wrote:
> that are only visible by the endpoints;

The identifiers are the same.

draft-irtf-pearg-numeric-ids-generation analyzes e.g. how a predictable 
identifier can be exploited by somebody that sees the ID (or can sample 
some),as well as by attackers that can't.

If a protocol employs numeric IDs and does not encrypt the ID, then both 
on-path systems and the remote endpoint will see the ID. If the protocol 
does employ encryption, then only the remote endpoint sees the IDs.

So, "who sees the identifiers" doesn't really change the identifier 
type: it just constrains who can exploit them and how.

> and, it suggests an overly specific identifier generation algorithm.

This particular document does not discuss any algorithms. In fact, the 
advice says:

So the algorithms are provided as *examples*. It's not a requirement to 
pick one of  the algorithms in draft-irtf-pearg-numeric-ids-generation.

> The document also suffers from 

All of the parameters are identifiers of some sort. It's the same type 
of parameter (a transient numeric ID), employed for identifying 
different data objects.

The generalization is not artificial. We came up with it after realizing 
that all transient numeric IDs fall into one of the categories in 
draft-irtf-pearg-numeric-ids-generation, based on the interoperability 
requirements and failure severity.

>     o  Protocol implementations that simply fail to comply with the

These are the three usual failures associated with the specification of 
numeric identifiers. All flawed IDs I know of are the result of one of 
these three issues.

They certainly are *not* the actual attacks, but rather the reasons why 
implementations end up with flawed IDs.

> document".

That's certainly not what we mean. The above text means:

* Some specs fail to spell out requirements (they spec'ed lesss than 
they should have) -- so implementations end up picking flawed algorithms 
because the spec failed to spell out the requiredments for the IDS.

* Some specs over-specify their IDs (the specified more than they should 
ahve), leading to flawed IDs. e.g., traditional IPv6 SLAAC, where the 
requirement should have been that the IID is unique, but the spec ended 
up requiring hosts to embed the MAC address in the IID.

* At times, protocol specs do a good job, but implementations fail to 
comply with the spec, and end up employing flawed IDs. (the protocol 
spec was good, but the implementors screwed up).

Nothing in this list self-references this document. It talks about the 
relevant specs for each of the IDs we analyzed.

> If we want to provide guidance, we should instead look at 

Such discussion is in 
https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-03 .

As noted, the analysis mentions what an attacker that doesn't see the 
IDs can do, and what an attacker that can sample the IDs can do. At the 
end of the day, it doesn't matter if the attacker doesn't see the IDs 
because he's off-path, or because the relevant protocol encrypts the 
numeric IDs -- at the end of the day, the attacker sees the IDs, or he 
doesn't.

> delays in the process for little practical result.

I disagree. I do think that, for example, the specification of 
connection IDs is sub-optimal.

I missed the LC for that document. But my understanding is that IESG 
review is pending. So hopefully the issue will be raised -- not to 
thwart progress, but to help improve the spec.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Dec 2020 02:12:49 -0300

Hi, Joe,

On 15/12/20 00:34, Joseph Touch wrote:
> 
> 
>> On Dec 14, 2020, at 9:28 AM, Iván Arce (Quarkslab) 
> If you’re running protocols where these IDs are exposed and that creates 
> a vulnerability, simply using these “algorithms” provides a false sense 
> of safety.

Flawed IDs introduce problems. IDs that are not flawed do not.

Using proper IDs such that they don't introduce issues means just that. 
The *the transient numeric IDs* won't be exploitable -- just that -- 
which is certainly not a sufficient condition to claim that a protocol 
is "safe" (whatever that means) -- since "safaty" might depend on a lot 
of other things.

Thanks,

---

From: Iván Arce (Quarkslab) <[email-masked]>
Date: Tue, 15 Dec 2020 09:57:32 -0300

Hello

> that are only visible by the endpoints; 

I suggested text to address that point by specifically calling out that
identifiers covered by authenticated encryption may not suffer from the
described weaknesses. I also explained why "may" or "could" is
appropriate, as the presence of cryptography is not by itself a solution
to every possible problem. It depends on how it is applied and the
properties of the transient ID in the specific protocol at hand.

> and, it suggests an overly
> specific identifier generation algorithm. 

This is simply not the case. There isnt any single algorithm in the
draft, it merely requires the author of a protocol to recommend an
algorithm to address any potential security & privacy issue identified
in the protocol. It does require the author todo the exercise of
identifying potential issues.

The document points at another draft
(https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-03)
where 4 specific algorithms are listed as suitable for different
scenarios. The algorithms in that draft are not made of up thin air,
they were actually used in different protocols to address security and
privacy problems.

For example, RFC 6528 which is a Proposed Standard proposed a very
specific algorithm to address security issues in TCP ISN generation.
https://tools.ietf.org/html/rfc6528#page-4

> abstract category, the "Transient Numeric Identifier". This feels

Indeed, all abstraction is artificial but most protocols use some form
of transient numeric identifier as described in the draft so it isnt an
invalid abstraction.

Our abstraction is based on empirical evidence, actual documented issues
involving numeric IDs in different protocols.

We've seen that over 30+ years the same issues have arised in protocols
at different layers due to the way those IDs are generated, we looked at
the many occurrences of such events, classified and abstracted the
common reasons of why it happened. The intention of the draft is,
precisely, to present this as a general problem with the use of IDs,
(since there is evidence that supports that view) that can be dealt with
proactively rather than how it is done now, on a case by case basis
years after a protocol specification is published and several
implementations are found flawed.

If protocol authors cannot learn from the past experience in IP, TCP,
DNS and other protocols that introduced, and years later solved these
problems then we are bound to repeat those experiences.  The intention
of our draft is to present the issue to protocol authors and provide
them with a resource to help them address it, should they need to do so
in their protocol.

> the actual attacks. 

It is exactly the opposite.

The list was built as a result of looking at actual, real problems in
various protocols. A non-exhaustive list of them is presented in Section
1. An actual, historical review of those problems in a subset of those
protocol is included in [I-D.irtf-pearg-numeric-ids-history]
(https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-history-04.txt)
which was originally part of the same draft but later forked to a
separate document as a result of WG discussion.

> It lists:>

That is is what distinguished all the cases that we looked into.
What we identified is that when there was a security or privacy issue
due to use of a transient ID, the root cause was one of those 3 cases.

It can hardly be self-referential because the problems and their causes
precede the writing of our draft. The list describes what has happened,
it isn't a fantasy we made up to fabricate a draft.

> attacks by the connected peer are not.

That is a partial characterization of the problem that does not cover
some actual attacks that occurred in real life.

Off-path attackers have no visibility over ID fields used in network
flows between other peers, and yet injection attacks have been possible
because transient IDs were used in ways that made communications
vulnerable. Notorious examples cases are TCP session hijacking and DNS
cache poisoning, to name just a few.

Correlation attacks are certainly possible even in the case of IDs not
"visible on the wire", for example when a legitimate peer can infer
current, past or future state of the other peer by sampling a sequence
of IDs provided by the counterpart.

Making protocol objects not "visible on the wire" does not prevent
spoofing, strong authentication and integrity does. Cryptography can
provide all or just some of those properties, confidentiality (making
things "not visible on the wire") is not sufficient.

But even if authenticated encryption (or "deterministic encryption" as
some people call today) is employed, the specific properties of the
protocol objects protected with encryption may still weaken the protocol.

> streams.

I could equally argue that QUIC is at odds with the proposed practice.
As I mentioned in prior emails, I do not believe that should prevent or
delay publication of QUIC as our draft is still being discussed.

In any case, I find it at a minimum odd that the case of a single
protocol specification (or rather two to be fair since Eric Rescorla
mentioned QUIC and DTLS) is brought up as an example of recent practice
as if such practice was widespread in every IETF WG.

And since you mentioned QUIC please note that in "21.1.1.4.  Parameter
Negotiation" which is part of the draft's Security Considerations the
authors write:

   Connection IDs are unencrypted but integrity protected in all
   packets.

which is consistent with my above comment about what "invisibility on
the wire" gains us. Accordint to the authors, in QUIC, connection IDs
are visible but cannot be tampered with by an on-path attacker. Whether
that is sufficient to address all potential issues of transient
identifiers, I dont know. It's a 150+ page document and I might read it
all sometime in the future. At a first glance and as I noted in a prior
email, I believe the Coneection ID in QUIC is sufficiently complex to
require a more in depth analysis.

> If that document had been available before the design of QUIC,

If the delay was to address, before publication, a weakness identified
in the use of transient IDS proposed in the protocol then it would be
justified. I would rather see that happening than having the protocol
promoted to PS, implementations deployed massively, and years later find
out that they suffer a common problem due to lack of proper guidance on
how to deal with security and privacy associated to certain protocol
objects.

> I don't think that the document should be published as is.

I've proposed text that acknowledges that use of authenticated
encryption to protect transient identifiers may or could eliminate or
mitigate the weaknesses we describe.

Are there other specific things in the document that you think should be
addressed ?

regards,
/ivan

-- 
Iván Arce
CTO - Security Analysis
Quarkslab

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Dec 2020 22:04:05 -0300

> I don’t like the idea of over-specification to provide partial privacy or security.

It's quite the opposite.

Our document requires specifications to spell out the interoperability 
requirements, because quite too often speficiations specify things they 
need not.

For example, the QUIC spec specifies sequence numbers start at 0. *That* 
is an over specification. Because sequence numbers need not start at zero.

We simply require that specifications spell out the interoperability 
requirements for their identifiers, that they do a security and privacy 
analysis for them, and that they suggest one possible algorithm that 
would be well suited to generate the IDs, such that every implementer is 
not left to solve the question "now, what the heck should I use to 
generate these identifiers?".

Thanks,

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Dec 2020 20:08:37 -0800

On 12/16/2020 5:04 PM, Fernando Gont wrote:
> requirements, because quite too often speficiations specify things 
> they need not.
>
> For example, the QUIC spec specifies sequence numbers start at 0. 
> *That* is an over specification. Because sequence numbers need not 
> start at zero.

QUIC does not mandate that sequence numbers start at 0. Implementations 
can choose to start at random numbers, with the limitation that these 
numbers shall be lower than 2^32. That functionality had been verified 
in interop testing. There just are not too many benefits in doing that.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 01:35:26 -0300

On 17/12/20 01:08, Christian Huitema wrote:
[...]
> QUIC does not mandate that sequence numbers start at 0.

Section 5.1.1 of draft-ietf-quic-transport-29 says:
"  The sequence number of the
    initial connection ID is 0.  If the preferred_address transport
    parameter is sent, the sequence number of the supplied connection ID
    is 1.
"

Later in the same section, it says:

"  The sequence number on
    each newly-issued connection ID MUST increase by 1. "

OTOH, with respect to connection I-Ds, Section 5.1.1 says:

    "Each
    endpoint selects connection IDs using an implementation-specific (and
    perhaps deployment-specific) method which will allow packets with
    that connection ID to be routed back to the endpoint and to be
    identified by the endpoint upon receipt.

    MUST NOT be issued more than once on the same connection."

But then, the next section ("5.1.1.  Issuing Connection IDs") talks 
about randomized connection IDs:

    The connection
    ID randomly selected by the client in the Initial packet and any
    connection ID provided by a Retry packet are not assigned sequence
    numbers unless a server opts to retain them as its initial connection
    ID.

So yes: sequence numbers seem to be over-specified, and connection-ids 
seem to be under-specified.

What am I missing?

Thanks,

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Dec 2020 21:19:32 -0800

On 12/16/2020 8:35 PM, Fernando Gont wrote:
>>> Our document requires specifications to spell out the 
>>> interoperability requirements, because quite too often speficiations 
>>> specify things they need not.
>>>

When you mentioned "sequence numbers", I thought that you were referring 
to packet sequence numbers.

Connection ID sequence numbers are something else entirely. The sequence 
numbers are used to manage the creation and release of the Connection ID 
objects. For a variety of protocol reasons, the connection ID sequence 
numbers must start at zero.

This is actually a great example of the kind of discussions that would 
arise if this draft was published. You lob these "connection ID sequence 
numbers" is the arbitrary category of "temporary identifiers", and start 
making generic statements about the need to apply some kind of 
randomization. Yet the "connection ID sequence numbers" are never 
visible on the wire, and there is no reason to believe that they have 
any effect on the security or privacy considerations of the protocol.

> seem to be under-specified.

In short, you are missing the tons of discussions that went into that 
specification, taking into account the needs of a variety of 
environments including for example server farms. You are also picking 
out the Initial Connection ID out of context -- for protocol reasons, it 
is not generated in the same way as other connection IDs.

Again, you are providing a great example of why the IETF should not 
publish this draft. It is using an abstract generalization of 
"identifiers" to draw broad recommendations that are at odds with actual 
protocol development practice. Endorsing these recommendation in a BCP 
or even an informational RFC will be harmful, because it will cause 
unnecessary discussions, just like the one we are having here.

When I saw the first iterations of this work, my feeling was that 
documenting a class of design failures was great, but trying to go from 
there to design mandates was going too far. A couple years later, my 
opinion has not change. An informational document documenting a series 
of past attacks would be interesting and educational. The kind of rule 
making proposed in the draft, on the other hand, would be mostly harmful.

-- Christian Huitema

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Dec 2020 17:07:00 +1100

Everything else Christian says here about QUIC is accurate.  I see nothing there that suggests a problem in need of attention.  I would also point to https://tools.ietf.org/html/draft-ietf-quic-load-balancers for a more nuanced treatment of the connection ID selection problem.

On Thu, Dec 17, 2020, at 16:19, Christian Huitema wrote:
> An informational document documenting a series 

...but this is the most important message.  Removing Section 5 and all that depends on it would make this a better document.

Separately, I found the list of potential problems in Section 4 to be approximately OK, though it lacked any mention of a need to synchronize changes across protocol layers.  I acknowledge that that is about use rather than generation, but that is quite relevant here too.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 03:51:54 -0300

Christian,

On 17/12/20 02:19, Christian Huitema wrote:
[....]
> numbers must start at zero.

I expect that "variety of reasons" to be in the protocol specification.

> randomization.

Once more, you're misrepresenting what our document is saying.

Let's go through them once more:

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

This is largely unspecified for many of the QUIC numeric IDs. you claim 
"For a variety of protocol reasons, the connection ID sequence numbers 
must start at zero.". If that's needed, this requirement should be an 
explicit interoperability requirement, and the reasoning should be provided.

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

This part is also missing. It might be the case that there are no 
implications.

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

If, while doing step #2, you find any issues, then you should recommend 
how to generate the IDs to mitigate the identified issues. Otherwise, 
you can use whatever algorithm you please, as long as it's clear why 
there are no implications.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 03:58:06 -0300

> is not generated in the same way as other connection IDs.

I find it curious that in a group that does protocol specifications, 
valid questions are "answered" with "we have a lot of reasons for that" 
-- of which you don't provide any concrete one. (and if there were, they 
should be in the protocol specification).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 04:07:14 -0300

> unnecessary discussions, just like the one we are having here.

In the same line of reasoning, you might as well propose that RFC3552 
("Guidelines for Writing RFC Text on Security Considerations") be 
obsoleted, because it also takes time to write "Security Considerations".

And I guess one could also ask for document reviews (including IESG 
reviews) to be eliminated, since at times they can "cause unnecessary 
discussions".

Otherwise, I wonder what's harmful about this:

i.e., specify the interoperability requirements of your identifiers.

i.e., do the associate security and privacy assessment.

i.e., suggest an algorithm that can generate your IDs while mitigating 
the possible issues (if any) that you found in step #2 above.

Is the above text what all this controversy is about?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 04:28:18 -0300

Hello, Martin,

On 17/12/20 03:07, Martin Thomson wrote:
> Everything else Christian says here about QUIC is accurate.  I see
> nothing there that suggests a problem in need of attention.  I would
> also point to
> https://tools.ietf.org/html/draft-ietf-quic-load-balancers for a more
> nuanced treatment of the connection ID selection problem.

So, in previous exchanges, it was claimed that "there were no 
implications arising from CIDs".
But the very Abstract of the document you're referencing says:

    QUIC connection IDs allow continuation of connections across address/
    port 4-tuple changes, and can store routing information for stateless
    or low-state load balancers.  They also can prevent linkability of
    connections across deliberate address migration through the use of
    protected communications between client and server.

That reads like privacy implications in my book. And should be part of 
the core spec.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 04:35:42 -0300

On 17/12/20 03:07, Martin Thomson wrote:
>> An informational document documenting a series of past attacks
>> would be interesting and educational. The kind of rule making
>> proposed in the draft, on the other hand, would be mostly harmful.
> 
> ...but this is the most important message.  Removing Section 5 and
> all that depends on it would make this a better document.

Huh? The whole point of this document is to provide advice, and such
advice is in Section 5.

> Separately, I found the list of potential problems in Section 4 to be
> approximately OK, though it lacked any mention of a need to
> synchronize changes across protocol layers.  I acknowledge that that
> is about use rather than generation, but that is quite relevant here
> too.

That's a good point. We considered that to be implicit here:

    o  Employing the same identifier across contexts in which constancy
       is not required

One trivial example would be the randomization of MAC addresses without 
a change in the MAC address triggering generation of a new IPv6 address.

That's what you seem to phrase as "synchronization of changes across 
layers".

In the bullet referenced aboce, the MAC address is one of the things 
that defines the context for an IPv6 address (along with the SLAAC 
prefix, Interface Index, and Network ID (such as SSID).

Do you think this warrants clarification?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 05:35:38 -0300

Forwarding to the list, since (probably) non-subscriber posts are moderated.

-------- Forwarded Message --------
Subject: 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
Date: Thu, 17 Dec 2020 01:15:13 -0700
From: Theo de Raadt <[email-masked]>
To: Fernando Gont <[email-masked]>
CC: Christian Huitema <[email-masked]>, Joe Touch 
<[email-masked]>, Eric Rescorla <[email-masked]>, 
[email-masked], [email-masked]

Fernando,

Thanks for bringing this discussion to my attention.

This conversation makes me sad and frightened of the future.

I have been involved in teams since 1989 who attempted to crush
attackable numeric identifiers in all layers of software.  It started
with RPC XIDs, DNS IDs, TCP IDs, PIDs, UDP/TCP port numbers, pid
numbers, NTP timestamps, it just went on and on.  Sadly hundreds of
line-items in standards by IETF, ANSI, and POSIX contain no guidance on
numeric identifier selection, and for decades developers chose the
simplest solutions which generally satisfied the primarly property
("temporal uniqueness"), but failed to consider other desireable
properties (leading to guessability, replay, etc).

Users on the Internet have encountered thousands of attackpoints which
could have been twarted (or been made more difficult) with a bit of
careful consideration.

One path towards solving that problem is introducing crypto layers,
which introduces it's own weight.

Full crypto is not the only path.

Eventually, observance of all the problems converged on the need for
strong random numbers in every Unix subsystem (kernel, libraries,
applications).  So our team eventually introduced strong random numbers
into OpenBSD, and inserted utilization of these numbres into every nook
and cranny.  (Random numbers also showed up in a few other operating
systems but they did not use them in every nook and crany).  We made
per-protocol decisions to retrofit random numbers into each problematic
identifier.  We engaged experts where needed, we performed multi-year
interop tests.  It took a decade to make safe IDs the default.  Then it
took another decade each change to be accepted as safe and correct, and
land in Linux and other systems.

So here we are today -- many legacy layers (such as TCP, DNS, NTP, etc)
use safer numeric identifiers in a majority of implementations, but
often the standards documents have not been updated to state so.

I believe this BCP is being written because it is largely impossible to
update guidance in older documents, and I suspect on a daily basis we'll
see new documents being written which ignore this guidance.

At this point I need to mention two of the authors of this draft were
been involved in two seperate OpenBSD efforts, 20+ years ago, for DNS
IDs, and later for TCP IDs related to RST and ICMP.  In each case,
OpenBSD acted as an incubator for their ideas.

BUT WHAT I'M READING IN THIS THREAD ATTEMPTS TO COUNTER NEARLY A
GENERATION OF DEVELOPED WISDOM.

How did a few of you becomes so full of yourselves?

You suggest NO GUIDANCE is needed.

You suggest the guidance is HARMFUL (to your drafts, and to the whole
ecosustem).

In the last 20 years we learned a catagory of simple rules which could
have prevented SIGNIFICANT HARM, but it is written nowhere.

The BCP says a protocol identifiers must be checked for safety, but if
they are safe, the job is done.  The BCP provides a checklist against
past problems and details a set of choices good.  This is such a simple 
task,
where is the outrage coming from?

Those rules should be in an IETF document, to ensure that protocol 
developers
are aware of the guidance.

This process of trying to block the dissemination of guidance to future
protocol developers shocks me.

It makes the IETF teamwork look like a circus.

I believe some of you have an invisible agenda, and your claims for why
this draft is problematic is fake.

I recommend you stop behaving like children.

Please start acting like adults that want a better world, a safer world,
a world where every simple safety measure is considered.

I'd like to close with my theory about what underlies the bogus
criticism that is being provided:

I believe there are people amongst us who recognize that most
recommendations in this BCP collapse to requiring strong random number
generation in all relevant compute environments, and the crypto wars
have begun again and pervasive random numbers are a thread to such people.

As someone who went through the last crypto war, I really hope this BCP
goes through because it will make random numbers generators pervasive.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Dec 2020 20:17:15 +1100

>     o  Employing the same identifier across contexts in which constancy

Unnecessary linkability is one thing, but "not required" is not the thing I refer to, but "constancy where unlinkability is desirable".

> a change in the MAC address triggering generation of a new IPv6 address.

Right.

> Do you think this warrants clarification?

Definitely.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 06:42:57 -0300

> Unnecessary linkability is one thing, but "not required" is not the thing I refer to, but "constancy where unlinkability is desirable".

FWIW, our argument is essentially that if constancy is not required in a 
given context, then you should generally avoid it. i.e., 
"unlinkability", where possible, should be the default.

>> Do you think this warrants clarification?

Please let me craft some text and come back to you to check whether you 
think it addresses this issue.

Thanks!

Regards,

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Dec 2020 21:06:46 +1100

> "unlinkability", where possible, should be the default.

I'm not sure that this is sufficient if it means uncoordinated changes, or that that works in every context. This says nothing about cross-layer coordination or managing trade-offs at different layers.

This is another reason to avoid making such strong recommendations.  I sympathize with the sentiment, but as a general statement I can't support this recommendation.  Capturing this as a goal and explaining the consequences of not achieving it should suffice.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 07:29:03 -0300

On 17/12/20 07:06, Martin Thomson wrote:
>> FWIW, our argument is essentially that if constancy is not required
>> in a given context, then you should generally avoid it. i.e., 
> I'm not sure that this is sufficient if it means uncoordinated
> changes, or that that works in every context. This says nothing about
> cross-layer coordination or managing trade-offs at different layers.

Note:
The text you were quoting essentially just summarizes the most root 
causes of of flawed generation of transient numeric IDs.

And yes, there are cases where problems arise because constancy wasn't 
required for some context, but the algorithm resulted in such constancy.

It follows that, "avoid linkability, where possible" would avoid such 
issues -- however, this *is not* a recommendation in this document.

> This is another reason to avoid making such strong recommendations.

These are the only recommendations in this document:

Which of these would you deem as "too strong" or disagree with?

Thanks,

---

From: Iván Arce (Quarkslab) <[email-masked]>
Date: Thu, 17 Dec 2020 10:02:35 -0300

Hello

On 12/17/20 2:19 AM, Christian Huitema wrote:
> specification, 

and so will every other reader of the 180+ page QUIC specification.
The document should stand on its own and be sufficiently clear on how to
implement the protocol without shooting oneself in the foot.

You call that "overspecification" ?

Implementers should not be privvy to the tons of discussions that went
into the process to write the final document.

I will refrain from commenting on the different confusing paragraphs
about connection IDs in the QUIC document because we are not reviewing
that document here. I guess there is a separate thread for that somewhere.

> taking into account the needs of a variety of
> is not generated in the same way as other connection IDs.>
> publish this draft. 
> It is using an abstract generalization of
> protocol development practice. 

You are reiterating the same arguments.

First by insinuating that an "abstract generalization" is a bad thing,
it is not. We generalize from empirical data, we abstract into a
classification issues that have reocurred over 30+ years in different
protocols and provide guidance to help current and future authors not
incur in the same issues.

Second, by singling out the QUIC document and generalizing from it as if
that was how every other protocol is currently developed. I don't see
any evidence to support such implicit claim.

We can continue talking past each other for weeks. One saying that
arbitrary generalizations are bad and pointing at QUIC as a example of
how things are done right now, the other arguing that abstracting and
generalizing from known similar problems not only is not bad but it is
actually useful and repeating that generalizing from a single data point
(QUIC) is a bad form of "abstract generalization".

We will continue to talk past each other and get nowhere because
evidently the intent of that line of debate is not to improve our draft
to make it more effective but to prevent its publication.

Everyone is entitled to an opinion and yours is that the draft should
not be published but the arguments provided to support that opinion are
simply not sound. There is no need to reiterate them, they are clear.

> Endorsing these recommendation in a BCP

It will not cause any unnecessary discussion if protocol designers look
at the transient IDs they are putting in their protocol, reflect on
their impact on security & privacy and refine their design accordingly.
If there is a discussion about why a given ID should or should not
follow our guidance it would not be an unnecessary discussion.

> making proposed in the draft, on the other hand, would be mostly harmful.

I am of the opinion that the most harmful would be to document a number
of reocurring design failures of the past and then do nothing to prevent
repeating those failures in the future.

/ivan

-- 
Iván Arce
CTO - Security Analysis
Quarkslab

---

From: Joseph Touch <[email-masked]>
Date: Thu, 17 Dec 2020 15:35:22 -0800

> On Dec 14, 2020, at 9:12 PM, Fernando Gont <[email-masked]> wrote:
> 

Christian has expressed much of my position, with the exception of the following:

IMO - protocols MUST NOT limit how IDs are selected or used. The issue isn’t the protocol spec; it’s the implementation.

I.e., an *implementation* MAY do so. These recommendations MAY be useful, to that end.

What I want to avoid is breaking the potential for IoT devices to use these protocols simply because they can’t implement the approaches described here.

I also want to avoid a receiver saying “hey, sender, you picked the IDs badly, so I won’t connect to you”.

That’s where I worry this is headed, and want to avoid.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Dec 2020 18:39:04 -0500

> What I want to avoid is breaking the potential for IoT devices to use these protocols simply because they can’t implement the approaches described here.

Hardware RNGs are pretty common in embedded devices nowadays. I don’t think this is actually a practical problem, although I am curious to know if you know of new hardware for which it would be a problem. I will admit that ancient hardware might have trouble, but it probably won’t be updated, given the state of the art at present, so I don’t think such a device poses a serious problem.

---

From: Joseph Touch <[email-masked]>
Date: Thu, 17 Dec 2020 15:47:38 -0800

> On Dec 17, 2020, at 3:39 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Dec 17, 2020, at 6:35 PM, Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
> Hardware RNGs are pretty common in embedded devices nowadays.

In Raspberry Pi, yes. PICs and Arduinos, no. Other IoTs, YMMV.

> I don’t think this is actually a practical problem, although I am curious to know if you know of new hardware for which it would be a problem. I will admit that ancient hardware might have trouble, but it probably won’t be updated, given the state of the art at present, so I don’t think such a device poses a serious problem.

What you add as a requirement ends up excluding as a platform. That’s the antithesis of Internet design.

The point is that these are tradeoffs of *implementation*, and should not be described as protocol deficiencies.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Dec 2020 19:20:37 -0500

> The point is that these are tradeoffs of *implementation*, and should not be described as protocol deficiencies.

It sounds like what you’re saying is that it’s a SHOULD, not a MUST?

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Dec 2020 16:51:37 -0800

> On Dec 17, 2020, at 4:21 PM, Ted Lemon <[email-masked]> wrote:
> 

At the *protocol* level, it’s nothing. Only as an implementation suggestion. 

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 22:58:08 -0300

Joe,

On 17/12/20 20:35, Joseph Touch wrote:
> 
> 
>> On Dec 14, 2020, at 9:12 PM, Fernando Gont <[email-masked] 

I don't know what's his "position". Reality is that we have been 
receiving objections against our document for things that are not even 
in our document.

I've explained that the requirements are in Section 5. Reqs #1-#2 simply 
spells out that every specs should nevertheless do. Req #3, says "if 
you've found issues, just suggest an algorithm that deals with it in the 
best possible way. Perios.

> IMO - protocols MUST NOT limit how IDs are selected or used. The issue 
> isn’t the protocol spec; it’s the implementation.

Current protocol specs not only do not spell out the interoperability 
requirements, but also over-specify the generation of their IDs.

Transient numeric IDs have interoperability constraints that you must 
comply with. When implementations enforce further requirements without 
an interoperability rationale *THAT* is a protocol limiting the IDs.

What we mean is:

#1: Spell out the interop req. i.e., tell us the properties that the IDs 
must have. -- we want to know the minium requirements the IDs need to 
comply to.

#2: Analyze the possible implications of such IDs.

#3: If you found any possible issues in #2, just suggest something to 
the implementer that complies with #1 and deals gracefully with #2.

We devote to protocol specs and have produced flawed specifications in 
this respect for a long time. Why should we expect every single 
implementer to do this analysis on their own to come up with a sensible 
algorithm?

> What I want to avoid is breaking the potential for IoT devices to use 
> these protocols simply because they can’t implement the approaches 
> described here.

Fair enough. Now when picking an algorithm, you'll probably have, say, 
the best option which might be more expensive and mitigate most/all 
issues, and, say, a lightweight version that e.g. mitigates some/most 
issues.

Explain the trade-offs of which, and suggest implementers when to use 
which ("this one is most sensible for constrained devices, and this one 
is sensible for the general case"). Done.

> badly, so I won’t connect to you”.

That's of course sensible. And that's why we have #1.

THe only way in which you can avoid this is when the interoperability 
requirements are clear. Now when talking about some of QUIC's IDs, and 
asking for why things are done, Christian response was, essentially, 
"oh, that's in the mail archive of the tons of discussions we have had".

That approach of coming up with requirements is doom to led to both 
interoperability problem (because you don't know what to comply with for 
things to work), and security/privacy issues (because there's no 
analysis of the implications of such IDs).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 23:00:08 -0300

On 17/12/20 20:39, Ted Lemon wrote:
> Hardware RNGs are pretty common in embedded devices nowadays. I don’t 
> think this is actually a practical problem, although I am curious to 
> know if you know of new hardware for which it would be a problem. I will 
> admit that ancient hardware might have trouble, but it probably won’t be 
> updated, given the state of the art at present, so I don’t think such a 
> device poses a serious problem.

Yeah, I would also be quite surprised for endpoints to be able to do 
encryption/authentication, but not be able to compute PRNG or a simple 
hash function. (since QUIC was raised as a document for which, somehow, 
our documents turns out to be problematic)

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 23:04:47 -0300

On 17/12/20 20:47, Joseph Touch wrote:
[...]
> 
>> I don’t think this is actually a practical problem, although I am 
>> curious to know if you know of new hardware for which it would be a 
>> problem. I will admit that ancient hardware might have trouble, but it 
>> probably won’t be updated, given the state of the art at present, so I 
>> don’t think such a device poses a serious problem.
> 

Our document requires the spec to spell out the interop requirements for 
the IDs, analysis their sec/privacy implications, and suggest an 
algorithm (or more than one, if you wish) to generate them.

> The point is that these are tradeoffs of *implementation*, and should 
> not be described as protocol deficiencies.

The tradeoffs should be in your suggestions.

We devote to specs and have got the specification of transient numeric 
IDs for ages. I don't think anyone could realistically pretend 
implementaers to go and do an assessmet for each algorithm for each ID 
employed by a protocol. -- the exception probably being OpenBSD.

Seriously. Anybody that has ever been involved in the stack of any open 
source project knows that.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 23:10:17 -0300

> What you add as a requirement ends up excluding as a platform.

Recommend != require.  e.g. SHOULD vs MUST.

We recommend that you do this, but we understand there might be reasons 
(e.g., implementations constrains) for which you might need to do 
something else.

That provides a safe default. Folks that think know better, are on their 
own.

Nowadays, both folks that know better, and those that do not, are on 
their own.

Thanks,

---

From: Joseph Touch <[email-masked]>
Date: Thu, 17 Dec 2020 18:35:54 -0800

> On Dec 17, 2020, at 5:58 PM, Fernando Gont <[email-masked]> wrote:
> 
> What we mean is:
> 
> #1: Spell out the interop req. i.e., tell us the properties that the IDs must have. -- we want to know the minium requirements the IDs need to comply to.
> 
> #3: If you found any possible issues in #2, just suggest something to the implementer that complies with #1 and deals gracefully with #2.

That would be the topic of a document on “Specifying the interoperability requirements of generated IDs in protocols”.

That is not the title of this document; the difference between the two is where we disagree.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2020 23:48:39 -0300

On 17/12/20 23:35, Joseph Touch wrote:
> 
> 
>> On Dec 17, 2020, at 5:58 PM, Fernando Gont <[email-masked] 
>> #1: Spell out the interop req. i.e., tell us the properties that the 
>> IDs must have. -- we want to know the minium requirements the IDs need 
>> to comply to.
>>
> That would be the topic of a document on “Specifying the 
> interoperability requirements of generated IDs in protocols”.
> 

Clearly not.

There's no single advice in this document on how to specifiy 
interoperability requirements for numeric IDs.

The goal is to do a security analysis. Folks writing a spec are expected 
to know how to do #1. We ask that #1 is spelled out clearly, because 
that a "must have" to do #2, and also to review such analysis. And when 
you do #2, you may have to do #3 if issues are found.

   -- the kind of stuff you do in security considerations nowadays.

---

From: Joseph Touch <[email-masked]>
Date: Thu, 17 Dec 2020 19:00:48 -0800

> On Dec 17, 2020, at 6:48 PM, Fernando Gont <[email-masked]> wrote:
> 
>>> On Dec 17, 2020, at 5:58 PM, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> What we mean is:
>>> 
> There's no single advice in this document on how to specifiy interoperability requirements for numeric IDs.
> 
> The goal is to do a security analysis.

That isn’t #1.

It’s a giant leap to assert that as the point of #2 - basically because “possible” doesn’t mean likely.

And “graceful” does not describe what this document recommends. 

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Dec 2020 00:02:15 -0300

Joe,

I think we have gone through this before. Folks (including you) raise 
objections. I note that the claim has no basis or ask a question which 
clearly shows the objection has no basis, and they omit the question, 
stop responding, or switch to something else.

First it was the algorithms this document was requiring -- but it 
doesn't require any.

Now the problem is the title.

I have already started to write down the objections each folk has 
raised, the questions me, Ivan or the Security AD asked, and how they 
were not responded to.

At the end of the day it's up to the AD to judge if valid concerns have 
been raised, or whther folks are simply trying to thwart this effort.

For folks that want a longer explanation, please refer to Theo de 
Raadt's post: 
https://mailarchive.ietf.org/arch/msg/last-call/4h6S6Ymw9knoJFKGVQe0bM4JMwE/

Constructive comments -- of which I've seen virtually none -- are 
welcome, as always.

Thanks,
Fernando

---

From: Iván Arce (Quarkslab) <[email-masked]>
Date: Fri, 18 Dec 2020 00:45:15 -0300

Hello Joseph

> isn’t the protocol spec; it’s the implementation.

If the use of IDs creates a known security problem they should, yes.
If guidance is not heeded things like those described here will continue
to happen:

note CVE-2020-17439, another instance of good old off-path DNS cache
poisoning due to use of predictable DNS TXIDs

[PDF]
https://www.forescout.com/company/resources/amnesia33-how-tcp-ip-stacks-breed-critical-vulnerabilities-in-iot-ot-and-it-devices/

> these protocols simply because they can’t implement the approaches

I don't think this is really a concern given that IoT devices are
already implementing some of the proposed algorithms.

For example, RFC 6528 is a Proposed Standard and mandates (with SHOULD):

3.  Proposed Initial Sequence Number Generation Algorithm

   TCP SHOULD generate its Initial Sequence Numbers with the expression:

      ISN = M + F(localip, localport, remoteip, remoteport, secretkey)

   where M is the 4 microsecond timer, and F() is a pseudorandom
   function (PRF) of the connection-id.  F() MUST NOT be computable from
   the outside, or an attacker could still guess at sequence numbers
   from the ISN used for some other connection.  The PRF could be
   implemented as a cryptographic hash of the concatenation of the
   connection-id and some secret data; MD5 [RFC1321] would be a good
   choice for the hash function.

It is possible that some devices do not follow that advice but any
device with a working PRNG should be capable of doing it.

> badly, so I won’t connect to you”.

I don't think this is mandated anywhere.
In fact our draft does not even mandate that consideration is given to
the security & privacy factors of IDs, documented and an algorithm
recommended. But protocol authors may very well say:
"for the ID field <x> use a global counter initialized in 0 and
incremented by 1 in each packet or any other algorithm, we are aware of
the security & privacy consenquences, this is a conscious decision, see
Security Considerations for further discussion of our attacker  model"

> That’s where I worry this is headed, and want to avoid.
I understand the concern but I do not see how our draft could lead to that.

regards,
/ivan

-- 
Iván Arce
CTO - Security Analysis
Quarkslab

---

From: Christian Huitema <[email-masked]>
Date: Thu, 17 Dec 2020 19:56:55 -0800

> stop responding, or switch to something else.

Or they consider that they have made their point, and don't want to read 
through lengthy repetitions of the same counter-argument. Silence does 
not mean assent.

To be clear, the point is not that security risks should be ignored. 
Nobody is saying that. The point is that the proper way to conduct risk 
analysis is by looking at attack areas such as information disclosure, 
risks of spoofing, etc. These analyses will vary depending on 
circumstances, and the responses are not always the same. They are 
definitely not the same for information inside and outside the 
encryption envelope. They are also not the same for all parameters in a 
system. To give an example, consider the stream offset indicating the 
position of the message bytes in a file. Randomizing that would be 
ridiculous.

Analysis of weaknesses is good. Prescription of one-size-fit-all 
remedies, on the other hand, does more harm than good.

-- Christian Huitema

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Dec 2020 20:02:30 -0800

> On Dec 17, 2020, at 7:03 PM, Fernando Gont <[email-masked]> wrote:
> 
> I think we have gone through this before. Folks (including you) raise objections. I note that the claim has no basis or ask a question which clearly shows the objection has no basis, and they omit the question, stop responding, or switch to something else.

We do, because our input has need ignored (again) and we have better things to do. 

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Dec 2020 01:11:59 -0300

On 18/12/20 00:56, Christian Huitema wrote:
[...]> To be clear, the point is not that security risks should be ignored.
> remedies, on the other hand, does more harm than good.

I will ask this again. Where's the one-size-fits all here:

?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Iván Arce (Quarkslab) <[email-masked]>
Date: Fri, 18 Dec 2020 01:18:32 -0300

Hello

On 12/17/20 9:51 PM, Joe Touch wrote:
>> On Dec 17, 2020, at 6:47 PM, Joseph Touch <[email-masked]
>> <mailto:[email-masked]>> wrote:

As noted before, RFC 6528, a proposed standard, already mandates with
SHOULD and algorithm to generate TCP ISNs
(https://tools.ietf.org/html/rfc6528#page-4)

Also, RFC 3550 "Real Time Protocol" (RTP), an Internet Standard, has
very specific guidance for how to generate certain identifiers:
(https://tools.ietf.org/html/rfc3550#page-59)

 It is also not sufficient to obtain an SSRC identifier simply by
   calling random() without carefully initializing the state.  An
   example of how to generate a random identifier is presented in
   Appendix A.6.

In sum, there are already many protocol specifications where very
specific algorithms are mandated or suggested with little or no analysis
of security and privacy impact, sometimes those algorithms even
introduce weaknesses.

Our draft does not mandate any algorithm, it mandates that protocol
authors do an analysis of impact of the transient identifiers they put
in their protocols, document that analysis, and recommend appropriate
algorithms. It does not say that any said algorithm must be a MUST.

Perhaps we could add text saying that protocol authors should not forbid
that implemeters not comply with the recommended algorithms.

That would address your concern and  clarify that the analysis and a
recommendation is required but specific algorithm recommendations cannot
be a MUST.

/ivan

-- 
Iván Arce
CTO - Security Analysis
Quarkslab

---

From: Iván Arce (Quarkslab) <[email-masked]>
Date: Fri, 18 Dec 2020 02:04:29 -0300

> We do, because our input has need ignored (again) and we have better things to do. 

You have provided no constructive criticism, have not proposed any text
to deal with your objections or concerns, or to improve the draft in any
other way and have simply argued that the draft shouldnt be published
period.

The total sum of your input is "do not publish this".

We have not ignored it, we have engaged in a discussion replying to
every objection to publication with arguments and examples, we have
suggested text to address your concerns about IoT devices that cant
possibly have an RNG, and other's concerns as well but none of those
efforts seem sufficient or acceptable.

The ignoring seem to be somewhere else.

I've spent every email on this thread trying to explain why the draft
should published instead of discussing how to make it better.

I have better things to do as well.

/ivan

-- 
Iván Arce
CTO - Security Analysis
Quarkslab

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Dec 2020 02:22:52 -0300

>     example of how to generate a random identifier is presented in

And RFC2460 suggested to generate the IPv6 Frad ID with a global 
counter, and this is rfc793 for the ISN:

   To avoid confusion we must prevent segments from one incarnation of a
   connection from being used while the same sequence numbers may still
   be present in the network from an earlier incarnation.  We want to
   assure this, even if a TCP crashes and loses all knowledge of the
   sequence numbers it has been using.  When new connections are created,
   an initial sequence number (ISN) generator is employed which selects a
   new 32 bit ISN.  The generator is bound to a (possibly fictitious) 32
   bit clock whose low order bit is incremented roughly every 4
   microseconds.  Thus, the ISN cycles approximately every 4.55 hours.
   Since we assume that segments will stay in the network no more than
   the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
   hours we can reasonably assume that ISN's will be unique.

etc., etc., etc.

Joe knows this, of course.

But I guess the goal here is not to do collaborative work and improve 
the document, but to thwart its publication.

[..]
> that implemeters not comply with the recommended algorithms.

It's simple: it's up to the implementation whether they want to have the 
algorithm be a "MUST", "SHOULD", or anything else. Or simply suggest one 
possible way to generate the numeric ID, even without RFC2119 language 
"The following figure illustrates one possible algorihtm...."

Thanks,

---

From: "Theo de Raadt" <[email-masked]>
Date: Thu, 17 Dec 2020 01:15:13 -0700

Fernando,

The BCP says a protocol identifiers must be checked for safety, but if
they are safe, the job is done.  The BCP provides a checklist against
past problems and details a set of choices good.  This is such a simple task,
where is the outrage coming from?

Those rules should be in an IETF document, to ensure that protocol developers
are aware of the guidance.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Dec 2020 11:30:27 -0800

Hi Ekr,

> to be minutes posted, for which I share some of the blame.

I just re-watched that section of the session. I'm not sure anything
was missed. What I heard was actually a fairly confusing discussion
with weak enthusiasm and certainly nothing like consensus that there
should be a BCP.

In addition, I would make two points.

1. The resolution was that that the ADs would work with the authors
   to find a home for this.

2. The discussion was predicated on a presentation, not on review of
   the contents of the document. That is the part we are doing now.

3. The one really strong voice for something here was Watson Ladd
   who asked for a document that would tell him what to do, which
   this is not.

So to the extent to which you're arguing that there is some presumption
that this document should be published as if it had come out of
a WG, I disagree.

> the relevant discussion in this draft to account for that class of

This document contains two pieces:

1. A set of "common flaws" in generating ID (S 4)
2. A set of requirements about what kind of analysis one has to do (S 5).

>From my perspective, S 5 is mostly reasonable, though I don't really
think a special BCP is needed for them. However, for the reasons
above, I think S. 4 is out of step with what's needed for many modern
protocols. In particular, one might well come away from reading that
with the impression that what QUIC and DTLS are doing here is bad, but
I don't think that's really the right conclusion to draw. So, having
that material published as an RFC seems harmful. I think that what's
needed here would be a rework, not just a sentence or two.

> (numerical) identifiers do not qualify as "Common Issues" in that sense?

I think they probably do qualify as common issues, but presenting them
in the way they are presented here is miseleading.

> consideration.

I don't think that's what I said. Rather, my position is that:

(1) We shouldn't move forward with the contents of this document for
    the reasons above.
(2) Piecemeal updating of this kind is bad and therefore if people
    do want to update 3552, we should actually do that and that
    model-T might or might not be a place to start.

-Ekr

---

From: Fernando Gont <[email-masked]>
Date: Mon, 28 Dec 2020 19:49:20 -0300

Hi, Eric,

On 28/12/20 16:30, Eric Rescorla wrote:
>    > > somewhat more positive on Informational if there weren't also a 
> number

I have a different reading of the discussion. But I will wait for Ben to 
speak about this one.

>     the contents of the document. That is the part we are doing now.

FWIW, versions of this document were discussed since the times when 
Stephen and Kathleen were the Security ADs. Since that time it was 
always argued that the path for this particular piece was an 
AD-sponsored document.

[....]>
>  From my perspective, S 5 is mostly reasonable, 

FWIW, Sections 1-4 are, for the most part, introductory. The meat of 
this document is in Section 5.

> though I don't really think a special BCP is needed for them.

We have a very long tradition of flawed transient numeric IDs, as 
documented in 
https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history . So 
I'm curious how/why you argue that a BCP is not needed on the topic.

> However, for the reasons
> I don't think that's really the right conclusion to draw. 

I don't follow.

This document argues that:

1) Interoperability requirements are clearly spelled out

2) Possible security/issues arising from the employed IDs are properly 
analyzed.

3) Appropriate algorithms are suggested for the generation of the IDs in #1.

I'd assume that QUIC and DTLS do #1 already -- otherwise, that'd be a 
flaw in the corresponding specs.  Also that #2 is done -- possibly as 
part of the Security Considerations section. The result of this is might 
be that there are no issues associated with the employed IDs.  Depending 
on #1 and #2 the specs could suggest an algorithm to generate the IDs.

So I'm not sure what would be the rationale for arguing that what QUIC 
or DTLS do is bad.

If you think that adding some wording suggesting that the use of e.g. 
cryptographic authentication may be of use to mitigate some of the 
common issues associated with flawed IDs, that's totally fine to us. -- 
such use can certainly mitigate the possibility of data injection based 
on predictable IDs (such as sequence numbers).

> in the way they are presented here is miseleading.

Not sure what's the way in which they are "being presented".

#1: spell out the interoperability requirements of the IDs the spec employs

This seems a very important (yet often overlooked) thing to do in a 
spec. -- the reader of the spec shouldn't have to do guesswork about the 
requirements of the involved IDs. ANy proper spec should have this.

#2 Analyze any security/privacy issues arising from the IDs.

This seems  a very sensible request in the context of rfc3552 and 
RFC6973 (think data minimization in particular)

#3 Suggest algorithms that mitigate any issues found while doing #2 (#3 
is an obvious outcome from #2)

If you did find issues when doing #2, suggest a way to mitigate them --- 
or should every single implementer do #1-#3 on their own?

So I'm curious where's the controversy. Based on 
https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history , we're 
kind of asking the obvious.

Thanks,

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Dec 2020 14:18:44 -0500 (EST)

>    who asked for a document that would tell him what to do, which

I agree here. The document does not tell us what to do. There is just
some handwaving about hash functions.

It does not state anything about how to determine the required size of the
Transient Numeric Identifier to make it safe from attack. It does not talk
about the BCP for seeding of any kind of hash or prf function. Or about
using Transient Numeric Identifiers so that you can verify it without
needing to keep state (eg cookies)

> 1. A set of "common flaws" in generating ID (S 4)

And this is really already and better done in I-D.irtf-pearg-numeric-ids-history.
It should just point to it without elaborating again in this document.

> think a special BCP is needed for them.

I agree. It is obvious to those who care and a really low bar that we
should be already meeting at the IETF in general at this point. For
example "2. Provide a security and privacy analysis of the aforementioned
identifiers." is already required for the Security Considerations and
checkd with SecDir reviews. The privacy parts are done somewhat less but
are not omitted either.

Section 5 bullet 3 points to another document. It is almost as if bullet
point 1 and 2 could be part of the introduction there.

Once you do these two things, this draft is basically scaffolding
without content.

Paul

---

From: Fernando Gont <[email-masked]>
Date: Tue, 29 Dec 2020 17:00:22 -0300

> some handwaving about hash functions.

Are you reading the document from the Subject line, or a different one?

Because there's no discussion whatsoever about "hash functions" in 
draft-gont-numeric-ids-sec-considerations.

The requirements are very specific. Namely:

And we point to [I-D.irtf-pearg-numeric-ids-generation], where you can 
find sample analysis for different categories of identifiers. An 
analysis of common issues associated with I-Ds, and algorithms that 
mitigate them.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 29 Dec 2020 17:25:19 -0300

Hello, Paul,

> checkd with SecDir reviews. The privacy parts are done somewhat less but

So I certainly agree that this is "a really low bar that we  should be 
already meeting at the IETF in general at this point", and probably also 
that "It is obvious to those who care".

But then, may I ask:

1) How you explain the timelines in 
https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history-04 ?

2) How do you explain that a preliminar inspection of the core QUIC spec 
also fails in this regard? (e.g., connection-IDs)

3) What the "controversy" is all about?

Is it that nobody cares? Is it that the topic is not that obvious? 
Anything else?

> Once you do these two things, this draft is basically scaffolding

Please do read the document.

Point #1 (from Section 5 of the I-D) is not "part of the Intro". Point 
#1 is an actual *requirement*. Because it is this point that allows 
reviewers to tell what's needed from the I-D. Without #1, you can't do #2.

And, indeed, many flaws have to do with protocol specs over-specifying 
their transient numeric IDs. And the reader/reviewer somehow needs to 
assume that there's a reason for which the spec specifies the IDs in the 
way it does, instead of quickly realizing that the spec is 
over-specifying its transient numeric IDs.

And item #3 *of course* points to another document! -- Because we don't 
require you to pick any of the algorithms in 
https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation  -- 
You are free to come up with your own. We simply document algorithms 
that have been employed to generate different types of transient numeric 
identifiers, because it might well be the case that you need something 
similar, and in that case, you don't need to rebuild the wheel. But you 
are free to do it if you wish.

If you did read the document, then I wonder if some version of the above 
prose would be of use bellow the numbered-list.... because clearly you 
have misinterpreted both the requirements and their rationale/motivation 
-- or we have not been clear enough in that regard.

It's puzzles me that you portray this document as doing lot of 
handwaving. Because what's in this document is essentially the process 
that I followed to improve e.g. IPv6 stable IIDs (RFC7217), TCP sequence 
numbers (RFC6528), transport protocol ephemeral ports (RFC6056), IPv6 
Frag IDs (RFC7739), and IPv6 temporary IIDs (rfc4941bis).

Thanks,

---

From: Paul Wouters <[email-masked]>
Date: Thu, 31 Dec 2020 12:42:47 -0500 (EST)

On Tue, 29 Dec 2020, Fernando Gont wrote:

> already meeting at the IETF in general at this point", and probably also that 
> "It is obvious to those who care".
>
> But then, may I ask:
>

It seems the tail of the last 15 years all refer to IPv6, so perhaps
that area needs to write up a specific document that allows implementors
to verify their implementation's use of numeric identifiers. That is,
explicitly list the fields and how to safely generate them.

> 2) How do you explain that a preliminar inspection of the core QUIC spec also 
> fails in this regard? (e.g., connection-IDs)

Do you think publishing this document will change how the QUIC working
group will act in the future? I am sceptical.

> 3) What the "controversy" is all about?

That I'm a little confused about too. I don't follow Theo de Raadt's
reasoning of the end of the world. Before I read the draft, I was
expecting people to object to certain avoiding of random fields because
those are abused for privacy reasons (eg user tracking) but I found
none of that in the actual draft documents.

> Is it that nobody cares? Is it that the topic is not that obvious? Anything 
> else?

I can only speak for myself. I found the document in question to
basically say the equivalent of "please be careful", and that is not
very useful to me as implementor. I cannot go and check my code after
reading the draft, and I dont really feel that writing new drafts would
be affected by having read this document. That is why I say that this
low bar is kind of already met. If we are not meeting this low bar,
adding a new draft document isn't going to change this either.

> Please do read the document.

I had :P I might have confused reading the mentioning of hash algorithms
between the three related documents. I had read all three.

> And, indeed, many flaws have to do with protocol specs over-specifying their 
> transient numeric IDs. And the reader/reviewer somehow needs to assume that 
> there's a reason for which the spec specifies the IDs in the way it does, 
> instead of quickly realizing that the spec is over-specifying its transient 
> numeric IDs.

I find the word over-specifying a bit strange. If it is specified in the
RFC, you have to do it to interop or to get the at-the-time deemed
required security. Implementors should not think "Is this over-specified?"
If there is an error in the spec, a new RFC should update the current
RFC and fix it. If everyone starts second guessing over-specification,
then we are doing more harm than good by ending up with non-compliant
and non-interoperating implementations.

> https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation

Sure. I am not saying it is wrong. I am just saying there isn't much
content in this draft compared to all the boilerplate. Which makes me
think this document's little content could be better split over the
other two documents.

> It's puzzles me that you portray this document as doing lot of handwaving. 
> Because what's in this document is essentially the process that I followed to 
> improve e.g. IPv6 stable IIDs (RFC7217), TCP sequence numbers (RFC6528), 
> transport protocol ephemeral ports (RFC6056), IPv6 Frag IDs (RFC7739), and 
> IPv6 temporary IIDs (rfc4941bis).

I guess we have a difference audience in mind. You seem to be targetting
IETF draft authors, while I'm thinking of implementors.

Paul