Re: [tcpinc] AD review of tcp-eno

"Black, David" <David.Black@dell.com> Thu, 27 July 2017 13:22 UTC

Return-Path: <David.Black@dell.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 BE60C132150; Thu, 27 Jul 2017 06:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.2
X-Spam-Level:
X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=bTV7cLeE; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=c5z5xc2E
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 c6fxl0yVdSCf; Thu, 27 Jul 2017 06:22:00 -0700 (PDT)
Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 CADCA131D32; Thu, 27 Jul 2017 06:21:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1501161719; x=1532697719; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qoqYWTZi6jT3ajkD/N2NUOyXmG6XC8hTmNvu5ucl2BI=; b=bTV7cLeElD5Yj2y4WJ52ML+mTfn/wUdcBnxb12K2UAN3LomNGPWknTaP gr774C1RV3X65RVGV8QCNkJpvzdpmjLZLmnWMSJ6xSqZTqZteMLTHy7gA cG5b0kyO4TzyTzmjMvQAfpaTiSGvIvBzj9ADkpWVKWuz33V5GtfU/c9Yi Y=;
Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 08:21:57 -0500
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 19:19:44 +0600
Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6RDLseS001829 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Jul 2017 09:21:56 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v6RDLseS001829
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1501161716; bh=5VgZA4oRiB8qkVll2YvA8z0JcJ0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=c5z5xc2EBWlkvXLy600+y1LafZPG/GtPyOYpLMdMxU0jku+VtMJiKCwvhtguYGSWg nw8DpqVxcHMaPisvfS6yQZiwiahVKb2y0XFQ45LIEmu6Tma6JXenagycRShSANWdSF RDo9aq+ZP37s6FZdBMIzQzBG8D++KHL4pE212QwM=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v6RDLseS001829
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd56.lss.emc.com (RSA Interceptor); Thu, 27 Jul 2017 09:21:41 -0400
Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6RDJjKt019988 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Thu, 27 Jul 2017 09:21:47 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0352.000; Thu, 27 Jul 2017 09:20:05 -0400
To: "tcpinc@ietf.org" <tcpinc@ietf.org>
CC: "draft-ietf-tcpinc-tcpeno.all@ietf.org" <draft-ietf-tcpinc-tcpeno.all@ietf.org>
Thread-Topic: AD review of tcp-eno
Thread-Index: AQHTBjGr9NIWBVpYBEqO6/K8LwyL/qJmjVgAgAEcHrA=
Date: Thu, 27 Jul 2017 13:20:05 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FB997E6@MX307CL04.corp.emc.com>
References: <55B07DA5-E274-4720-A919-83483094B9A0@tik.ee.ethz.ch> <CE03DB3D7B45C245BCA0D243277949362FB97D36@MX307CL04.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FB97D36@MX307CL04.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.127]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/PbSQoAI2Iz89SxMwNKWE8kQSeyc>
Subject: Re: [tcpinc] AD review of tcp-eno
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, 27 Jul 2017 13:22:03 -0000

And likewise resending this follow-up as draft shepherd ...

Thanks, --David


