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

[Robert Moskowitz <[e-mail]>]

Ben,

In ver 18 I have replaced "Perfect Forward Secrecy" with "Forward Secrecy".

That seems to be a consensus on saag.

Please let me know where you stand on my various responses.

Thank you

Bob

On 3/18/20 11:50 AM, Robert Moskowitz wrote:
> I have pushed out ver 17
>
> I believe with this I have done my best at answering all the AD 
> questions/comments.
>
> At least one open item on the octet encoding.
>
> Please review this version and my responses to Roman and Ben and let's 
> collect the last set of changes to wrap this up.
>
>
>
> On 3/9/20 4:00 PM, Robert Moskowitz wrote:
>>
>>
>> On 3/4/20 12:44 PM, Benjamin Kaduk via Datatracker wrote:
>>> Benjamin Kaduk 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 
>>> 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-dex/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> This is a placeholder discuss, intended to illustrate several key
>>> omissions from the current document and as an indication that it is not
>>> yet ready for full IESG Evaluation.  In that vein, I will defer the
>>> evaluation shortly, to attempt to short-circuit the current round of
>>> evaluation while the draft improves.  In particular, this is not
>>> intended to be a complete review of the document.
>>>
>>> The FOLD scheme for compressing full host identities into ORCHIDs/HITs
>>> is pretty problematic.  The current text acknowledges that collisions
>>> are possible and attempts to justify the scheme by pointing out that no
>>> collision-free scheme is possible absent a cryptographic hash, which is
>>> an appeal to authority ("we can't use a cryptographic hash on
>>> constrained systems") that does not attempt to answer the question of
>>> whether it is actually reasonable to use a mechanism that allows
>>> collisions for this purpose (vs. just not being able to do anything).
>>> Additionally, there is not any discussion of second-preimage 
>>> resistance,
>>> which is the more important property here, in terms of an attacker 
>>> being
>>> able to construct a collision with an existing HIT of an honest node.
>>
>> In my humble opinion, second-preimage attack defense will be the same 
>> as any attack against the HI -> HIT mapping function.
>>
>> The only place HITs are used in HIP unauthenticated is in the initial 
>> I1 - I2 part of the exchange.  By the R2, everything is 
>> authenticated.  All other HIP messages containing HITs are 
>> authenticated.
>>
>> So the attack is slipping in a HI-HIT mapping that is malicious. Per 
>> Roman's comments, I will be adding to the I2 and R2 processing to 
>> validate this mapping.
>>
>> HIP has always had to handle probabilistic collisions.  DEX now 
>> requires checking for collisions as critical (via ACLs or other 
>> mechanisms).  I will see to adding text.
>>
>> Operationally, the challenge is in those low level sensors that have 
>> no way to have an ACL set up for the servers/gateways that they are 
>> connected to.  But this is true even for BEX.  So inclusion of the 
>> password authentication is part of the critical behavior is ACL or 
>> similar HI-HIT mappings are not possible (sensors with no out-of-band 
>> update mechanism).  We are always twisting ourselves in the 
>> chicken-and-egg problem with these devices.
>>
>>> In a related vein, Section 3.2.1 claims that the above concerns can be
>>> remediated by deployment of a collision detection scheme, "achieved 
>>> here
>>> through either an ACL or some other lookup process".  This process is
>>> vital to the security of the system as a whole, and it would be
>>> irresponsible to publish this document without a precise specification
>>> of what properties are needed in order to perform this process, as well
>>> as a worked example that can be used absent other considerations.
>>
>> I will be adding this per Roman's comments.  Most will be in the I2 
>> and R2 processing.
>
> Done.  See 7.1
>
>>
>>
>>> Given that the applicability statement ("in communicating with such
>>> constrained devices") implies that there is intent to have 
>>> full-featured
>>> nodes that implement both HIP DEX and HIP BEX, I think we need
>>> significantly more discussion of how such nodes avoid using DEX in
>>> situations where it was not appropriate.  That is, how is it known that
>>> the peer should be using DEX vs. BEX?  Yes, the HIT includes an
>>> indication of whether the identity is for use with DEX vs. BEX, but 
>>> that
>>> does not seem like quite the relevant property.  Do we envision
>>> scenarios where a node is positioned somewhat like a gateway, using DEX
>>> on one interface and BEX to the broader internet?
>>
>>
>> Yes to the gateway situation.  Or the sensor has E2E DEX connection 
>> to the central server somewhere on the greater Internet.
>>
>> Perhaps text that limits DEX on non-constrained nodes for use with 
>> peers in the DEX ACL (or other equivalent control mechanism).
>
> See 7.1 and last sentence of 1.2
>
>>
>>> Using AES-CTR with the long-term static-static master key requires
>>> careful tracking of counter (sequence) number to nonvolatile 
>>> storage.  I
>>> did not see discussion of the security consequences of inadvertent
>>> counter reuse.
>>
>> I will look at this and see what I can add.
>
> See changes to 6.11 and last bullet point in Sec Considerations.
>
>>
>>> I appreciate the design to limit use of the long-term static-static
>>> master key to essentially just key-wrap operations, but this seems to
>>> require the presence of a CSPRNG in order to obtain secure session 
>>> keys.
>>> Expecting a strong CSPRNG on a node so constrained that DEX is 
>>> necessary
>>> seems to be a questionable assumption, and I see no discussion of the
>>> need for a good RNG.  (Relying on the full-featured peer to contribute
>>> good entropy to the key derivation is not an option, since DEX is
>>> allowed to be used between two nodes that are both constrained.)
>>
>> The current text is:
>>
>>    o  The strength of the keys for the Pair-wise Key SA is based on the
>>       quality of the random keying material generated by the Initiator
>>       and the Responder.  As either peer may be a sensor or an actuator
>>       device, there is a natural concern about the quality of its random
>>       number generator.
>>
>> Changed to:
>>
>>    o  The strength of the keys for both the Master and Pair-wise Key SAs
>>       is based on the quality of the random keying material generated by
>>       the Initiator and the Responder.  As either peer may be a sensor
>>       or an actuator device, there is a natural concern about the
>>       quality of its random number generator.  Thus at least a CSPRNG
>>       SHOULD be used.
>>
>>> The default KEYMAT algorithm uses the "CKDF" (CMAC-based KDF)
>>> construction, analogous to HKDF (RFC 5869).  However, the paper
>>> motivating 5869's design choices does not seem to justify the usage of
>>> CMAC instead of HMAC, since the proof requires a PRF* but CMAC (with
>>> AES) is only a PRP.  Absent some detailed justification or prior art it
>>> does not seem prudent to use such a novel construction for
>>> security-critical functionality.
>>
>> The CKDF design comes from NIST SP800-108.  I had extensive 
>> discussions with NIST and the 5869 authors at the DEX design time. 
>> These points were discussed and considered that CKDF is a prudent 
>> design.
>>
>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> Some additional comments (also incomplete), since they were already 
>>> written.
>>> It would be reasonable to ignore for now any that don't make sense or
>>> are on parts of the text likely to change as a result of the 
>>> higher-level discussion.
>>>
>>> Abstract
>>>
>>> My preference is to just use "forward secrecy" rather than "perfect
>>> forward secrecy", as perfection is hard to attain.
>>
>> I am all for that!  My Jewish Orthodox background makes me cringe at 
>> the use of PFS.  No such thing in this world (btw, I also cringe at 
>> the common use of "awesome")...
>>
>> If there is consensus to drop PFS from all IETF standards, I will 
>> replace "perfect forward secrecy" with "forward secrecy" and PFS with 
>> just the full verbiage as FS does not seem to be meaningful.
>
> It is too late in IETF usage to change.  We live with it.
>
>>
>>
>>> Section 1.1
>>>
>>>     HIP DEX operationally is very similar to HIP BEX. Moreover, the
>>>     employed model is also fairly equivalent to 802.11-2007
>>>     [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but
>>>     handled in a single exchange.
>>>
>>> 802.11 security does not exactly have a shiny track record...
>>
>> You want to see the "smoking gun" document on WEP design from Nov 
>> '94?  I have it.
>>
>> The point is the Master key and Pair-wise key design.  Not 
>> necessarily how they were constructed.  I also published the initial 
>> paper on the attack on WPA-PSK.
>>
>>>     HIP DEX does not have the option to encrypt the Host Identity of 
>>> the
>>>     Initiator in the I2 packet.  The Responder's Host Identity also is
>>>     not protected.  Thus, contrary to HIPv2, HIP DEX does not 
>>> provide for
>>>     end-point anonymity and any signaling (i.e., HOST_ID parameter
>>>     contained with an ENCRYPTED parameter) that indicates such 
>>> anonymity
>>>     should be ignored.
>>>
>>> What would you do if you didn't ignore such signalling?  Drop the
>>> connection as being with a misbehaving peer?
>>
>> Probably more like a ill thought-out implementation.  Right now I am 
>> of the opinion of leaving this as is.  But I can be convinced to add 
>> a drop connection.
>>
>>>     As in [RFC7401], data packets start to flow after the R2 
>>> packet.  The
>>>     I2 and R2 packets may carry a data payload in the future. The
>>>     details of this may be defined later.
>>>
>>> I'm not sure what value is added by mentioning the possibility of data
>>> payload in I2/R2.
>>
>> This is carried over from 5201.  There were ideas pointing how the 
>> 3-way TCP setup can become a 5-way HIP - TCPinESP setup. A few other 
>> were discussed in HIPRG, but no one has proposed to actually use this 
>> feature.  It stays for some future thinker to tinker with.
>>
>>
>>>     An existing HIP association can be updated with the update 
>>> mechanism
>>>     defined in [RFC7401].  Likewise, the association can be torn down
>>>     with the defined closing mechanism for HIPv2 if it is no longer
>>>     needed.  In doing so, HIP DEX omits the HIP_SIGNATURE parameters of
>>>     the original HIPv2 specification.
>>>
>>> I think the intent here is more along the lines of "HIP DEX does so 
>>> even
>>> in the absence of the HIP_SIGNATURE that is used in standard HIPv2".
>>> (I also note that there's some subtle semantic mismatch between DEX as
>>> "diet exchange" and its used to indicate continuing lack of security
>>> functionality throughout the extent of the association, after the
>>> exchange is completed.)
>>
>> Changed to:
>>
>>    An existing HIP association can be updated with the update mechanism
>>    defined in [RFC7401].  Likewise, the association can be torn down
>>    with the defined closing mechanism for HIPv2 if it is no longer
>>    needed.  In doing so, HIP DEX does so even in the absence of the
>>    HIP_SIGNATURE that is used in standard HIPv2.
>>
>>
>>>     Finally, HIP DEX is designed as an end-to-end authentication and 
>>> key
>>>     establishment protocol.  As such, it can be used in combination 
>>> with
>>>
>>> Don't we have a LAKE WG now?  How does DEX compare to what they are
>>> working on?
>>
>> I looked some more at LAKE.  They are proposing to use ephemeral DH 
>> as part of the exchange.  That goes counter to sec 1.2 of HIP-DEX. If 
>> they come up with an approach that performs "acceptably", then I will 
>> be looking at it.
>>
>>> Section 1.2
>>>
>>> In lieu of detailed comments, allow me to propose a rewrite of the 
>>> whole
>>> section:
>>>
>>> % HIP DEX achieves its lightweight nature in large part due to the
>>> % intentional removal of Forward Secrecy (FS) from the key 
>>> exchange.  Current
>>> % mechanisms to achieve FS use an authenticated ephemeral 
>>> Diffie-Hellman
>>> % exchange (e.g., SIGMA or PAKE).  HIP DEX targets usage on devices 
>>> where
>>> % even the most lightweight ECDH exchange is prohibitively expensive 
>>> for
>>> % recurring (ephemeral) use.  For example, experience with the 8-bit
>>> % 8051-based ZWAWVE ZW0500 microprocessor has shown that EC25519 
>>> keypair
>>> % generation exceeds 10 seconds and consumes significant energy (i.e.,
>>> % battery resources).  Even the ECDH multiplication for the HIP DEX
>>> % static-static key exchange takes 8-9 seconds, again with measurable
>>> % energy consumption.  This resource consumption is tolerable as a
>>> % one-time event during provisioning, but would render the protocol
>>> % unsuitable for use on these devices if it was required to be a
>>> % recurring part of the protocol.  For devices constrained in this
>>> % manner, a FS-enabled protocol will likely provide little gain.  The
>>> % resulting "FS" key, likely produced during device provisioning, would
>>> % typically end up being used for the remainder of the device's
>>> % lifetime.  With such a usage pattern, the inherent benefit of
>>> % ephemeral keys is not realized.  The security properties of such 
>>> usage
>>> % are very similar to those of using a statically provisioned symmetric
>>> % pre-shared key, in that there remains a single PSK in static storage
>>> % that is susceptible to exfiltration/compromise, and compromise of 
>>> that
>>> % key in effect compromises the entire protocol for that node. HIP DEX
>>> % achieves marginally better security properties by computing the
>>> % effective long-term PSK from a DH exchange, so that the provisioning
>>> % service is not required to be part of the risk surface due to also
>>> % possessing the PSK.
>>> %
>>> % Due to the substantially reduced security guarantees of HIP DEX
>>> % compared to HIP BEX, HIP DEX MUST only be used when at least one of
>>> % the two endpoints is a class 0 or 1 constrained device defined in
>>> % Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both 
>>> endpoints
>>> % are class 2 devices or unconstrained.
>>
>> I have accepted your text with one typo and some formatting.  Of 
>> course this text uses FS rather than PFS so that is a mis-match for now.
>>
>> 1.2.  Applicability
>>
>>    HIP DEX achieves its lightweight nature in large part due to the
>>    intentional removal of Forward Secrecy (FS) from the key exchange.
>>    Current mechanisms to achieve FS use an authenticated ephemeral
>>    Diffie-Hellman exchange (e.g., SIGMA or PAKE).  HIP DEX targets usage
>>    on devices where even the most lightweight ECDH exchange is
>>    prohibitively expensive for recurring (ephemeral) use.  For example,
>>    experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has
>>    shown that EC25519 keypair generation exceeds 10 seconds and consumes
>>    significant energy (i.e., battery resources).  Even the ECDH
>>    multiplication for the HIP DEX static-static key exchange takes 8-9
>>    seconds, again with measurable energy consumption.  This resource
>>    consumption is tolerable as a one-time event during provisioning, but
>>    would render the protocol unsuitable for use on these devices if it
>>    was required to be a recurring part of the protocol.  For devices
>>    constrained in this manner, a FS-enabled protocol will likely provide
>>    little gain.  The resulting "FS" key, likely produced during device
>>    provisioning, would typically end up being used for the remainder of
>>    the device's lifetime.
>>
>>    With such a usage pattern, the inherent benefit of ephemeral keys is
>>    not realized.  The security properties of such usage are very similar
>>    to those of using a statically provisioned symmetric pre-shared key,
>>    in that there remains a single PSK in static storage that is
>>    susceptible to exfiltration/compromise, and compromise of that key in
>>    effect compromises the entire protocol for that node.  HIP DEX
>>    achieves marginally better security properties by computing the
>>    effective long-term PSK from a DH exchange, so that the provisioning
>>    service is not required to be part of the risk surface due to also
>>    possessing the PSK.
>>
>>    Due to the substantially reduced security guarantees of HIP DEX
>>    compared to HIP BEX, HIP DEX MUST only be used when at least one of
>>    the two endpoints is a class 0 or 1 constrained device defined in
>>    Section 3 of [RFC7228]).  HIP DEX MUST NOT be used when both
>>    endpoints are class 2 devices or unconstrained.
>>
>>
>>> Section 2.2
>>>
>>>     Ltrunc (M(x), K)   denotes the lowest order K bits of the result of
>>>        the MAC function M on the input x.
>>>
>>> I'm not sure I'm going to interpret the "lowest order K bits" the same
>>> way that everyone else will.  I think "leftmost" or "first" are more
>>> common terms for describing this sort of truncation.
>>
>> This text goes back to 5201.  Implementors of 5201 did not have a 
>> problem with this, in fact probably one of them supplied the text. 
>> But I am open to change based on consensus.
>>
>>> Section 2.3
>>>
>>>     CMAC:  The Cipher-based Message Authentication Code with the 
>>> 128-bit
>>>        Advanced Encryption Standard (AES) defined in RFC 4493 
>>> [RFC4493].
>>>
>>> I would suggest just using CMAC as the acronym and not trying to
>>> overload it to also be AES-specific.
>>
>> Do you recommend I just reference SP800-38B?
>>
>>>     HIT Suite:  A HIT Suite groups all algorithms that are required to
>>>        generate and use an HI and its HIT.  In particular, these
>>>        algorithms are: 1) ECDH and 2) FOLD.
>>>
>>> For DEX.  For normal HIPv2 we wouldn't touch FOLD with a long pole.
>>
>> :)
>>
>>    HIT Suite:  A HIT Suite groups all algorithms that are required to
>>       generate and use an HI and its HIT.  In particular for HIP DEX,
>>       these algorithms are: 1) ECDH and 2) FOLD.
>>
>> BTW, I once DID use a 10' pole to chase a family of raccoons out of 
>> my garage.  Really, it WAS 10' long, I had just gotten it from the 
>> lumber yard.  Came home and there were a bunch of beady eyes in the 
>> garage..
>>
>>>     HI (Host Identity):  The static ECDH public key that represents the
>>>        identity of the host.  In HIP DEX, a host proves ownership of 
>>> the
>>>        private key belonging to its HI by creating a HIP_MAC with the
>>>        derived ECDH key (see Section 3).
>>>
>>> This may sound pedantic, but this doesn't actually prove ownership of
>>> the private key.  Someone who knows the private key of the other party
>>> and the public key of the host in question would be able to produce the
>>> same MAC from the corresponding derived ECDH key.  I think the most we
>>> can say here is that a host authenticates itself as that host identity
>>> [with that HIP_MAC].  There's the corresponding trust of the recipient
>>> that its own private key remains secure and thus that no party other
>>> than itself or the peer identity could have generated that message.
>>
>> I will think on this one.  See what verbiage helps.
>
> So I need to reference the proper HIP_MAC.  Initiator's private key in 
> I2 and Responder's in R2.
>
>    HI (Host Identity):  The static ECDH public key that represents the
>       identity of the host.  In HIP DEX, a host proves ownership of the
>       private key belonging to its HI by creating a HIP_MAC with the
>       derived ECDH key (see Section 3) in the appropriate I2 or R2
>       packet.
>
>
>>
>>>     Initiator:  The host that initiates the HIP DEX handshake.  This 
>>> role
>>>        is typically forgotten once the handshake is completed.
>>>
>>> "typically"?  Perhaps it's best to say that the role is not used or
>>> needed after the handshake is completed.
>>
>> I the HIP state machine, either peer can be the Initiator. Roles can 
>> be reversed.  If one party looses state, it can then become the 
>> Initiator regardless of what role it had in the original exchange.
>>
>> This is the text used in 7401.
>>
>>>     KEYMAT:  Keying material.  That is, the bit string(s) used as
>>>        cryptographic keys.
>>>
>>> I'm surprised we need an abbreviation for this.
>>
>> I got comments in early drafts of 5201-bis.  Put it in.  Take it 
>> out.  So for now, I leave it in.
>>
>>>     Length of the Responder's HIT Hash Algorithm (RHASH_len):  The
>>>        natural output length of RHASH in bits.
>>>
>>> [this doesn't really fit the pattern of "definition"s]
>>
>> It is in 7401.  If the AD says pull it.  It goes.
>>
>> Though perhaps the definition is of RHASH_len?
>
>    RHASH_len:  The natural length of the RHASH Algorithm in bits.
>
>
> But that really should be clear in its name.  I am leaving this in 
> unless someone says to pull it.
>
>>
>>>     Responder:  The host that responds to the Initiator in the HIP DEX
>>>        handshake.  This role is typically forgotten once the 
>>> handshake is
>>>        completed.
>>>
>>> [same thing re "typically"]
>>
>> Same response.
>>
>>> Section 3
>>>
>>>     HIP DEX implementations MUST support the Elliptic Curve Diffie-
>>>     Hellman (ECDH) [RFC6090] key exchange for generating the HI as
>>>     defined in Section 5.2.3.  No additional algorithms are 
>>> supported at
>>>     this time.
>>>
>>> It's kind of weird to see a "MUST" for "RFC6090 key exchange"; 6090
>>> discusses the general class of things but is not a specific key 
>>> exchange
>>> algorithm (e.g., curve).
>>> I'd also consider s/supported/defined/.
>>
>> Good point.  Changed to:
>>
>>    HIP DEX implementations use the Elliptic Curve Diffie-Hellman (ECDH)
>>    [RFC6090] key exchange for generating the HI as defined in
>>    Section 5.2.3.  No alternative algorithms are defined at this time.
>>
>>>     Due to the latter property, an attacker may be able to find a
>>>     collision with a HIT that is in use.  Hence, policy decisions 
>>> such as
>>>     access control MUST NOT be based solely on the HIT. Instead, the HI
>>>     of a host SHOULD be considered.
>>>
>>> I don't think this is correct or a strong enough statement. In
>>> particular, I don't think access control should be based on the HIT at
>>> all, so strike "solely".  Also, the "SHOULD" seems too week. I can
>>> understand that "MUST use the HI" could be overly constraining, but
>>> "access control decisions MUST be made on the actual identity of the
>>> host, e.g., the full HI" should allow for sufficient flexibility.
>>
>> I will see how this changes with the ACL additions.
>
> See sec 71. and this text changed to:
>
>    Due to the latter property, an attacker may be able to find a
>    collision with a HIT that is in use.  Hence, policy decisions such as
>    access control MUST NOT be based solely on the HIT.  Instead, the HI
>    of a host SHOULD be considered (see Section 7.1).
>
>
>>
>>>     Carrying HIs and HITs in the header of user data packets would
>>>     increase the overhead of packets.  Thus, it is not expected that
>>>
>>> s/and/or/?
>>
>> fixed.
>>
>>>     association.  When other user data packet formats are used, the
>>>     corresponding extensions need to define a replacement for the
>>>     ESP_TRANSFORM [RFC7402] parameter along with associated semantics,
>>>     but this procedure is outside the scope of this document.
>>>
>>> Why is ESP_TRANSFORM the most important parameter here, when we talk
>>> about mapping a packet to the HIP association?  I thought ESP_TRANSFORM
>>> was literally about the encryption mechanics, not metadata around it.
>>
>> Again, this goes back to 5201.  We are talking about ~20 years of 
>> discussions.
>>
>> We are discussing HIs and HITs, but that SPIs are used in everyday 
>> packets as the pointer to the HIs and HITs involved.  I will think on 
>> this, but it is down the list on things to change that were inherited 
>> from 5201.
>>
>>> Section 3.2
>>>
>>> ORCHID claims to provide statistical uniqueness and routability at some
>>> overlay layer, neither of which this FOLD procedure provides, due to
>>> easily-generatable second preimages.
>>>
>>> Section 3.2.1
>>>
>>>     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
>>>
>>> This is not an argument that this is a reasonable thing to do; it's
>>> merely an argument that it's a thing that can be done that has the same
>>> claimed properties as the only type of thing that could be done.  It
>>> might be a bad idea to do the only type of thing that can be done, and
>>> you have not convinced me otherwise.  (See also the distinction between
>>> collision-resistance and second-preimage-resistance alluded to in my
>>> comment on the previous section.)
>>
>> Other changes may help, or not.  We can rejoin this point after draft 
>> 14 (note I will be pushing out draft 13 today for the publish 
>> deadline for changes done so far).
>>
>>>     here through either an ACL or some other lookup process that
>>>     externally binds the HIT and HI.
>>>
>>> Without at least one well-specified mechanism for actually doing this
>>> and clear documentation of what precise properties such a mechanism
>>> needs to provide, I think it's irresponsible to publish this document.
>>
>> In the works.
>
> sec 7.1
>
>>
>>> Section 4.1
>>>
>>>     By definition, the system initiating a HIP Diet EXchange is the
>>>     Initiator, and the peer is the Responder.  This distinction is
>>>     typically forgotten once the handshake completes, and either party
>>>     can become the Initiator in future communications.
>>>
>>> ["typically" again]
>>
>> same response.
>>
>>>     Diffie-Hellman Group IDs supported by the Initiator.  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.  In such cases, another 
>>> mechanism to
>>>     convey the Initiator's supported DH Groups (e.g., by using a 
>>> default
>>>     group) must be specified.
>>>
>>> This seems under-specified for a proposed standard and is probably
>>> better off omitted entirely.
>>
>> This is carried over from 5201, which WAS experimental.  So I can see 
>> it as reasonable to drop this as no one proposed another mechanism.
>
> dropped.
>
>>
>>    The Initiator first sends a trigger packet, I1, to the Responder.
>>    This packet contains the HIT of the Initiator and the HIT of the
>>    Responder, if it is known.  Moreover, the I1 packet initializes the
>>    negotiation of the Diffie-Hellman group that is used for generating
>>    the Master Key SA.  Therefore, the I1 packet contains a list of
>>    Diffie-Hellman Group IDs supported by the Initiator.
>>
>>
>>>     The second packet, R1, starts the actual authenticated 
>>> Diffie-Hellman
>>>     key exchange.  It contains a puzzle - a cryptographic challenge 
>>> that
>>>     the Initiator must solve before continuing the exchange. The level
>>>     of difficulty of the puzzle can be adjusted based on level of trust
>>>     with the Initiator, current load, or other factors.  In 
>>> addition, the
>>>
>>> The Initiator is unauthenticated at this point, so "level of trust"
>>> seems to not really be defined...
>>
>> Changed to "knowledge of the".  If the Responder "knows" that the 
>> Initiator is a sensor, using a smaller puzzle may be preferred. there 
>> is discussion about large puzzles being an attack on sensors.
>>
>>> Section 4.1.1
>>>
>>> If an unconstrained (DoSing) attacker is competing with a constrained
>>> honest initiator to solve puzzles during an attack, it seems like the
>>> honest initiator is going to lose out pretty badly.
>>
>> You do what you can that makes some degree of sense.  You just don't 
>> walk away from the problem.
>>
>>> Section 4.1.4
>>>
>>> There are security considerations for serializing the HIP state to
>>> nonvolatile storage!
>>
>> Do you want text about this in the Securities Considerations?
>>