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.
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,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
