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

Watson Ladd <> Thu, 19 October 2017 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F4BD12421A; Thu, 19 Oct 2017 07:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vLvo7_tabPh4; Thu, 19 Oct 2017 07:49:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54AEC124B17; Thu, 19 Oct 2017 07:49:32 -0700 (PDT)
Received: by with SMTP id s41so6158720uab.10; Thu, 19 Oct 2017 07:49:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id v48mr1561889uad.101.1508424571285; Thu, 19 Oct 2017 07:49:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 19 Oct 2017 07:49:30 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Watson Ladd <>
Date: Thu, 19 Oct 2017 07:49:30 -0700
Message-ID: <>
To: David Mazieres expires 2018-01-17 PST <>
Cc:,,, tcpinc <>
Content-Type: multipart/alternative; boundary="001a11415848bdf5e3055be776f9"
Archived-At: <>
Subject: Re: [tcpinc] Review of draft-ietf-tcpinc-tcpeno-10
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Oct 2017 14:49:34 -0000

On Thu, Oct 19, 2017 at 2:34 AM, David Mazieres <> wrote:

> Watson Ladd <> 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".