Re: [Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT)

[Robert Moskowitz <[e-mail]>]

I will be pushing out v 15 shortly with some more fixes.  This way you 
can review them as I go, rather in one go.  The items I previously said 
'fixed' were in ver 14.

On 3/6/20 9:21 AM, Robert Moskowitz wrote:
>
>
> On 3/4/20 1:28 PM, Roman Danyliw via Datatracker wrote:
>> Roman Danyliw has entered the following ballot position for
>> draft-ietf-hip-dex-13: Discuss
>>
>> 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 tohttps://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-dex/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> (initial ballot now that this draft is deferred)
>>
>> ** Section 1.2.  Thanks for the scoping provided by this applicability
>> statement.  Given the reduced security that DEX will provide, IMO it needs a
>> bit more precision (and caution).
>
> And I should point out it gives more security that has been provided 
> in these classes of devices in the past.
>
>> OLD
>>     HIP DEX MUST  only be used in communicating with such constrained
>>     devices (e.g., class 0 and 1 devices as defined in section 3 in
>>     [RFC7228]).
>>
>> NEW
>>
>> HIP DEX MUST only be used when one of the peers is a class 0 or 1 constrained
>> device as defined in Section 3 of [RFC7228].  HIP DEX MUST NOT be used if both
>> peers are class 2 constrained devices or have greater capability.
>
> Done.
>
>> ** Section 3.2.1, Per “Since collision-resistance is not possible with the
>> tools at hand, any reasonable function (e.g.  FOLD) that takes the full value
>> of the HI into generating the HIT can be used, provided that collision
>> detection is part of the HIP-DEX deployment design.  This is achieved here
>> through either an ACL or some other lookup process that externally binds the
>> HIT and HI.”, when exactly should this ACL lookup occur?  Please provide
>> guidance in an explicit step in the appropriate packet processing section
>> (i.e., in Section 6.*) on when this should be.
>
> I will look into this.  It is during I2 and R2 processing as that is 
> when the recipient can trust that the HI is for the HIT.
>
> There is also a ACL check for I1 and R1, but that is just to limit who 
> to talk to, not is the who claim valid.
>
> Also the constrained device may not have ACL checking capability. No 
> way to update the ACL in a sensor, for example.  In this case the 
> password authentication is required.
>
> I will look at the places to make sure this is covered.

See sec 7.1

>
>
>> ** Section 5.2.1 – Is this list of DH Group IDs intended to be a subset of the
>> HIP Group ID sub-registry?  If so, Curve25519 and Curve448 don’t appear to be
>> in the
>> https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-5?
>>   Should they be registered?
>
>
> Hmmm. for some reason I thought this was handled.  I will check it out 
> and if I am missed it, I will update the IANA section.

Done.  I think.

>
>> ** Section 6.3.  Per “Some payload protection mechanisms have their own Key
>> Derivation Function, and if so this mechanism SHOULD be used.”, if the payload
>> protection mechanisms have their own KDF, how would their security properties
>> be trusted if their KDF is NOT used?  Why is this SHOULD not a MUST?
>
> I need to reread this section before commenting.  If I remember right, 
> this is a dodge clause that someone wanted.  I may just end up pulling it.

I pulled this text, but kept it as a comment in the XML if someone later 
things it is needed.  ;)

And with this I am pushing out ver 15 for you to review.  As you said in 
the DOTS wg, version numbers are free.