> -----Original Message-----
> From: Black, David [mailto:David.Black@dell.com]
> Sent: Wednesday, July 26, 2017 4:36 PM
> To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>ch>; draft-ietf-tcpinc-
> tcpeno.all@ietf.org
> Subject: RE: AD review of tcp-eno
> 
> Hi Mirja,
> 
> Many thanks for your careful review and comments.
> 
> In section 5, I believe we are dealing with a terminology collision:
> 
> > 4) sec 5:
> > s/TEPs MUST protect TCP data streams with authenticated
> encryption./TEPs
> > MUST protect TCP data streams with unauthenticated encryption./ ? Or do
> > you mean must support both, authenticated and unauthenticated?
> 
> The original text is correct, so this change should not be made, but that
> original text is highly susceptible to being misread, and hence does need
> attention to improve clarity.   For reasons that only security experts will be
> able explain :-), "authenticated encryption" does not include or require
> endpoint authentication.  Here's the relevant definition from Section 1 of RFC
> 5116:
> 
>    Authenticated encryption [BN00] is a form of encryption that, in
>    addition to providing confidentiality for the plaintext that is
>    encrypted, provides a way to check its integrity and authenticity.
> 
> https://tools.ietf.org/html/rfc5116#section-1
> 
> I suggest adding text to section 5 of this draft to repeat or paraphrase this
> RFC 5116 definition, and informatively cite RFC 5116 as the source.
> 
> I'll also take a small mea culpa on the IANA Considerations - I should've
> caught that in WG Last Call.
> 
> Thanks, --David
> 
> 
> > -----Original Message-----
> > From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
> > Sent: Wednesday, July 26, 2017 1:07 PM
> > To: draft-ietf-tcpinc-tcpeno.all@ietf.org
> > Subject: AD review of tcp-eno
> >
> > Hi all,
> >
> > thanks for this very well written document and detailed shepherd write-
> up!
> >
> > I’m afraid we need a new revision before IETF Last Call because the RFC
> > should only specify the actually TCP option and not the experimental one.
> So
> > you can simply remove the experimental one in Figure 1, 2 and 3 (as well as
> > sec 4.8) and only note in the IANA section that this experimental
> assignment
> > also exists, as it is already done.
> >
> > Other minor comments:
> >
> > 1) I would recommend to switch the last to paragraphs in section 4.5; I think
> > that helps understanding.
> >
> > 2) I’m wondering if it would make sense to specify at the beginning of
> section
> > 4.7 another requirement that TEPs SHOULD only specify the use of SYN
> data
> > if there is some a-priori knowledge that the other end is likely to support
> tcp-
> > eno and the tep (e.g. due to previous successful connections aka session
> > resumption, or application knowledge).
> >
> > 3) Sec 4.8 does not really specify what to do with the transcript. I guess
> that’s
> > TEP specific but it sounds like there should be a requirement stated that a
> > TEP has to check this or abort the connection…?
> >
> > 4) sec 5:
> > s/TEPs MUST protect TCP data streams with authenticated
> encryption./TEPs
> > MUST protect TCP data streams with unauthenticated encryption./ ? Or do
> > you mean must support both, authenticated and unauthenticated?
> >
> > 5) section 6: Maybe
> > OLD
> > "Figure 9 shows a three-way handshake with a successful TCP-ENO
> >    negotiation.  The two sides agree to follow the TEP identified by
> >    suboption Y.“
> > NEW
> > "Figure 9 shows a three-way handshake with a successful TCP-ENO
> >    negotiation. Host A includes two ENO suboptions with TEP identifiers X
> and
> > Y.
> >    The two sides agree to follow the TEP identified by suboption Y.“
> >
> > 6) Also looking at the example in Figure 11, I have to say that the spec does
> > not clearly state anywhere that the first ACK has to have a ENO option (it’s
> > only mention implicitly somewhere). Maybe that can be spelled out more
> > clearly (in section 4.6)?
> >
> > 7) Also based on this example. I guess it’s also possible that a middlebox
> does
> > not strip the options in the SYN packets but only in the ACK. In this case
> host
> > A would send encrypted data and host B would think they are not
> encrypted
> > and deliver garbage to the application. I’m not sure how to avoid or even
> > detect such a case but maybe it’s still good to mention this somewhere…?
> >
> > 8) section 7.2: The following is a normative requirement thats should be
> > stated normatively (MUST) somewhere in the main part of the
> specification:
> > "To stay robust in the face of dropped segments, hosts must continue
> >    to include non-SYN form ENO options in segments until such point as
> >    they have received a non-SYN segment from the other side.“
> >
> > 9) I would recommend to move 7.1 into an own section (not as part of
> > section 7 on rational), or maybe rather as a subsection of section 8.
> >
> > 10) From reading the text in the IANA section, I believe you rather what
> „RFC
> > required“ as a policy (see https://tools.ietf.org/html/rfc8126#section-4.7).
> > Early allocation are always possible and does not need to be noted
> separately
> > (see https://tools.ietf.org/html/rfc8126#section-3.4).
> >
> > 11) Do you want to specially note Andrea’s contribution to this work in the
> > acknowledgements?
> >
> > 12) RFC5226 (now RFC8126), RFC6994 (after removing the exp option from
> > the body of the doc), and RFC7413 do not need to be normative
> references.
> > Please move to informative.
> >
> > 12) Finally, two tiny things from the nits check:
> >
> https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft
> > -ietf-tcpinc-tcpeno-08.txt
> > - There shouldn’t be reference in the abstract. You can just remove it; TLS is
> > well known. You may want to add it in section 7.1 instead.
> > - RFC 5226 is obsolete
> > Both could be fixed by the editor but as you anyway have to make a new
> > revision, so you can fix these as well.
> >
> > Thanks!
> > Mirja
> >