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