>
>> ** Section 6.3.  The input to CKDR-Extract seems underspecified:
>> -- Per the definition of IKM, when should these different inputs be used (at
>> least two appear to be specified)?  References to Kij are made in this section
>> and in other parts of the document, but they aren’t input for CKDR-Extract()?
>
> Will research this and see if more text is needed and how.
>
>> -- Per “where ‘CKDF-Extract’ is an octet string “ in the definition of “info”
>> in CKDR-Extract(), what encoding should be used to convert that into an octet
>> string?  Is it ASCII, as in 067 075 068 070 045 069 120 116 114 097 099 116?
>
> Will check this too.
>
>> ** Section 9.  Please add language to the effect that “production deployments
>> of this specification MUST NOT use the NULL-ENCRYPT HIP_CIPHER” (to mirror the
>> language already stated in Section 5.2.2 on the topic).
>
> Good point.  Will do.
>
>> ** Section 9.2.  This mandatory guidance to validate public keys is helpful.
>> Please provide guidance in an explicit step in the appropriate packet
>> processing section (i.e., in Section 6.*) on when this should be done.
>
> I thought I did.  Grumble.  Will take care of this too.
>
>> Two “discuss discuss”-es with the caveat that I didn’t follow the WG
>> discussions.
>>
>> ** The following seems to indicate we don’t have everything we need to publish
>> a standards track document: -- Section 6.  “It should be noted that many of the
>> packet processing rules are denoted here with "SHOULD" but may be updated to
>> "MUST" when further implementation experience provides better guidance.”
>
> I did not want this, if I recall correctly.  It was something of a 
> standard wording back when this was first done.  At this point, I will 
> pull this.  It is not uncommon that a standard goes out and then some 
> years later deployment teaches us things about what SHOULD and what MUST.
>
>
>> -- Section 9.  “o  The puzzle mechanism using CMAC explained in Section 4.1.1
>> may need further study regarding the level of difficulty in order to establish
>> best practices with current generation of  constrained devices.”
>>
>> If there isn’t sufficient implementation experience, why isn’t this document
>> experimental?  What is the plan for getting better guidance?  Is there a risk
>> in not having this clarity?
>
> Actually this is another area that can be pulled now.  Rene did 
> testing on the difficulty and I believe we captured his experiences.  
> I will look at this and clarify.
>
>> ** Section 9.1.  Thanks for this section.  However, I’m not convinced that
>> SECP160R1 is needed.  DEX is already selectively profiling RFC7401 (i.e., its
>> already choosing to exclude certain things) and there are “no production”
>> implementation of DEX.  What is the rationale for keeping it?
>
> In the workgroup I was asked to keep it in?  To /harmonize/ with other 
> areas of constrained security?  This is some years back though, and it 
> is another area where by this time, we have enough to drop it?  I am 
> willing to, but I should ask on the HIPSEC list and see what private 
> replies I get.
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> ** Section 3.0.  Per “Thus, it is not expected that these parameters are
>> carried in every packet, but other methods are used to map the data packets to
>> the corresponding His”, what are these other methods?
>
> This text is lifted right out of sec 3 of rfc7401.  ESP SPIs are a 
> stated example further in that paragraph.
>
>> ** Section 3.1.  Per “There are two advantages of using a hashed encoding  over
>> the actual variable-sized public key in protocols.”, perhaps as a reminder is
>> in order that in this document the HIT isn’t a hashed encoding but a compressed.
>
> A case of lifting text from 7401 where it needs to be adjusted a bit.  
> I will make the change.
>
>> ** Section 4.1.  Per “Note that in some cases it may be possible to replace
>> this trigger packet by some  other form of a trigger, in which case the
>> protocol starts with the Responder sending the R1 packet.”, how does this
>> additional trigger occur?
>
> Some packet that has enough information for the receiver to deduce 
> that an I1 COULD have been sent and to then respond with an R1 to see 
> if the sender supports HIP.
>
> None have been defined.  This actually goes back to 5201.  More of a 
> placeholder to allow others to make adjustments in their implementation.
>
>> ** Section 4.1. Per “In such cases, another mechanism to convey the Initiator's
>> supported DH Groups (e.g., by using a default group) must be specified.”,
>> where/how would it be specified?
>
> Again, nothing has been specified, but in a closed environment it was 
> thought that an ACL or other data store would contain enough 
> information, like the supported DH Groups to successfully trigger an 
> R1 without receiving an I1.  This is more a placeholder for any 
> developer that is working on an alternative to using the I1 to note 
> all that must be done if something other than an I1 is used.
>
> "If you are going to try and optimize this protocol, remember all that 
> you have to include" kind of thing.
>
>> ** Section 4.1.2.1. Per “This strategy is based on a timeout that is set to a
>> value larger than the worst-case anticipated round-trip time (RTT ).”, how is
>> the worst case RTT computed?
>
> IIRC, the implementers want this in.  It goes back to 5201, sec 6.6.  
> Perhaps one that is still around (hint, Jeff or Tom) can comment.
>
>
>> ** Section 5.3.2.  Per “Responder sets the source HIT in the R2 packet based on
>> the destination HIT from the I1 packet”, shouldn’t this say “Responder sets the
>> source HIT in the _R1_ packet …”?
>
> OOPS!  Good catch.  Fixed.  Probably some poor job (by me!) in copying 
> and pasting text.
>
>> ** Section 5.3.2.  Per “Based on the deviating DH group ID in the HOST_ID
>> parameter, the Initiator then SHOULD abort …”, why not MUST abort?
>
> A MUST costs a round trip.  It is possible that the Initiator, based 
> on local policy, can make a decision to go with the received R1 rather 
> than restart the exchange.  Thus we chose SHOULD here over MUST.
>
>> ** Section 6.8. Step 5.  Per “5.  If any of the checks above fail, there is a
>> high probability of an ongoing man-in-the-middle or other security attack.  The
>> system SHOULD act accordingly, based on its local policy.”, this guidance seems
>> underspecified.  Could the text at least provide a recommendation of aborting
>> and logging?
>
> Seems reasonable request.  But this text goes back to 5201. Perhaps 
> some of the HIPv1 and/or v2 implementors can tell want they do here.
>
>> ** Section 9.  Per “The strength of the keys for the Pair-wise Key SA is based
>> on the quality of the random keying material.  As either peer may be a sensor
>> or an actuator device, there is a natural concern about the quality of its
>> random number generator.”, this is helpful caution. What guidance can be given
>> to ameliorate the concern?
>
> When we did IEEE 802.11i, we actually had an annex giving pseudo code 
> for gathering entropy by listening to the radio noise or how to build 
> an ring-occilator on your chip.
>
> Is there any good IETF RFC recommendation on a good RND for 
> constrained devices?  I would be happy to include copied text or a 
> reference.
>
>> ** Editorial
>> -- Section 1.2.  The sentence “Also, it is often the case that HIP DEX …” is
>> repeated twice.
>
> Thanks.   Fixed.  I kept the 2nd one as the separate para.  Reads 
> better in my opinion.
>
>> -- Section 4.1. s/the the/the/
>
> fixed.
>
>> -- Section 6.3.  Typo.
>> s/The HIP DEX KEYMAT process is based on the is the/
>> The HIP DEX KEYMAT process is based on the/
>
> fixed.
>
>> -- Section 9.2.  Editorial.  Per “With the curves specified here, there is a
>> straightforward key extraction attack, which is a very serious problem the use
>> of static keys in HIP-DEX”, there appears to be some missing words – perhaps “…
>> with the use of static keys by HIP-DEX”.
>
> thanks.  Yes, I have added "with"
>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit