Re: [tcpinc] AD review of tcp-eno
David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Thu, 27 July 2017 20:29 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 3AB87132198; Thu, 27 Jul 2017 13:29:08 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HcUOEGjJC5IS; Thu, 27 Jul 2017 13:29:06 -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 84DE7131DA6; Thu, 27 Jul 2017 13:29:06 -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 v6RKT6DJ096065; Thu, 27 Jul 2017 13:29:06 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v6RKT5kT010627; Thu, 27 Jul 2017 13:29:05 -0700 (PDT)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, draft-ietf-tcpinc-tcpeno.all@ietf.org
Cc: tcpinc <tcpinc@ietf.org>
In-Reply-To: <80C705CD-8A24-49A9-A1B8-6FA7B2162941@kuehlewind.net>
References: <55B07DA5-E274-4720-A919-83483094B9A0@tik.ee.ethz.ch> <80C705CD-8A24-49A9-A1B8-6FA7B2162941@kuehlewind.net>
Reply-To: David Mazieres expires 2017-10-25 PDT <mazieres-jcdqn4cj29iym4ysariezfidys@temporary-address.scs.stanford.edu>
Date: Thu, 27 Jul 2017 13:29:05 -0700
Message-ID: <87fudh62um.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/tjSdtYufbZ6hZSpbW3ck6pC-AJM>
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 20:29:08 -0000
"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> writes: > 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. Thanks for the feedback. Just to confirm, is this still what we should do after the discussion? Or are there other things we need to add (like Joe's suggestion not to send both option types)? > 1) I would recommend to switch the last to paragraphs in section 4.5; > I think that helps understanding. Good idea, but requires a little wordsmithing. Here is the proposed new language: A passive opener (which is always host B) sees the remote host's SYN segment before constructing its own SYN-ACK segment. Hence, a passive opener SHOULD include only one TEP identifier in SYN-ACK segments and SHOULD ensure this TEP identifier is valid. However, simultaneous open or implementation considerations can prevent host B from offering only one TEP. To accommodate scenarios in which host B sends multiple TEP identifiers in the SYN-ACK segment, the _negotiated TEP_ is defined as the last valid TEP identifier in host B's SYN-form ENO option. This definition means host B specifies TEP suboptions in order of increasing priority, while host A does not influence TEP priority. > 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). This may be true for SYN-only segments, but doesn't necessarily hold for SYN-ACK. To my mind, the requirement that "To avoid unexpected connection aborts, ENO implementations MUST disable the use of data in SYN-only segments by default" is both stronger and more specific than saying only with a-priori knowledge. Essentially we are saying the application has to request it. So for now I haven't done anything with this feedback. Let me know if you have a more specific suggestion. > 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…? What to do with the transcript is highly TEP specific, but since every TEP will need to reference a transcript to comply with the requirements of section 5.1, it seemed simpler and less error prone to define one explicitly as part of TCP-ENO. The connection doesn't need to be aborted, but the session IDs won't match. Basically the transcript is required for the following point in section 5.1: The session ID MUST depend in a collision-resistant way on all of the following (meaning it is computationally infeasible to produce collisions of the session ID derivation function unless all of the following quantities are identical): ... * The negotiation transcript specified in 4.8. So for now I haven't done anything, but am open to more suggestions if you think this still needs to be fixed. > 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? As David Black pointed out, the language was correct but maybe confusing. Here is the new proposed language: TEPs MUST protect TCP data streams with authenticated encryption. (Note "authenticated encryption" designates the REQUIRED form encryption algorithm [@RFC5116]; it does not imply any actual endpoint authentication.) > 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.“ Fixed. > 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)? This was the intent of the first sentence of section 4.6: A host employing TCP-ENO for a connection MUST include an ENO option in every TCP segment sent until either encryption is disabled or the host receives a non-SYN segment. Rather than fiddle with 4.6, I propose clarifying section 6 as follows: (1) A -> B: SYN ENO<X,Y> (2) B -> A: SYN-ACK ENO<b=1,X> [ENO stripped by middlebox] (3) A -> B: ACK [rest of connection unencrypted legacy TCP] Figure 11: Failed TCP-ENO negotiation because of network filtering Figure 11 Shows another handshake with a failed encryption negotiation. In this case, the passive opener B receives an ENO option from A and replies. However, the reverse network path from B to A strips ENO options. Hence, A does not receive an ENO option from B, disables ENO, and does not include a non-SYN-form ENO option in segment 3 when ACKing B's SYN. Had A not disabled encryption, Section 4.6 would have required it to include a non-SYN ENO option in segment 3. The omission of this option informs B that encryption negotiation has failed, after which the two hosts proceed with unencrypted TCP. > 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…? I propose addressing this in section 8, as follows: Once TCP-ENO is deployed, we will be in a better position to gather data on two types of failure: ... 2. Middleboxes causing TCP-ENO connections to fail completely. This can happen if middleboxes perform deep packet inspection and start dropping segments that unexpectedly contain ciphertext, or if middleboxes inconsistently strip ENO options from packets in the same direction. > 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.“ I have deleted the word "must" from here. Section 7 is not intended to be normative, but rather describe the rationale for having made this requirement elsewhere in the document. > 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. Is this because you thought section 7.1 was trying to establish normative requirements? A lot of those details were previously more closely intermingled with the specification, which the working group did not like. Now that we've got those points separated out into section 7 but still part of the document, I think it reads more cleanly. Hence, my inclination would be to leave 7.1 as is (other than deleting "must"), but if you want to elaborate on why it should be moved, you can probably change my mind. > 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). The specification required was intentional, because we wanted to avoid the same chicken-and-egg problem caused by the need for a TCP option. Since the point of TCP-ENO is to make it significantly easier to develop future TEPs than it would be to develop TCP encryption schemes from scratch, and since the TCP option for tcpcrypt and TCP-ENO caused a fair amount of friction in the TCPINC working group, I feel reasonably strongly that it would be best to give out TEP identifiers well in advance of RFC publication, provided there is a plausible draft specification. My strong preference would thus be to leave things as is, but of course in the end I would defer to you if based on your experience you really think it needs to be RFC required. > 11) Do you want to specially note Andrea’s contribution to this work > in the acknowledgements? Hmm... we definitely want to leave Andrea as first author the same as if he hadn't died, reflecting the fact that he was the main person behind the work. If we put anything in the acknowledgments, it could diminish his contributions by emphasizing the fact that other people had to "finish" the document, when really what we are doing at this point is just tiny little cleanups. > 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. Fixed. > 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. Both fixed. If you just confirm what to do about the TCP option kinds and obviously voice any objections to my proposed fixes above, we can get a new draft uploaded soon. Thanks, David
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Black, David
- Re: [tcpinc] AD review of tcp-eno Joe Touch
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Joe Touch
- Re: [tcpinc] AD review of tcp-eno Joe Touch
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno David Mazieres
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Kyle Rose
- Re: [tcpinc] AD review of tcp-eno Kyle Rose
- Re: [tcpinc] AD review of tcp-eno David Mazieres
- Re: [tcpinc] AD review of tcp-eno David Mazieres
- Re: [tcpinc] AD review of tcp-eno Black, David
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)