Subject: [secdir] Review of draft-ietf-tcpinc-tcpeno-10

From: Watson Ladd <[email-masked]>
Date: Mon, 16 Oct 2017 15:03:15 -0700

Dear all,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is that the writing and most of the
structure is fine, but I am a bit confused by some of the security
properties and how they are stated. It is not clear to me why the
unpredictability of generated session IDs is required. It is also not
clear to me that the requirement that a TEP produce different keys for
different transcripts is strong enough: we need to ensure that every
TEP produces different keys (with high probability) (and session
identifiers) for different transcripts to prevent cross-protocol
attacks.

Sincerely,
Watson Ladd

---

From: David Mazieres <[email-masked]>
Date: Thu, 19 Oct 2017 02:34:43 -0700

Watson Ladd <[email-masked]> writes:

> unpredictability of generated session IDs is required.

Thanks for your review.

Unpredictability of session IDs is required because doing so is not
particularly burdensome and because it's a very strong property that
subsumes the security requirements of a broad range of cases where
things might otherwise go wrong.  For example, the TEP has to be 33
bytes, and we don't want the last 16 of them being zeros.  Moreover, if
people sign session IDs for authentication, we want to be absolutely
sure they don't mess up the domain separation.  As another example,
someone might use a session ID on one connection to try to authenticate
a session ID on another.  Do you buy this rationale?  And is it
important enough that you think we need to add a subsection to the
rationale section discussing it?

> It is also not clear to me that the requirement that a TEP produce
> different keys for different transcripts is strong enough: we need to
> ensure that every TEP produces different keys (with high probability)
> (and session identifiers) for different transcripts to prevent
> cross-protocol attacks.

Do you mind clarifying this comment?  I assume it's in relation the
following two paragraphs from sections 4.8 and 10 respectively?

   To defend against attacks on encryption negotiation itself, a TEP
   MUST with high probability fail to establish a working connection
   between two ENO-compliant hosts when SYN-form ENO options have been
   altered in transit.  (Of course, in the absence of endpoint
   authentication, two compliant hosts can each still be connected to a
   man-in-the-middle attacker.)  To detect SYN-form ENO option
   tampering, TEPs must reference a transcript of TCP-ENO's negotiation.

   ...

   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.

The goal here is indeed to thwart both cross-TEP attacks and TEP
downgrade attacks, but to do so without mandating a particular hash
function for all TEPS, because that would severely hamper crypto
agility.  The extra byte in session IDs should save us from cases where
somehow both SHA-512 and Keccac are secure, but someone found two inputs
x and y such that SHA-512(x)==SHA-3(y) causing reuse of Session IDs
across TEPs.  So I can't figure out the attack you are worried about...

Thanks,
David

---

From: Watson Ladd <[email-masked]>
Date: Thu, 19 Oct 2017 07:49:30 -0700

> rationale section discussing it?

More rational for the requirement would I think help.

> across TEPs.  So I can't figure out the attack you are worried about...

Ah, that does work. Thanks for responding to my review.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: David Mazieres <[email-masked]>
Date: Fri, 20 Oct 2017 02:24:32 -0700

There's a new TCP-ENO draft in the usual place:

        https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/

This draft addresses last call comments we received.  Other than some
typos, the main changes are to update the requirements language (section
1) to use RFC8174 and to add a new section 8.5.  Since 8.5 contains new
language, we'd appreciate other eyes on this paragraph (even just
comments saying "looks fine" would be helpful):

8.5.  Unpredictability of session IDs

   Section 5.1 specifies that all but the first (TEP identifier) byte of
   a session ID MUST be computationally indistinguishable from random
   bytes to a network eavesdropper.  This property is easy to ensure
   under standard assumptions about cryptographic hash functions.  Such
   unpredictability helps security in a broad range of cases.  For
   example, it makes it possible for applications to use a session ID
   from one connection to authenticate a session ID from another,
   thereby tying the two connections together.  If furthermore helps
   ensure that TEPs do not trivially subvert the 33-byte minimum length
   requirement for session IDs by padding shorter session IDs with
   zeros.

Thanks,
David