[LACNIC/Seguridad] Identificadores numericos predecibles (Fwd: Re: Last Call: <draft-gont-numeric-ids-sec-considerations-06.txt> (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice)

[Fernando Gont]

Estimados,

En ocasiones, cuando un mismo problema es recurrente en el tiempo, uno 
se pregunta "como diablos puede ser que el mismo problema siga 
ocurriendo una y otra vez para diferentes protocolos).

Junto a Ivan Arce, decidimos abordar uno de dichos problemas: el de uso 
de "identificadores numericos temporales predecibles". Publicamos tres 
documentos al respecto:

1) https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history

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

3) https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations


El primero estudia la historia de los IDs predecibles -- y quien sepa 
leer entre lineas, tal vez pueda sacar alguna conclusión extra :-)

El segundo hace un analisis tecnico de estos identificadores, analiza 
las implicancias de seguridad y privacidad, y propone algoritmos que 
permiten generar identificadores numericos sin dichos problemas.

Finalmente, el tercer documento, apunta a recomendar que todas las 
especificaciones hagan un analisis de seguridad y privacidad adecuado, 
apra poder evitar que estos problemas ocurran en el futuro.

El nivel de ridiculez de las objeciones recibidas no ha tenido limite.

Aqui envio una, en la cual el autor argumento que como esta a punto de 
publicarse la especificación de QUIC, y la misma *no* hace una analisis 
de seguridad adecuado de sus identificadores numericos, entonces nuestro 
documento #3 no deberia publicarse.

Dicho de otro modo: "estamos haciendo las cosas mal. Asi que no queremos 
que se publique un documento con recomendaciones, ya que nos dejaría en 
evidencia".

Abajo reenvio el mail en cuestión. Y quien esté interesado puede leer el 
thread cometo en: 
https://mailarchive.ietf.org/arch/browse/last-call/?gbt=1&q=draft-gont-numeric-ids-sec-considerations-06.txt

Slds,
Fernando




-------- Forwarded Message --------
Subject: 	Re: 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: 	Sun, 13 Dec 2020 14:06:39 -0800
From: 	Eric Rescorla <ekr en rtfm.com>
To: 	Iván Arce (Quarkslab) <iarce en quarkslab.com>
CC: 	Fernando Gont <fgont en si6networks.com>, last-call en ietf.org, 
draft-gont-numeric-ids-sec-considerations en ietf.org





On Sun, Dec 13, 2020 at 1:03 PM Iván Arce (Quarkslab) 
<iarce en quarkslab.com <mailto:iarce en quarkslab.com>> wrote:

     Hello Eric, Fernando

     On 12/13/20 5:38 AM, Fernando Gont wrote:
      > Hello, Eric,
      >
      > Thanks for your comments! In-line....
      >
      >
      > On 12/12/20 18:44, Eric Rescorla wrote:
     ..
      >>
      >> At a high level, many of the attacks listed here (especially in 
TCP)
      >> result from the reliance (potentially accidental) on unpredictable
      >> identifiers as a countermeasure against various forms of 
attack. For
      >> instance, TCP is subject to a variety of off-path injection attacks
      >> which are partly mitigated by randomizing sequence numbers and port
      >> numbers. However, the more modern practice is to cryptographically
      >> authenticate datagrams, thus preventing injection attacks even
     if the
      >> port and sequence number are predictable.
      >
      > I don't think the two are mutually-exclusive. Nobody is arguing that
      > randomizing numeric IDs is an alternative to cryptographic
     authentication.

     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.


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.



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

     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.


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.


      >>     Connection IDs MUST NOT contain any information that can be
     used by
      >>     an external observer (that is, one that does not cooperate
     with the
      >>     issuer) to correlate them with other connection IDs for the 
same
      >>     connection.  As a trivial example, this means the same
     connection ID
      >>     MUST NOT be issued more than once on the same connection.
      >
      > I believe that not recommending a good/safe choice for 
generating IDs
      > has been proved to be problematic.

     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.


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.


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

     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?


See above for a specific example.


     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?


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

-Ekr