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

[Joseph Touch <touch@xxxxxxxxxxxxxx>]

On Dec 13, 2020, at 6:51 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:

On 13/12/20 19:47, Joe Touch wrote:

On Dec 13, 2020, at 1:54 PM, Eric Rescorla <ekr@xxxxxxxx> wrote:

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 protoco

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

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.

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


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

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

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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call