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

[Eric Rescorla <[e-mail]>]

On Tue, Nov 20, 2018 at 12:07 PM Miika Komu <[e-mail]> wrote:

> 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
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Rich version of this review at:
> > https://mozphab-ietf.devsvcdev.mozaws.net/D3709
> >
> >
> > 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:
>
> https://tools.ietf.org/html/rfc8005
>
> 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):
>
> https://tools.ietf.org/html/rfc6538#section-4.1
>
> 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:
>
> https://tools.ietf.org/html/rfc5338#section-3.2
>
> 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:
>
> https://tools.ietf.org/html/rfc6317
>
> 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?
>

Maybe I'm missing something, but it seems like this is not an interoperable
state of affairs.


> IMPORTANT
> > 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?
>

Proposed Standard.



> > COMMENTS
> > 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
> challenging.
>
> Did I capture your thinking correctly?
>

Well, this isn't a collision; it's what's called a preimage. I.e.,
computing a public
key with a given HIT. Anyway, as far as I can tell, in HIP being able to
compute
a preimage for HIT Y = H(K_X) is equivalent to breaking key K_X, so that
means
that that function must have reasonable strength. 2^64 is nowhere near
enough and the typical expected security level of IETF protocols is 2^128,
so that means that the full width of the IPv6 address has to be used.



> 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?
>


Yes, I think that would be good to do.


> > 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:
>
> https://tools.ietf.org/html/rfc7343#section-5
>
> (Please let me know if an explicit reference is needed)
>

No, I'm referring to the point I raised above.



> > 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:
>

I'm not following how this solves the problem. It seems like you're still
going to get
badly suboptimal routing.

-Ekr


> Existing apps:
>
> https://tools.ietf.org/html/rfc6538#section-2.3.2
> https://tools.ietf.org/html/rfc5338#section-3.2
>
> HIP native apps:
>
> https://tools.ietf.org/html/rfc6317#section-4.1.1
>
> > 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!
>