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

Robert Moskowitz <> Fri, 13 March 2020 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33EB93A0404; Fri, 13 Mar 2020 10:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TSTfc731fm2k; Fri, 13 Mar 2020 10:45:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4ACB3A0402; Fri, 13 Mar 2020 10:45:33 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79C166212C; Fri, 13 Mar 2020 13:45:31 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 2RFxHLY1bdku; Fri, 13 Mar 2020 13:45:12 -0400 (EDT)
Received: from (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E246762111; Fri, 13 Mar 2020 13:45:11 -0400 (EDT)
From: Robert Moskowitz <>
To: Roman Danyliw <>, The IESG <>
Cc:,,, Gonzalo Camarillo <>
References: <> <>
Message-ID: <>
Date: Fri, 13 Mar 2020 13:45:06 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------3E58DD0C462A35E0235A32D7"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Hipsec] Roman Danyliw's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and 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: Fri, 13 Mar 2020 17:45:37 -0000

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 to
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> (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
>>   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.
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> ** 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 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
HTT Consulting

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