Return-Path: 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: <87o9p3wkek.fsf@ta.scs.stanford.edu> From: Watson Ladd Date: Thu, 19 Oct 2017 07:49:30 -0700 Message-ID: To: David Mazieres expires 2018-01-17 PST Cc: secdir@ietf.org, draft-ietf-tcpinc-tcpeno.all@ietf.org, iseg@ietf.org, tcpinc Content-Type: multipart/alternative; boundary="001a11415848bdf5e3055be776f9" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:49:34 -0000 --001a11415848bdf5e3055be776f9 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 19, 2017 at 2:34 AM, David Mazieres < dm-list-tcpcrypt@scs.stanford.edu> 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". --Rousseau. --001a11415848bdf5e3055be776f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 19, 2017 at 2:34 AM, David Mazieres <<= a href=3D"mailto:dm-list-tcpcrypt@scs.stanford.edu" target=3D"_blank">dm-li= st-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.=C2=A0 These comments were written primarily for the benefit of t= he
> security area directors.=C2=A0 Document editors and WG chairs should t= reat
> 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.=C2=A0 For example, the TEP has to be 33 bytes, and we don't want the last 16 of them being zeros.=C2=A0 Moreove= r, if
people sign session IDs for authentication, we want to be absolutely
sure they don't mess up the domain separation.=C2=A0 As another example= ,
someone might use a session ID on one connection to try to authenticate
a session ID on another.=C2=A0 Do you buy this rationale?=C2=A0 And is it important enough that you think we need to add a subsection to the
rationale section discussing it?

More r= ational 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<= br> > ensure that every TEP produces different keys (with high probability)<= br> > (and session identifiers) for different transcripts to prevent
> cross-protocol attacks.

Do you mind clarifying this comment?=C2=A0 I assume it's in rela= tion the
following two paragraphs from sections 4.8 and 10 respectively?

=C2=A0 =C2=A0To defend against attacks on encryption negotiation itself, a = TEP
=C2=A0 =C2=A0MUST with high probability fail to establish a working connect= ion
=C2=A0 =C2=A0between two ENO-compliant hosts when SYN-form ENO options have= been
=C2=A0 =C2=A0altered in transit.=C2=A0 (Of course, in the absence of endpoi= nt
=C2=A0 =C2=A0authentication, two compliant hosts can each still be connecte= d to a
=C2=A0 =C2=A0man-in-the-middle attacker.)=C2=A0 To detect SYN-form ENO opti= on
=C2=A0 =C2=A0tampering, TEPs must reference a transcript of TCP-ENO's n= egotiation.

=C2=A0 =C2=A0...

=C2=A0 =C2=A0Because TCP-ENO enables multiple different TEPs to coexist, se= curity
=C2=A0 =C2=A0could potentially be only as strong as the weakest available T= EP.=C2=A0 In
=C2=A0 =C2=A0particular, if session IDs do not depend on the TCP-ENO transc= ript in
=C2=A0 =C2=A0a strong way, an attacker can undetectably tamper with ENO opt= ions to
=C2=A0 =C2=A0force negotiation of a deprecated and vulnerable TEP.=C2=A0 To= avoid such
=C2=A0 =C2=A0problems, TEPs MUST compute session IDs using only well-studie= d and
=C2=A0 =C2=A0conservative hash functions.=C2=A0 That way, even if other par= ts of a TEP
=C2=A0 =C2=A0are vulnerable, it is still intractable for an attacker to ind= uce
=C2=A0 =C2=A0identical session IDs at both ends after tampering with ENO co= ntents
=C2=A0 =C2=A0in 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.=C2=A0 The extra byte in session IDs should save us from cases wher= e
somehow both SHA-512 and Keccac are secure, but someone found two inputs x and y such that SHA-512(x)=3D=3DSHA-3(y) causing reuse of Session IDs
across TEPs.=C2=A0 So I can't figure out the attack you are worried abo= ut...

Ah, that does work. Thanks for re= sponding to my review.
=C2=A0

Thanks,
David



--
"Man is born f= ree, but everywhere he is in chains".
--Rousseau.
--001a11415848bdf5e3055be776f9--