Re: [Hipsec] Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

Miika Komu <> Tue, 20 November 2018 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E69E130EF2; Tue, 20 Nov 2018 12:07:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QGnCpnsXP_RT; Tue, 20 Nov 2018 12:07:12 -0800 (PST)
Received: from ( [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55E86130E8F; Tue, 20 Nov 2018 12:07:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=20161220; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:Cc:To:Subject:From:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lDDV8VNcpv1Iw6xr3aeDGiXDJGktxKvwVXZ0RlKZWAM=; b=fpjd8945r17EJiXSfYA2/7vO8b BUa929eR2nM7vV7XIMj8HTD3mw10xIMjFycp71dxDkAp9J+od5XnPjMnPZ/boSVtpt5apwL0OG083 SigTe+7BarOzRvaKFeE00p9C+aGv0hZ1Se0IuodnfthxLfw+MT8FkhUdlG2Wxb81LLxRzHJ8FUqYs ILHEAwTQ9j3sk+rxe/xK7ixlwQ4jKdlTNbYOcFWOhgrnoydA5qR7Yl22U8YejdgPlB6rslvMlclaC Nxc/e0zj6QfB14NXMrXWPq95b8h0bm4JezTCLIgE2YHc9a7lF9sqr1MGGVbs0mgIDCxRupi9LISsN zmpJkcdw==;
Received: from ([] helo=[]) by with esmtp (Exim 4.89) (envelope-from <>) id 1gPCIb-0002o2-IR; Tue, 20 Nov 2018 22:07:05 +0200
From: Miika Komu <>
To: Eric Rescorla <>, The IESG <>
Cc:, Gonzalo Camarillo <>,,
References: <>
Message-ID: <>
Date: Tue, 20 Nov 2018 22:07:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
X-Mailman-Approved-At: Thu, 22 Nov 2018 05:47:18 -0800
Subject: Re: [Hipsec] Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Nov 2018 20:10:46 -0000

Hi Eric,

On 5/7/18 00:41, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-hip-rfc4423-bis-19: No Objection
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Rich version of this review at:
> Maybe I'm missing something important, but I don't see in this
> document how you go from a HI (or HIT) to the corresponding IP
> locator. That seems pretty critical to making this work. Can you point
> me in the right direction?

(I interpret "right" direction here as how to implement this in 
practice; please let me know if you were asking for something else)

Existing applications can utilize LSIs or HITs, for instance, via 
/etc/hosts in Linux or if the developer/user uses them directly. 
Mappings can be configured manually. A better way is to use ,e.g., DNS 
to store the FQDN, HIs, IP address mappings:

An application can receive LSIs or HITs from DNS queries when a HI 
record exists for a host. This can be implemented  in the local resolver 
library (e.g. glibc in Linux) supports it and sends the HI-to-IP address 
mapping to the local HIP daemon. As an alternative implementation 
technique, dynamic relinking of applications (i.e., LD_PRELOAD in Linux):

As yet another alternative, RFC5338 (section 3.2) suggests interposing 
HIP-aware agents (think about HIP-capable DNS proxy like "dnsmasq" in 
Linux) that translate HIs into LSIs and HITs to the application and 
cache the IP address mapping to the HIP daemon:

That's all for existing applications. New HIP native applications could 
use DNS library extensions for getaddrinfo() that would be implemented 
e.g. in glibc in Linux:

All of the mentioned references are mentioned in the draft. Should I add 
something more compressed along these lines of text or is this too detailed?

> S 11.3.1.
>>       avoiding manual configurations.  The three components are further
>>       described in the HIP experiment report [RFC6538].
>>       Based on the interviews, Levae et al suggest further directions to
>>       facilitate HIP deployment.  Transitioning the HIP specifications to
>>       the standards track may help, but other measures could be taken.  As
> This confuses me, because we seem to be looking to advance some of the
> HIP specs (e.g., hip-dex) at PS

Can you elaborate? And do you mean protocol stack by PS?

(This text is based on the subjective opinions of the interviewed 
people. So I don't think it matters so much)

> S 3.1.
>>          were obtained.  For 64 bits, this number is roughly 4 billion.  A
>>          hash size of 64 bits may be too small to avoid collisions in a
>>          large population; for example, there is a 1% chance of collision
>>          in a population of 640M.  For 100 bits (or more), we would not
>>          expect a collision until approximately 2**50 (1 quadrillion)
>>          hashes were generated.
> It's not just a matter of collisions being hard, but also of being
> difficult to produce an HI with a given name.

...where name would be the hash (i.e. HIT). So I added:

Besides accidental collisions, it is also worth noting that intentional 
collisions are difficult to accomplish because generating a valid, 
colliding hash along with its private-public key is computationally 

Did I capture your thinking correctly?

> S 4.
>>       'well known', some unpublished or 'anonymous'.  A system may self-
>>       assert its own identity, or may use a third-party authenticator like
>>       DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion
>>       to another namespace.  It is expected that the Host Identifiers will
>>       initially be authenticated with DNSSEC and that all implementations
>>       will support DNSSEC as a minimal baseline.
> This wasn't a very good assumption when 4423 was published, and it
> seems even worse now, given the low rate of deployment of DNSSEC and
> the fact that we know many middleboxes break DNSSEC.

Then I guess it would be fine to remove the last sentence?

> S 4.3.
>>       packet.  Consequently, a HIT should be unique in the whole IP
>>       universe as long as it is being used.  In the extremely rare case of
>>       a single HIT mapping to more than one Host Identity, the Host
>>       Identifiers (public keys) will make the final difference.  If there
>>       is more than one public key for a given node, the HIT acts as a hint
>>       for the correct public key to use.
> How do you handle second-preimage attacks on the hash?

I guess you are referring to this:

(Please let me know if an explicit reference is needed)

> S 5.1.
>>       At the server side, utilizing DNS is a better alternative than a
>>       shared Host Identity to implement load balancing.  A single FQDN
>>       entry can be configured to refer to multiple Host Identities.  Each
>>       of the FQDN entries can be associated with the related locators, or a
>>       single shared locator in the case the servers are using the same HIP
>>       rendezvous server Section 6.3 or HIP relay server Section 6.4.
> This is becoming a less common practice. How do you handle anycast,
> which is the modern practice?

I added the following statement:

"It is also worth noting that opportunistic mode is also required 

in practice when anycast IP addresses would be utilized as locators:"

Does this address your concern?

Btw, opportunistic mode is further described in the following documents:

Existing apps:

HIP native apps:

> S 7.
>>       The encapsulation format for the data plane used for carrying the
>>       application-layer traffic can be dynamically negotiated during the
>>       key exchange.  For instance, HICCUPS extensions [RFC6078] define one
>>       way to transport application-layer datagrams directly over the HIP
>>       control plane, protected by asymmetric key cryptography.  Also, S-RTP
> Nit: SRTP, no hyphen

Thanks, fixed!