"Black, David" <david.bl...@dell.com> writes:
> I found something useful, as it turns out that I’ve seen this before in
> dealing w/another draft …
> o TEPs MUST NOT permit the negotiation of any encryption algorithms
> with significantly less than 128-bit security.
> To begin with, “permit the negotiation” is somewhat off, as this is a
> design-time requirement for TEP security strength. Fortunately, NIST SP
> 800-57 part 1 covers the notion of “security strength” in significant detail,
> so citing that should provide clarity on that concept. That leaves the
> concern about how not to lose AES-128 if an attack is discovered that knocks
> a few bits off of its security strength. Here’s a suggestion with the full
> rationale:
> o TEP encryption SHOULD have a security strength [SP800-57part1] of at least
> 128 bits and MUST have a
> security strength of at least 120 bits. The intent of this requirement is
> to allow use of encryption
> algorithms designed for 128 bit security strength if attacks should be
> discovered that weaken their
> security strength by a few bits.
> I suggested 120 bits here as being halfway between 128 bits (clearly
> acceptable) and 112 bits (clearly unacceptable) – that could be some other
> number of bits, e.g., 124 bits.
Hi, David. Thanks for this general approach. However, I have a couple
of points. First, I'm not sure I understand your criticism about permit
the negotiation, as we would expect most TEPs to engage in some sort of
cipher suite negotiation. Second, why make this more complicated with
the SHOULD 128? Can we just have a 120-bit requirement? What about
the following?
o 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.
If you accept that, then I think the only remaining issues are this from
your other email:
> The complete Security Considerations paragraph that is the focus of this
> Discuss point is:
>
> Because TCP-ENO enables multiple different TEPs to coexist, security
> could potentially be only as strong as the weakest available TEP. 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. To avoid such
> problems, TEPs MUST compute session IDs using only well-studied and
> conservative hash functions. That way, even if other parts of a TEP
> are vulnerable, it is still intractable for an attacker to induce
> identical session IDs at both ends after tampering with ENO contents
> in SYN segments.
>
> That paragraph looks like a reasonable description of the security risk and
> countermeasure, except for the one sentence that Ekr pointed out. Here’s a
> suggested fix:
>
> OLD
>
> To avoid such
>
> problems, TEPs MUST compute session IDs using only well-studied and
> conservative hash functions.
>
> NEW
>
> To avoid such problems, TEPs are required to compute session IDs in a
> collision-resistant way based on the TCP-ENO transcript and other
> parameters, as specified in Section 6.
>
> This also reflects Mirja’s observation that IETF & IESG review will be the
> means of ensuring that this happens, so a “MUST” is not needed here beyond the
> “MUST” in Section 6. In support of that observation, please be sure to make
> Barry Leiba’s suggested IANA registry policy changes from RFC Required to IETF
> Review.
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 want to make clear clear that the session ID hash function choice
needs extra scrutiny to prevent this point from being lost on future
generations of IETF & IESG reviewers. I don't have to make it a MUST if
that seems really problematic. But I also don't just want to reiterate
the same point as section 5.1, which is I think what your proposed
language does.
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.
Thanks,
David
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
