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

[Eric Rescorla <[e-mail]>]

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?



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

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.


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.


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?


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?


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