[tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Sat, 11 November 2017 02:03 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: tcpinc@ietf.org
Delivered-To: tcpinc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C57421200C1; Fri, 10 Nov 2017 18:03:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tcpinc-tcpeno@ietf.org, David Black <david.black@dell.com>, tcpinc-chairs@ietf.org, david.black@dell.com, tcpinc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.65.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151036581280.449.10740505473540594433.idtracker@ietfa.amsl.com>
Date: Fri, 10 Nov 2017 18:03:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/Ggk8DQaUbJ5GHmZxwaIkHgWpf7I>
Subject: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 11 Nov 2017 02:03:33 -0000
Eric Rescorla has entered the following ballot position for draft-ietf-tcpinc-tcpeno-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- o TEPs MUST NOT permit the negotiation of any encryption algorithms with significantly less than 128-bit security. IMPORTANT: I don't know what "significantly means". I wouldn't be making a point of this, but it's phrased as a normative requirement, so I don't know what conformance means. IMPORTANT: This actually seems to be a bit confusing about how to handle URG. Consider TCP-use-TLS, you would just process URG in the normal way and then generate errors if URG causes reordering at the TLS layer. This seems like a reasonable procedure but is at least arguably prohibited by this text. 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 IMPORTANT: this also does not seem to be unambiguous. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 4. Provide a standard negotiation transcript through which TEPs can defend against tampering with TCP-ENO. This was unclear to me when I first read this. Maybe "Export a standard negotiation transcript to TEPs which they can use to defend against" opportunistically. It uses a new TCP option kind to negotiate one among multiple possible TCP encryption protocols or TEPs. The negotiation involves hosts exchanging sets of supported TEPs, where Nit: I would say "one TEP out of multiple" Also, "TCP encryption protocols or TEPs." is confusing. If you feel the need to redefine, do "TCP encryption protocols (TEPs)" variable-length data. When "v = 0", the byte itself constitutes the entirety of the suboption. The 7-bit value "glt" expresses one of: I would say "the remaining 7-bit value, called "glt", may take on various meanings, as defined below" "b = 0" plays the "A" role. The host that sent "b = 1" plays the "B" role. This would be clearer if it (a) explained the reasoning and (b) appeared before the packet formats. Perhaps something like "Because the passive opener MUST set b=1 and the active opener by default sets b=0, the normal cases is that the active opener is A and the passive opener is B. Applications which depend on simultaneous open and have some other way of breaking the tie can set one side to b=1 (even though it is the active opener) and thus arrange for correct role assignment. Otherwise, simultaneous opens will fail" If both sides of a connection set "b = 1" (which can happen if the active opener misconfigures "b" before calling "connect"), or both sides set "b = 0" (which can happen with simultaneous open), then Why is this "misconfigures"? You allow them to do so. initial suboption byte (see Figure 4). By default, suboption data extends to the end of the TCP option. Hence, if only one suboption requires data, the most compact way to encode it is to place it last Why is this "by default"? It just seems like another setting of glt. connection or when there is any ambiguity over the meaning of the SYN data. This requirement applies to hosts that implement ENO even when ENO has been disabled by configuration. However, note that I think you may mean to say "when the last SYN TEP is not eventually negotiated" o TEPs MUST NOT depend on long-lived secrets for data confidentiality, as implementations SHOULD provide forward secrecy some bounded, short time after the close of a TCP connection. Maybe "depend solely" because one might want to use a DH mode where a static DH key is mixed in with an ephemeral. probability detect a FIN flag that was set or cleared in transit and does not match the sender's intent. A TEP MAY discard a segment with such a corrupted FIN bit, or may abort the connection What is "high probability" that disable urgent data by default. The exception is when applications and protocols are known never to send urgent data. (4) B -> A: SYN-ACK ENO<b=1,X,Y,Z> [rest of connection encrypted according to TEP Y] Can you show a=0 in line 1?
- [tcpinc] Eric Rescorla's Discuss on draft-ietf-tc… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Black, David
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Kyle Rose
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Black, David
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… David Mazieres
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Black, David
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… David Mazieres
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… David Mazieres
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… David Mazieres
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Black, David
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Tero Kivinen
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… David Mazieres
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Amanda Baber
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… David Mazieres
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Black, David
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Tero Kivinen
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Black, David
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Tero Kivinen
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… David Mazieres
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Amanda Baber
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Amanda Baber
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… David Mazieres
- Re: [tcpinc] Eric Rescorla's Discuss on draft-iet… Amanda Baber