Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Mon, Nov 13, 2017 at 9:24 PM, David Mazieres <
[e-mail]> wrote:

> Eric Rescorla <[e-mail]> writes:
>
> > To be honest, I think this document is working too hard in both cases to
> > try to legislate that people don't do things that we think are bad. The
> > bottom
> > line is that in both cases the boundaries around what we think is OK and
> > what we think is not are kind of fuzzy (as you illustrate above with
> > Curve25519). Rather than try to write RFC 2919 language about this,
> > it would be better to simply describe the consequences of bad choices,
> > and say that the function must be collision resistant, and stop.
>
> I don't understand the RFC2919 reference.  Did you mean a different RFC,
> or is there some IETF lore about this being an overly-specified RFC?
>

Sorry RFC 2119.



> The thing is, there is definitely historical precedent for intentionally
> choosing weak crypto algorithms.


Yes, I really am aware of this.


  And while I hope the truly bad old
> days are behind us, I still think it's important that we abstract some
> base level of security out of TCP-ENO so that most applications don't
> need to whitelist TEP identifiers.
>

I think you're really overestimating the amount of influence IETF has here.
What we can do is stop IANA from registering code points, but nothing stops
people from just grabbing one for a noncompliant TEP. I'm fine with having
text in the RFC that says "this needs to be a strong function and that's
why",
but it's not like we can take people to court to make them stop doing that,
so having extremely precise and strong language here doesn't actually
help that much.

-Ekr