Re: [tcpinc] 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: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@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/tcpinc/qG4RC2p0TB1GII-V4RUkcQJytSc>
Subject: Re: [tcpinc] Review of draft-ietf-tcpinc-tcpeno-10
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-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
- Re: [tcpinc] Review of draft-ietf-tcpinc-tcpeno-10 David Mazieres
- Re: [tcpinc] Review of draft-ietf-tcpinc-tcpeno-10 Watson Ladd
- [tcpinc] New TCP-ENO draft David Mazieres