Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Sat, 04 February 2017 02:27 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 C604F12952F for <tcpinc@ietfa.amsl.com>; Fri, 3 Feb 2017 18:27:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 tV66c_oht34G for <tcpinc@ietfa.amsl.com>; Fri, 3 Feb 2017 18:27:08 -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 901C0129495 for <tcpinc@ietf.org>; Fri, 3 Feb 2017 18:27:08 -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 v142R7PM093179; Fri, 3 Feb 2017 18:27:07 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v142R6A0090844; Fri, 3 Feb 2017 18:27:06 -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: <1FD85C9B-BE52-4E9F-A6D9-54BAD0425C8A@akamai.com>
References: <D668D28F-42BB-40A4-81D1-1FF2D3D95ECB@akamai.com> <87fujvonza.fsf@ta.scs.stanford.edu> <1FD85C9B-BE52-4E9F-A6D9-54BAD0425C8A@akamai.com>
Date: Fri, 03 Feb 2017 18:27:04 -0800
Message-ID: <87o9yin11j.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/gASKPXzyrdY59ng3XB2oMf9pj3k>
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-04 PDT <mazieres-rpftec6qtnb8edwhne83y7ez4s@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: Sat, 04 Feb 2017 02:27:10 -0000

"Holland, Jake" <jholland@akamai.com> writes:

> 2.a. A scenario for illustration:
>
> For instance, maybe next year somebody reads about ENO and decides to
> upgrade protocol X, their proprietary gaming application protocol, so
> that Xv2 will be identical except that the passphrase will now be
> HMAC-MD5 of passphrase+sessionID if and only if the remote connection
> sets the a-bit, instead of just the cleartext passphrase. Your example
> exactly, I think.

I guess the problem here is that protocol X might not have a way to
negotiate some new authentication mechanism, so you need some kind of
flag to do this.  The "a" bit solves that problem.  However, as you
point out, the "a" bit is a one-shot mechanism, so whatever behavior
change it triggers should have some crypto agility/negotiation facility.
In the case that you are replacing passwords, I think that's okay,
because an MD5 hash will be 32 hex digits while a SHA-256 one will be
64.  But it would be better to say "md5:XXX" or something for even more
future flexibility.

Would it address your concern if we say that when use of the "a" bit is
required to slot in a new authentication mechanism, the new mechanism
should allow some crypto agility or negotiation mechanism for future
compatibility?

> 2.b. Another different example with a different problem:
>
> Suppose I write an app that talks to servers I don’t own, and my OS
> has the recommended API feature from 4.7 (“implementations MAY provide
> a per-connection mandatory encryption mode that automatically resets a
> connection if ENO fails”), so my app tries one connection with
> mandatory encryption, then on failure with the right error code, I
> retry without encryption and with a reduced feature set of things I’m
> willing to send to the server. However, I don’t have time to implement
> session ID authentication, and the server wouldn’t accept it anyway.

The mandatory encryption mode is not intended to serve a security
function, but rather to enable TEPs to optimize connection setup using
SYN data.  An example use case would be that you are connecting to an
NFS server that you know supports TCP-ENO, so you might as well do the
key agreement right in the SYN exchange if some future TEP supports it.
(We can't allow such an optimization by default because it reduces
backwards compatibility with TCP.)

> Should my app set the a-bit? I think this version of the ENO draft
> says yes, because I have altered my behavior in the presence of
> encrypted TCP (and it wasn’t practical for me to authenticate, so I
> qualify as an exception for the first SHOULD from 5.1). I publish my
> app this way, and it’s downloaded by a few hundred folks with
> accolades about my security-consciousness.

You definitely should not set the "a" bit.  The "a" bit is there if you
need it, but there is (or should be) no implication that you "SHOULD"
set it in cases where it is not required.  Header bits are a precious
resource, so if anything applications SHOULD NOT use the "a" bit if they
do not need to.

So perhaps the clarification is that you SHOULD avoid using the "a" bit
unless you absolutely need to, and when you do use it, since there's
only one "a" bit, you SHOULD slot in a mechanism that has hooks for
future compatibility.

> 2.c. a-bit summary
>
> I think it’s likely I’m missing something, and I’m hoping that a real
> life example and a use case walk-through of a scenario where it’s
> expected to help (and maybe also an explanation of how the scenarios
> like the above 2 are avoided under a correct reading of the draft)
> will help clear things up.

I guess a real-life example might be a kerberos protocol that protects
data with DES encryption and a weak MAC.  You could specify that, when
both sides set the "a" bit, two things happen:

        1) the endpoints omit the DES encryption and weak MAC (which are
           superseded by TEP encryption), and

        2) the authenticator format is altered to replace the subkey
           field (that, in the absence of TCP-ENO, specifies a key with
           which to encrypt session data) with the TCP-ENO session ID to
           prevent man-in-the-middle attacks.

Obviously this is just an example, and the decision on the exact
interpretation would fall to whoever on the kerberos team is extending
the kerberos protocol.  I'm sure it would involve lots of trade-offs I'm
not thinking of.  But the point is that this is the kind of thing people
might want to do, and they need an extra bit in order to do it.

I don't want to put such a concrete example in the ENO RFC, because we
would be stepping on the toes of the RFC4120 authors.  The point of the
"a" bit is to give people options.  There are scenarios where the "a"
bit can be put to good use.  There are scenarios where the "a" bit is
not needed.  And there are scenarios in which the "a" bit can
effectively be wasted on some trivial feature, leaving people later to
regret that they can't use it for something more important.  But one bit
is still better than zero bits, and if paired with some other
negotiation mechanism, a single bit is sufficient to provide future
adaptability.

Does that help?

> 4. citing drafts in support of future large SYN options:
> “Is there harm in doing this?  E.g., is it bad practice to cite internet drafts (non-normatively, of course) in an RFC?”

Okay, I think you've convinced me to go with standard practice and avoid
citing internet drafts.

David