[Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions

Tom Henderson <tomh@tomh.org> Fri, 18 July 2014 06:57 UTC

Return-Path: <tomh@tomh.org>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8FFED1B2910 for <hipsec@ietfa.amsl.com>; Thu, 17 Jul 2014 23:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id juJJti4bF_FG for <hipsec@ietfa.amsl.com>; Thu, 17 Jul 2014 23:57:39 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com []) by ietfa.amsl.com (Postfix) with SMTP id 2EBA11B290C for <hipsec@ietf.org>; Thu, 17 Jul 2014 23:57:39 -0700 (PDT)
Received: (qmail 871 invoked by uid 0); 18 Jul 2014 06:57:39 -0000
Received: from unknown (HELO cmgw4) ( by gproxy2.mail.unifiedlayer.com with SMTP; 18 Jul 2014 06:57:39 -0000
Received: from box528.bluehost.com ([]) by cmgw4 with id ToxU1o00l2molgS01oxX00; Fri, 18 Jul 2014 06:57:37 -0600
X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=JlLBb9Fn3sEA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=taXjemQLJ4_xxy049BsA:9 a=wPNLvfGTeEIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=xe9IlZocI9UNCHBcZM2MWMlofb7U3LbwXXAEkWD13fk=; b=K3gEFS0SmrumE56La3VWk+Ag1cnroOEm8OMaeaI74xSreXk6q1/BJo1it/BgT9dojOMoKITBoqNK2NmvkkYXVKOx7aqZSccZwAmzIaRVN3VWaSRwExK5pzigIngQS23J;
Received: from [] (port=59860 helo=[]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <tomh@tomh.org>) id 1X826k-0006KG-9b; Fri, 18 Jul 2014 00:57:30 -0600
Message-ID: <53C8C557.3070202@tomh.org>
Date: Thu, 17 Jul 2014 23:57:27 -0700
From: Tom Henderson <tomh@tomh.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: hipsec@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth authed with tomh@tomh.org}
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/2v7ompvuUUJU8M5liR4T2vOyisw
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jul 2014 06:57:40 -0000

I'm reposting several questions and comments from Stephen Farrell 
regarding RFC5201-bis, so that we can have some list discussion.  See 
below (quoted verbatim from:

The main issues below for discussion seem to be:

- what safeguards exist to reduce tracking of users?
- questions about the choices of certain algorithms and modes and 
whether they are still current

I'll open some more issues in the tracker if we don't get to consensus 


This review is based on the diff from 5201 [1]



Work started on this in 2009 it appears and the backwards
incompatible changes made to the BEX are roughly what I'd
expect to have seen for good work done around that time.
However, some things have changed since, that I don't see
reflected in the changes made to the BEX, so I'd like to
chat about those for a bit, in case they're still
malleable. If it is really the case that the boat has
sailed for such changes, then that's life, but I wonder
has it? (I really don't know for HIP.)

I think the features in the changes to the BEX that one
would consider noteworthy were that work done today are:

(1) Mandating some form of variability of, and
confidentiality for, the (non-routable?) HIT to enhance
privacy or at least mitigate trival passive tracking of
activity across time and different connections. (Or maybe
the "anonymous HI" mechanism achieves this, I wasn't
sure? If it does, then why have any other?)

(2) There is no support for newer elliptic curves or
representations like 25519.

(3) Continuing to support the 1536 MODP DHE group but not
supporting the 2048 equivalent seems a bit odd, as does
not having a code point for the 4096 but group.
Similarly, making the 1536 bit group the MTI (in 5.2.7)
is odd as is the assertion that "web surfing" can use a
lower security level.

(4) (5.2.8) Did the WG discuss deprecating the NULL
encryption option? (Haven't you finished testing yet:-)
Also - there are no counter modes, is that wise? Finally,
HIPv1's encryption codepoint 1 was for a 3DES option, but
here you have 1 == NULL, yet you deprecate codepoint 3,
which is confusing. Why is that?

(5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If
HMAC-SHA-256 is supported, then why not just use that?
Is there are real benefit in the sha1 variant?

Comment (2014-06-26)

- abstract: SIGMA-compliant is a bit of a mouthful for an
abstract - how many readers do we really expect to get

- 1.1: Saying the HI is the identity of the host seems a
little overstated to me, but I guess that's accepted as
a description for HIP, so not objecting, but it'd seem
more natural to me to say that a HI is an identifier that
a host can use. (Presumably load-balancing and mobility
scenarios could mean that a private key could be on more
than one host or one "host" might have >1 private key.)

- section 3: 3110 doesn't seem like a great reference
for RSA. Isn't there better?