Re: [tcpinc] Review of draft-ietf-tcpinc-tcpeno-10
Watson Ladd <watsonbladd@gmail.com> Thu, 19 October 2017 14:49 UTC
Return-Path: <watsonbladd@gmail.com>
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 6F4BD12421A; Thu, 19 Oct 2017 07:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vLvo7_tabPh4; Thu, 19 Oct 2017 07:49:32 -0700 (PDT)
Received: from mail-ua0-x243.google.com (mail-ua0-x243.google.com [IPv6:2607:f8b0:400c:c08::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AEC124B17; Thu, 19 Oct 2017 07:49:32 -0700 (PDT)
Received: by mail-ua0-x243.google.com with SMTP id s41so6158720uab.10; Thu, 19 Oct 2017 07:49:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C/5sUN0ipDDLBsia1UaE6AqQo/f1hxK6gFrUF63VlrY=; b=IZjsgVQ9vtQYy44rvKSOblaJ3FKCejVoNg1hF3FxV84c/46LeSmDIRfq3XWlYv18ac aiddFnhyEY3cjYn9mGQb0g2J/ZGh/LgJ2MaGDEWU08q9ckQFfv1A5GsSUlDFg+F0/QWf wTPpD2E9eIOziZFXnuXbq82bVTQwy297sp7yAecEkO0/DI+SoOgAtUg46qJ2wMGFa13O JEG/e4LP8DHAHw8pGUUMxRHezR7+V4SOF7nXu5uqMMm/U+aFLppfhQyzjOjupkcoxx5z J6rviEo5wNjaKqgF6GizdXMw2p56Q/A6dESgt+JmCjpBVYPRcwE6o+XYmtHn4bi8rrmr lhig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C/5sUN0ipDDLBsia1UaE6AqQo/f1hxK6gFrUF63VlrY=; b=qjNqUI6Mi/RDMJUaIRumOqVCUpLwqvRuAbrK+jMS9GD+nr8C0erlnIGMkr4YA7SX/4 GaSWNAwKbrPsCdy8hUQw0raNe5JObo1lrkcvcDdBBVpl11pBJMrW/HjzwexDtbFiSEZK rwaNWdiq8SDH2QG0hJy53xBZOrcknwRND56sFOPwa0Soe6w62XLi8TxkVQJ+WlBtz8jq qlI9EaA/h994Tm8oLQOUZHQsQoZl42RUoz1tslqP0+m2+1ISM5hNvGP/3UlEwo2VPil3 T6k8fzfeRtcmgkeCyGZOYHO7OYNCznYwwqGuNcTeQV2Qgilr54gIjjrpRstIVQpakDxX /Sjg==
X-Gm-Message-State: AMCzsaX0KWi53VZU92+Vv2WEM1M1g/2aZmfKGVVVRDKkpaMjjy8khl+C rntNhdM08qVlc//GFIDi3tIIfG3NGt+JisytWH6QzA==
X-Google-Smtp-Source: ABhQp+SWtnUlgNyeqIn/o3PRgxUAvzIjYj/vp1xpEFaaEoN4VB6L4xli/5T58Chu+robHqt2tgvELsw8h7h7gt534EM=
X-Received: by 10.159.49.179 with SMTP id v48mr1561889uad.101.1508424571285; Thu, 19 Oct 2017 07:49:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.48.129 with HTTP; Thu, 19 Oct 2017 07:49:30 -0700 (PDT)
In-Reply-To: <87o9p3wkek.fsf@ta.scs.stanford.edu>
References: <CACsn0cnUbMha8ZyP5h3E7zJqo5PinppXRhWxqy2d1b6nF4XmwA@mail.gmail.com> <87o9p3wkek.fsf@ta.scs.stanford.edu>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 19 Oct 2017 07:49:30 -0700
Message-ID: <CACsn0cnXQapmKG6RrRfP8bqkyt4p0YakgH-Q0XDYivcPV1WgLg@mail.gmail.com>
To: David Mazieres expires 2018-01-17 PST <mazieres-6zhpjtw5385e45j3qtg9s3i8b6@temporary-address.scs.stanford.edu>
Cc: secdir@ietf.org, draft-ietf-tcpinc-tcpeno.all@ietf.org, iseg@ietf.org, tcpinc <tcpinc@ietf.org>
Content-Type: multipart/alternative; boundary="001a11415848bdf5e3055be776f9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/JGk-3E_7Fig-QWBHey_qP5jrJHI>
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 14:49:34 -0000
On Thu, Oct 19, 2017 at 2:34 AM, David Mazieres < dm-list-tcpcrypt@scs.stanford.edu> wrote: > 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? > More rational for the requirement would I think help. > 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... > Ah, that does work. Thanks for responding to my review. > > Thanks, > David > -- "Man is born free, but everywhere he is in chains". --Rousseau.
- 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