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 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:
--
(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.
** 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.
** 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.
** 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
