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

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Thu, 19 October 2017 09:34 UTC

Return-Path: <dm-list-tcpcrypt@scs.stanford.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA73134842; Thu, 19 Oct 2017 02:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPau11Z-WSfg; Thu, 19 Oct 2017 02:34:44 -0700 (PDT)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1ADE1347C5; Thu, 19 Oct 2017 02:34:44 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v9J9Yh3x092434; Thu, 19 Oct 2017 02:34:43 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v9J9YhbZ002854; Thu, 19 Oct 2017 02:34:43 -0700 (PDT)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: Watson Ladd <watsonbladd@gmail.com>, secdir@ietf.org, draft-ietf-tcpinc-tcpeno.all@ietf.org, iseg@ietf.org, tcpinc <tcpinc@ietf.org>
In-Reply-To: <CACsn0cnUbMha8ZyP5h3E7zJqo5PinppXRhWxqy2d1b6nF4XmwA@mail.gmail.com>
References: <CACsn0cnUbMha8ZyP5h3E7zJqo5PinppXRhWxqy2d1b6nF4XmwA@mail.gmail.com>
Reply-To: David Mazieres expires 2018-01-17 PST <mazieres-6zhpjtw5385e45j3qtg9s3i8b6@temporary-address.scs.stanford.edu>
Date: Thu, 19 Oct 2017 02:34:43 -0700
Message-ID: <87o9p3wkek.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/N32q_Qz0Aw0AKWKm-EshyWqZNd4>
Subject: Re: [secdir] Review of draft-ietf-tcpinc-tcpeno-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Oct 2017 09:34:46 -0000

Watson Ladd <watsonbladd@gmail.com> writes:

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

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