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 6:42 PM, David Mazieres <
[e-mail]> wrote:

> "Black, David" <[e-mail]> writes:
>
> > This is entirely editorial about word choice - "permit the
> > negotiation" sounds like a runtime requirement to me, whereas this
> > section is entirely design requirements.  Using "support" instead of
> > "permit the negotiation of" is among the ways to make this clearer,
> > IMHO.
>
> But what about my proposed wording, which says "permit the use of"
> instead of "permit the negotiation of"?
>
> * TEPs MUST NOT permit the use of encryption algorithms with a
>   security strength [@!SP800-57part1] of less than 120 bits.  The
>   intent of this requirement is to allow the use of algorithms such as
>   AES-128 [@?AES] that are designed for 128-bit security and still
>   widely considered secure even after losing a few bits of security to
>   highly theoretical attacks.
>
> >> Second, why make this more complicated with the SHOULD 128?  Can we
> >> just have a 120-bit requirement?
> >
> > I think this is a "show your work" situation.  I'd expect a 120-bit
> requirement by itself to induce a fair amount of "where did that number of
> bits come from?" head scratching, starting from the inability to find a 120
> bit security strength in SP 800-57.  Independent of wording and keyword
> choices, there appear to be two things going on:
> >       a) We want TEPs designed to at least 128 bits of strength.
> >       b) We're willing to accept a few bits less if necessary, but not
> many bits less.
> > I think both need to be stated for clarity, although I'm not attached to
> the precise words used, e.g., lower case "should" instead of "SHOULD" seems
> reasonable for the 128 bit design requirement.  One advantage of using a
> "SHOULD" for the 128 bits of strength is that it invokes RFC 2119's
> requirement that "the full implications must be understood and carefully
> weighed before choosing a different course."
>
> The proposed language explains the rationale.
>
> Also, I'm not sure I agree that 128 bits are better than slightly fewer.
> For example, tcpcrypt's MTI DH curve is curve25519.  If memory serves,
> aren't the private keys for that something like 123 bits, because you
> are supposed to fix the top bits as 01 and bottom as 000 or something?
> It still seems like a perfectly fine choice of algorithm.  All else
> equal, given implementation considerations, I think we might be more
> likely to see mainstream 127-bit keys than 129-bit keys, and I'd rather
> people choose algorithms with more scrutiny.  When you are dealing with
> such small bit length differences, the constant factors and amount of
> human scrutiny against a big break are more important.
>
> > --[2]-- Cross-TEP security considerations for "vanity crypto"
> >
> >> The security considerations paragraph is trying to make a different
> >> point from the one in section 5.1.  Section 5.1 says you MUST provide
> >> all this stuff as an input to your hash function.  Section 10 says that
> >> hash function MUST not be weird "vanity crypto."  In other words, it may
> >> be reasonable to use vanity crypto for key negotiation or session data
> >> encryption, because that only affects the security of one TEP.  However,
> >> the session ID hash function potentially affects *all* TEPs because if
> >> it's broken, it will permit negotiation rollback attacks to deprecated
> >> TEPs--even when both sides prefer a more secure TEP.
> >
> > I would write what is meant/wanted here as opposed to assuming that
> > the rationale behind the MUST will be clear to all future reviewers.
>
> Obviously that is not coming through to readers, but that was the intent
> of the language.  E.g.:
>
>         In particular, if session IDs do not depend on the TCP-ENO
>         transcript in a strong way, an attacker can undetectably tamper
>         with ENO options to force negotiation of a deprecated and
>         vulnerable TEP.
>
> What about:
>
> Because TCP-ENO enables multiple different TEPs to coexist, security
> could potentially be only as strong as the weakest available TEP.  In
> particular, if TEPs use a weak hash function to incorporate the TCP-ENO
> transcript into session IDs, then an attacker can undetectably tamper
> with ENO options to force negotiation of a deprecated and vulnerable
> TEP.  To avoid such problems, session IDs SHOULD be computed using
> mainstream, well-studied, conservative hash functions.  That way, even
> if other parts of a TEP rely on more esoteric cryptography that turns
> out to be vulnerable, it is still intractable for an attacker to induce
> identical session IDs at both ends after tampering with ENO contents in
> SYN segments.
>

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.

-Ekr



> > --[3]-- IANA registry policy for TEP registry
> >
> >> Final point:  I only have a tcpcrypt review from Barry Leiba.  Should I
> >> apply his suggestion of "IETF review" instead of "RFC Required"?  I
> >> originally wanted "Specification Required" because I thought the
> >> designated expert review it implied would be sufficient.  Mirja talked
> >> me up to "RFC Required," which I thought was more strict.  However, does
> >> the RFC Required not in fact demand any kind of expert review?  (Looking
> >> at RFC8126, it doesn't seem to.)  I would be perfectly happy with an
> >> IRTF or Independent Submission stream RFC so long as a designated expert
> >> agrees the document is not a waste of a code point.
> >
> > This is somewhat in tension with the previous topic - how much review is
> sufficient to ensure that a weak TEP doesn't impact the security of all
> others?  The degree of review increases from Specification Required to RFC
> Required to IETF Review - if the need to ban potentially flawed vanity
> crypto hashes in TEPs is serious, then IETF Review seems justified, even
> though it imposes process costs on getting new TEPs approved.  In all
> cases, IANA will have a designated expert to advise on the registration,
> "RFC Required" adds the IESG taking a look, and IETF Review adds a lot more
> attention from the IETF security community.   More eyes tend to find more
> things ...
>
> As long as "RFC required" involves a designated expert, that would be my
> preference.  It's also what I think we arrived at after a bunch of
> discussion with Mirja.  I don't think the choice of conservative hash
> function requires more than a designated expert review, because it's not
> controversial or hard to check.  So is the status quo okay on this
> point?
>
> David
>