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

["Black, David" <[e-mail]>]

Trying to summarize …


--[1]-- TEP encryption security strength



> But what about my proposed wording, which says "permit the use of"
> instead of "permit the negotiation of"?


Ok, but “permit the ... of” is not needed – “TEPs MUST NOT use” is both direct and sufficient.



[…  snip …]



Beyond that, I concur with this point:



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


However, I still think that it’s a good idea to note that 128 bits is the preferred lower bound design target for security strength, although that can be done without a “SHOULD” keyword– e.g.:

TEPs MUST NOT use encryption algorithms with a security strength [@!SP800-57part1] of less than 120 bits.
TEP designs are encouraged to target a security strength of at least 128 bits to provide some headroom
above the 120 bit requirement to accommodate possible future attacks that remove a few  bits of security
strength without compromising the fundamental security of the encryption algorithm.

--[2]-- Cross-TEP security considerations for "vanity crypto"

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

Ekr, Tero and I all appear to think that an RFC 2119 keyword is not appropriate here.  Try:

OLD
To avoid such problems, session IDs SHOULD be computed using
mainstream, well-studied, conservative hash functions.
NEW
Towards avoiding such problems, security reviewers of new TEPs
are expected to pay particular attention to the security strength and
state of cryptanalysis (including research into possible attacks) of the
session ID hash function, above and beyond checking that the hash
function meets the requirements stated in Section 6.

This proposed text also makes it clear that the concern here is in addition to the Section 6 requirements on the hash function.

--[3]-- IANA registry policy for TEP registry

At least my suggestion of IETF Review was in part to see whether more strict review would be appropriate – that appears not to be the case, so …

I like Amanda’s suggestion of: “Expert Review with RFC Required”   That should result in two security reviews of a new TEP, both of which could halt a weak one.  Looking at the Independent Submission track as the “path of least resistance” that would be the IETF Security Area (ADs and Directorate) as part of RFC publication plus an IANA expert review as part of codepoint assignment.  Thank you, Amanda.

I have to admit that Ekr is right that anyone can do arbitrarily stupid things on their own – what we can stop is misuse of IETF’s good name and IANA registration in support of that sort of stupidity.

Thanks, --David

From: Eric Rescorla [mailto:[e-mail]]
Sent: Monday, November 13, 2017 3:40 PM
To: David Mazieres <[e-mail]>
Cc: Black, David <[e-mail]>; [e-mail]; Kyle Rose <[e-mail]>; [e-mail]; Mirja Kuehlewind (IETF) <[e-mail]>; The IESG <[e-mail]>; [e-mail]
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)



On Mon, Nov 13, 2017 at 6:42 PM, David Mazieres <[e-mail]<mailto:[e-mail]>> wrote:
"Black, David" <[e-mail]<mailto:[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