Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Fri, 03 February 2017 05:14 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 1FB24129BB1 for <tcpinc@ietfa.amsl.com>; Thu, 2 Feb 2017 21:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Level:
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Xi_u69tzXKbN for <tcpinc@ietfa.amsl.com>; Thu, 2 Feb 2017 21:14:06 -0800 (PST)
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 A4DE8129ACD for <tcpinc@ietf.org>; Thu, 2 Feb 2017 21:14:06 -0800 (PST)
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 v135E4U3049023; Thu, 2 Feb 2017 21:14:04 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v135E4oB076370; Thu, 2 Feb 2017 21:14:04 -0800 (PST)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: "Holland, Jake" <jholland@akamai.com>, "tcpinc@ietf.org" <tcpinc@ietf.org>
In-Reply-To: <D668D28F-42BB-40A4-81D1-1FF2D3D95ECB@akamai.com>
References: <D668D28F-42BB-40A4-81D1-1FF2D3D95ECB@akamai.com>
Date: Thu, 02 Feb 2017 21:14:01 -0800
Message-ID: <87fujvonza.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/_L2PLDqQyFYHc0ucU5WdOGABVJ4>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2017-05-03 PDT <mazieres-pkpvjfsmw3tssivxtan28pfsqw@temporary-address.scs.stanford.edu>
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: Fri, 03 Feb 2017 05:14:08 -0000
"Holland, Jake" <jholland@akamai.com> writes: > A few suggestions that I think might improve the doc: Thanks for going through the document. > 1. There should be a MUST for an API that an application can use to > discover whether a connection ended up encrypted, unless it’s there > and I missed it. I couldn’t find one in the doc, but it seems a likely > vital point for anything that satisfies the application-aware > definition. This is a good catch. There used to be a requirement that implementations MUST provide an API for getting the session ID that MUST give an error if the connection is not TEP-encrypted, but I think this got moved into the informational API draft. The natural place to mention this would be section 9 (security considerations). > 2. I’d like to see a section that lists a use case or 2 that can be > solved by knowing the remote host’s a-bit (or with the mandatory > application-aware mode), and how the a-bit solves them. I assume I’m > missing something obvious, but I haven’t been able to come up with a > use case that does anything useful with the remote a-bit. This is mentioned in the second paragraph of section 9 ("applications MAY use the application-aware bit to negotiate the inclusion of session IDs in authentication.") However, if you think the point is worth making more explicitly, maybe a place to do this would be in a new subsection of 7 (design rationale). > (An example guess: is the whole point so that you can avoid sending > sensitive data if the remote app itself hasn’t done anything to become > secure? And if so, is there some reason the application-layer protocol > shouldn’t be in charge of determining that?) Actually the point is to enable incremental steps towards security legacy protocols. Let's say that today some protocol X sends plaintext authentication cookie. With TCP-ENO, at least the cookie isn't available to a passive eavesdropper, but it's still not very secure. So you use the application-aware bit to signal that instead of a cookie, you will send a MAC of the session ID under the cookie, thereby keeping the cookie secret. Then in a few years, once everyone is always setting the application-aware bit, you disable the old authentication behavior or issue some warning, or provide some sort of application-aware pinning mechanism to prevent rollback attacks. The application-aware bit is what allows this incremental improvement in security to happen without a flag day, because having a flag day would be a show stopper for a lot of legacy protocols. Does that make sense? And does it merit its own section 7.6 or something? > 3. All 3 instances of “manual(ly)” in the doc seem better if changed > to “explicit(ly)” (sections 4.2 and 7.4) That's an easy change. > 4. In section 7.1, the hopes of increasing TCP’s SYN option space seem > exaggerated. EDO does not apply to SYN, and of the other 2 cited > drafts, one is expired over a year ago and the other looks, I guess > I’d call it "tricky", in addition to being experimental. It might be > better to remove the second and third paragraphs of section 7.1, or at > least reduce to just the one example of a live and applicable draft > (and maybe noting that it’s experimental). I agree that large SYN options seem like kind of a long shot, but if they ever happen, ENO stands to benefit. So part of the point here is to make it unambiguous that ENO would benefit from large SYN options and is ready to take advantage of them, because A) it's true, and B) it could potentially strengthen the case for current or future large option designs. Is there harm in doing this? E.g., is it bad practice to cite internet drafts (non-normatively, of course) in an RFC? David
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Scharf, Michael (Nokia - DE)
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno David Mazieres
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Joe Touch
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Joe Touch
- Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno Holland, Jake
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Scharf, Michael (Nokia - DE)
- Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tc… Black, David