> > 1) Encryption: Ekr and I need to talk about how to express “no weaker than
> > current strength of AES-128 (i.e., based on attacks known in 2017)”
>>
> Yep. Happy to do this at a mutually convenient time.
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.
Thanks, --David
From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Sunday, November 12, 2017 8:59 PM
To: Black, David <david.bl...@emc.com>
Cc: Kyle Rose <kr...@krose.org>; The IESG <i...@ietf.org>;
draft-ietf-tcpinc-tcp...@ietf.org; tcpinc-cha...@ietf.org; tcpinc@ietf.org
Subject: Re: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with
DISCUSS and COMMENT)
On Mon, Nov 13, 2017 at 9:53 AM, Black, David
<david.bl...@dell.com<mailto:david.bl...@dell.com>> wrote:
Keeping this all on one thread, I think the situation on the three Discus
points is:
1) Encryption: Ekr and I need to talk about how to express “no weaker than
current strength of AES-128 (i.e., based on attacks known in 2017)”
Yep. Happy to do this at a mutually convenient time.
2) The resolution for URG processing is clear – state that the list of two
techniques is not exhaustive, although the text would be improved by describing
the two techniques as examples of what could be done and not using the “MAY”
keyword.
LGTM.
3) On further reading, it looks like the one-way hash function concern is
caused by a little bit of weak text in the Security Considerations section, as
the body of the draft gets this topic right in Section 6:
o The session ID MUST depend in a collision-resistant way on all of
the following (meaning it is computationally infeasible to produce
collisions of the session ID derivation function unless all of the
following quantities are identical):
* Fresh data contributed by both sides of the connection,
* Any public keys, public Diffie-Hellman parameters, or other
public asymmetric cryptographic parameters that are employed by
the TEP and have corresponding private data that is known by
only one side of the connection, and
* The negotiation transcript specified in Section
4.8<https://tools.ietf.org/html/draft-ietf-tcpinc-tcpeno-13#section-4.8>.
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.
LGTM.
-Ekr
Thanks, --David
From: Eric Rescorla [mailto:e...@rtfm.com<mailto:e...@rtfm.com>]
Sent: Sunday, November 12, 2017 2:39 AM
To: Kyle Rose <kr...@krose.org<mailto:kr...@krose.org>>
Cc: Black, David <david.bl...@emc.com<mailto:david.bl...@emc.com>>; The IESG
<i...@ietf.org<mailto:i...@ietf.org>>;
draft-ietf-tcpinc-tcp...@ietf.org<mailto:draft-ietf-tcpinc-tcp...@ietf.org>;
tcpinc-cha...@ietf.org<mailto:tcpinc-cha...@ietf.org>;
tcpinc@ietf.org<mailto:tcpinc@ietf.org>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with
DISCUSS and COMMENT)
Sorry, "not an unreasonable desire"
On Sun, Nov 12, 2017 at 7:21 AM, Eric Rescorla
<e...@rtfm.com<mailto:e...@rtfm.com>> wrote:
On Sun, Nov 12, 2017 at 7:19 AM, Kyle Rose
<kr...@krose.org<mailto:kr...@krose.org>> wrote:
On Sun, Nov 12, 2017 at 1:13 PM, Eric Rescorla
<e...@rtfm.com<mailto:e...@rtfm.com>> wrote:
> On Sun, Nov 12, 2017 at 5:08 AM, Black, David
> <david.bl...@dell.com<mailto:david.bl...@dell.com>> wrote:
>> - Encryption: The intent is - don't use anything weaker than AES-128,
>> e.g., don't even think about using 3DES. The concern is how to write that
>> requirement in a way that would survive hypothetical discovery of a
>> catastrophic cryptanalytic attack on AES-128.
>
>
> Or even a small one. I mean, what does this say about Curve25519 or 4Q.
I think this is actually the issue driving the vagueness of the
requirement: e.g., if some hypothetical attack against AES-128 reduced
security by a few bits. The intent, as David suggests, is to prohibit
the use of something like DES, not to prohibit a 128-bit cipher with
only (say) 125 bits of security.
That's not a reasonable desire, but this is an RFC 2119 requirement, so it
really does need to be unambiguous.
-Ekr
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
