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

[Benjamin Kaduk <[e-mail]>]

On Fri, Jan 04, 2019 at 04:49:00PM +0000, Miika Komu wrote:
> Hi Benjamin,
> 
> On 5/9/18 23:58, Benjamin Kaduk wrote:
> > Benjamin Kaduk 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:
> > ----------------------------------------------------------------------
> > 
> > I share Eric's concerns about the need for
> > second-preimage-resistance from the hash, and in particular with the
> > birthday bound, it's unclear that using a 128-bit hash leaves a very
> > large margin for growth.
> 
> we'll address the comments in a response to Eric's original email.
> 
> > Some other section-by-section notes follow.
> > 
> > Section 1
> > 
> >     [...] HIP provides for limited forms of trust between systems,
> >     enhance mobility, multi-homing and dynamic IP renumbering, aid in
> >     protocol translation / transition, and reduce certain types of
> >     denial-of-service (DoS) attacks.
> > 
> > I think that something is weird here with singular vs. plural in the
> > list elements.
> 
> Adding -s in the end of the verbs (enhances / aids / reduces) probably 
> fixes the issue you mentioned?

I think so, yes.

> > Section 4
> > 
> > I agree with the secdir reviewer's not about "SHOULD NOT [implement
> > non-cryptographic HIP]"
> 
> The text has changed a bit during the reviews, but I changed the wording 
> to uppercase now:
> 
> In this document, some non-cryptographic forms of HI and HIP are 
> referenced, but cryptographic forms SHOULD be preferred because they are 
> more secure than their non-cryptographic counterparts.
> 
> (Btw, the type of draft is "informal" so I am not sure how much mandate 
> this has, but changed nevertheless)

Thanks!

> > Section 5.1
> > 
> >     At the client side, a host may have multiple Host Identities, for
> >     instance, for privacy purposes.  Another reason can be that the
> >     person utilizing the host employs different identities for different
> >     administrative domains as an extra security measure.  If a HIP-aware
> >     middlebox, such as a HIP-based firewall, is on the path between the
> >     client and server, the user or the underlying system should carefully
> >     choose the correct identity to avoid the firewall to unnecessarily
> >     drop HIP-based connectivity [komu-diss].
> > 
> > In addition to the firewall case, choosing the correct identifier
> > can also impact the privacy considerations, as a given identifier
> > would be trackable by on-path entities.
> 
> should I add something, I think privacy is mentioned already on the 
> first sentence?

I don't have any concise suggestions for new text, so probably fine to just
leave as-is.

> > Section 6.2
> > 
> >     When a node moves while communication is already on-going, address
> >     changes are rather straightforward.  The peer of the mobile node can
> >     just accept a HIP or an integrity protected ESP packet from any
> >     address and ignore the source address.  However, as discussed in
> >     Section 12.2 below, a mobile node must send a HIP UPDATE packet to
> >     inform the peer of the new address(es), and the peer must verify that
> >     the mobile node is reachable through these addresses.
> > 
> > Am I reading this right that from a technical perspective, the peer
> > can just accept stuff from wherever, but from a policy/protocol
> > perspective the UPDATE requirement is included?  The text could
> > probably be a bit more clear, potentially even without using RFC
> > 2119 language.
> 
> I would suggest the following to simplify the text a bit:
> 
>     When a mobile node moves while communication is already on-going,
>     address changes are rather straightforward.  The mobile node sends a
>     HIP UPDATE packet to inform the peer of the new address(es), and the
>     peer then verifies that the mobile node is reachable through these
>     addresses.  This way, the peer can avoid flooding attacks as further
>     discussed in Section 11.2.
> 
> Does that work for you?

That is much easier to read, thanks.

> > Section 10
> > 
> >     There are a number of variables that influence the HIP exchange that
> >     each host must support.  All HIP implementations should support at
> >     least 2 HIs, one to publish in DNS or similar directory service and
> >     an unpublished one for anonymous usage.  Although unpublished HIs
> > 
> > I suggest a parenthetical that the unpublished one should expect to
> > be rotated frequently in order to disrupt linkability/trackability.
> 
> added some text in parenthesis:
> 
> ...one to publish in DNS or similar directory service and an unpublished 
> one for anonymous usage (that should expect to be rotated frequently in 
> order to disrupt linkability/trackability).
> 
> >     will be rarely used as responder HIs, they are likely to be common
> >     for initiators.  Support for multiple HIs is recommended.  [...]
> > 
> > If multiple means "more than two", it's probably better to say that.
> > (If multiple means "more than one", this is just a weaker version of
> > "should support at least 2", above.)  And it's rather tempting to
> > make it a MUST, anyway.
> 
> I double checked this from RFC7401 and I would change the last sentence to:
> 
>     As stated in [RFC7401], "all
>     HIP implementations MUST support more than one simultaneous HI, at
>     least one of which SHOULD be reserved for anonymous usage", and
>     "support for more than two HIs is RECOMMENDED".

Ah, that's a good plan.

> >     Many initiators would want to use a different HI for different
> >     responders.  The implementations should provide for a policy mapping
> >     of initiator HITs to responder HITs.  This policy should also include
> >     preferred transforms and local lifetimes.
> > 
> > "mapping of initiator to responder" is potentially confusing, in
> > that in practice the procedure will be "I want to talk to responder
> > A, so let me look up that I use HIT X to talk to responder A", which
> > is the opposite direction from this text.
> 
> Good catch, this was text was referencing old RFC5201 text that was 
> replaced by RFC7401. I'd change the text as follows:
> 
>     As stated in [RFC7401], "Initiators MAY use a different HI for
>     different Responders to provide basic privacy.  Whether such private
>     HIs are used repeatedly with the same Responder, and how long these
>     HIs are used, are decided by local policy and depend on the privacy
>     requirements of the Initiator".
> 
> Similarly, I would update change the following paragraph (with similarly 
> outdated text):
> 
> "Responders would need a similar policy, describing the hosts allowed to 
> participate in HIP exchanges, and the preferred transforms and local 
> lifetimes."
> 
> ...as follows:
> 
>     According to [RFC7401], "Responders that only respond to selected
>     Initiators require an Access Control List (ACL), representing for
>     which hosts they accept HIP base exchanges, and the preferred
>     transport format and local lifetimes.  Wildcarding SHOULD be
>     supported for such ACLs, and also for Responders that offer public or
>     anonymous services".
> 
> Does this work for you?

I think so, thanks.

> > Section 11.1
> > 
> > I'd consider replacing "is an attempt to" with "attempts to" -- for
> > example, IPv6 tries to do a lot of things in addition to killing
> > NAT!
> 
> ok, changed
> 
> > Section 11.3.1
> > 
> >     [...]Second, a
> >     data plane component is needed.  Most HIP implementations utilize the
> >     so called BEET mode of ESP that has been available since Linux kernel
> >     2.6.27, but is included also as a userspace component in a few of the
> >     implementations.
> > 
> > Nit: "but ESP is included", I think.
> 
> I changed to:
> 
> Most HIP implementations utilize the so called BEET mode of ESP that
> has been available since Linux kernel 2.6.27, but the BEET mode is also
> included as a userspace component in a few of the implementations.

Ah, of course; thanks for fixing it up properly :)

> > Section 12.1
> > 
> > I don't understand the usage of "a-priori" in:
> >     The need to support multiple hashes for generating the HIT from the
> >     HI affords the MitM to mount a potentially powerful downgrade attack
> >     due to the a-priori need of the HIT in the HIP base exchange.
> 
> I agree that this is a bit confusing. I would simplify (and generalize) 
> this text as follows:
> 
> A MitM attacker could try to replay older I1 or R1 messages using weaker 
> cryptographic algorithms as described in section 4.1.4 in RFC7401.
> 
> How does this sound?

That sounds good to me.

> >     In HIP, the Security Association for ESP is indexed by the SPI; the
> >     source address is always ignored, and the destination address may be
> >     ignored as well.  Therefore, HIP-enabled Encapsulated Security
> >     Payload (ESP) is IP address independent.  This might seem to make
> >     attacking easier, but ESP with replay protection is already as well
> >     protected as possible, and the removal of the IP address as a check
> >     should not increase the exposure of ESP to DoS attacks.
> > 
> > It seems like there's still some potential incrased exposure, as
> > validating the ESP crypto is presumably more expensive than
> > validating source/destination IP addresses.
> 
> the destination address can be ignored or included the checks, this is 
> an implementation issue as indicated by the ESP RFC:
> 
> https://tools.ietf.org/html/rfc4303#section-2.1
> 
> Would changing the "may" to "MAY" fix your concern (noting that this 
> draft is still of informal type)?

I would suggest not changing to uppercase "MAY" if the actual normative
requirement is from another document (e.g., RFC 4303).

The point I was trying to make is that validating the ESP crypto is a more
expensive operation than just comparing IP address values, so that if my
"before" situation doesn't involve IPsec, then there is increased DoS
exposure.  But if the "before" is "ESP with source/destination address
validation" and the "after" is "ESP without source/destination address
validation", then yes, there is no increased exposure.  So perhaps I was
just misreading the intended statement.

-Benjamin

> > Section 12.3
> > 
> >     [...] At middleboxes, HIP-aware
> >     firewalls [lindqvist-enterprise] can use HITs or public keys to
> >     control both ingress and egress access to networks or individual
> >     hosts, even in the presence of mobile devices because the HITs and
> >     public keys are topologically independent. [...]
> > 
> > Nit: I think that just "topology independent" is what's intended.
> 
> changed, thanks!