Hi Luigi! Thanks for publishing -28/-29. It addresses my feedback per our discussion below. I've cleared my ballot.
Roman > -----Original Message----- > From: iesg <[email protected]> On Behalf Of Roman Danyliw > Sent: Wednesday, June 29, 2022 4:35 PM > To: Luigi Iannone <[email protected]> > Cc: The IESG <[email protected]>; [email protected]; > [email protected]; > [email protected] > Subject: RE: Roman Danyliw's Discuss on draft-ietf-lisp-sec-27: (with DISCUSS > and COMMENT) > > Hi Luigi! > > Thanks for the quick response. To your direct question, yes, the proposed > edits > described below address my feedback. > > Roman > > > -----Original Message----- > > From: Luigi Iannone <[email protected]> > > Sent: Wednesday, June 29, 2022 7:42 AM > > To: Roman Danyliw <[email protected]> > > Cc: The IESG <[email protected]>; [email protected]; > > [email protected]; [email protected] > > Subject: Re: Roman Danyliw's Discuss on draft-ietf-lisp-sec-27: (with > > DISCUSS and COMMENT) > > > > Hi Roman, > > > > Thank you very much for your review. > > > > A few proposed changes inline. > > > > > On 29 Jun 2022, at 03:47, Roman Danyliw via Datatracker > > > <[email protected]> > > wrote: > > > > > > Roman Danyliw has entered the following ballot position for > > > draft-ietf-lisp-sec-27: 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/about/groups/iesg/statements/handling-ballot-po > > > si tions/ for more information about how to handle DISCUSS and > > > COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > ** Since originally scheduled for the telechat in version -26, thank > > > you for adding the following text about preferring HMAC-SHA256 for > > > new deployments in > > > -27: > > > > > > The HMAC > > > function AUTH-HMAC-SHA-256-128 [RFC6234] MUST be supported in > LISP- > > > SEC implementations. LISP-SEC deployments SHOULD use AUTH-HMAC- > > SHA- > > > 256-128 HMAC function, unless older implementations using AUTH- > HMAC- > > > SHA-1-96 are present in the same deployment [RFC2104]. > > > > > > Could this same approach be applied for the algorithms set by KDF ID. > > > Specifically: > > > > > > -- Section 6.9 says: > > > > > > The key derivation function > > > HKDF-SHA1-128 [RFC5869] MUST be supported. > > > ... > > > However, since HKDF-SHA1-128 is mandatory to implement, the process > > > will eventually converge. > > > > > > Could it say something to the effect of: > > > > > > The key derivation function HKDF-SHA256 MUST be supported in > > > LISP-SEC implementations. LISP-SEC deployments SHOULD use the > > > HKDF-SHA256 > > HKDF > > > function, unless older implementations using HKDF-SHA1-128 are > > > present in the same deployment. > > > > > > However, since HKDF-SHA1-128 and HKDF-SHA256 are supported, the > > > process will eventually converge. > > > > Yes, good idea. THe text makes sense and makes LISP-Sec even more robust. > > > > > > > > > > -- Section 8.5. Add HKDF-SHA256 to the "LISP-SEC Authentication Data Key > > > Derivation Function ID" registry > > > > > > > Yep. > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > Thank you to Alexey Melnikov for the SECDIR review. > > > > > > ** Section 4. > > > In this > > > way the ETR can maliciously redirect traffic directed to a large > > > number of hosts. > > > > > > Does the number of impact host matter so much as the generic ability > > > to redirect traffic? I’m imagining that a “surgical” or targeted > > > attack might be equally interesting – for example, if there was a > > > particular services on a given prefix that an attacker wanted to redirect. > > > > You are right. It works both ways. > > The text can simply state: “… the ETR can maliciously redirect traffic." > > > > > > > > > > ** Section 5. > > > > > > Those trust relationships are used to securely > > > distribute, as described in Section 8.4, ... > > > > > > Is Section 8.4, really the right reference here? > > > > > > ** Section 6.5 > > > Implementations of this specification MUST support OTK Wrapping ID > > > AES-KEY-WRAP-128+HKDF-SHA256 that specifies the use of the HKDF- > > > SHA256 Key Derivation Function specified in [RFC4868] > > > > > > RFC4868 doesn’t define a HKDF with SHA256. Do you mean RFC5869? > > > Same issue in Section 8.4 (IANA table) > > > > Will be replaced. > > > > > > > > ** Section 6.5 > > > 4. The per-message encryption key is computed as: > > > > > > * per-msg-key = KDF( nonce + s + PSK[Key ID] ) > > > where the nonce is the value in the Nonce field of the Map- > > > Request, 's' is the string "OTK-Key-Wrap", and the operation'+' > > > just indicates string concatenation. > > > > > > HKDFs typically take one more input, L, the output size. Since this > > > is tied to a particular key wrap the options are more constrained. > > > AES-KEY-WRAP-128 can have both a 128-bit and 192-bit KEK, please > > > explicitly state the expected output size. > > > > > > 128 bits is the expected output size. > > > > > > > > ** Section 7.4 > > > > > > As an example, in certain closed and controlled deployments, it is > > > possible that the threat associated with an on-path attacker between > > > the xTR and the Mapping System is very low, and after careful > > > consideration it may be decided to allow a NULL key wrapping > > > algorithm while carrying the OTKs between the xTR and the Mapping > > > System. > > > > > > > > > > Wouldn’t this violate: > > > -- Section 6.4, “ITR-OTK confidentiality and integrity protection > > > MUST be provided in the path between the ITR and the Map-Resolver” > > > > > > -- Section 6.4, “If the NULL-KEY-WRAP-128 algorithm (see Section > > > 8.4) is selected and no other encryption mechanism (e.g. DTLS) is > > > enabled, in the path between the ITR and the Map-Resolver, the > > > Map-Request MUST be dropped and an appropriate log action SHOULD be > taken” > > > > > > -- Section 6.5, “MS-OTK confidentiality and integrity protection MUST be > > > provided in the path between the Map-Server and the ETR.” > > > > > > > Yes it would. The text in section 7.4 needs to be changed, actually > > dropping altogether the paragraph you are citing. > > > > > > > ** Section 7.7. Recommend adding that when DTLS is used it > > > confirmed to RFC7525, or even better would be draft-ietf-uta-rfc7525bis. > > > > Will be updated > > > > > > > > ** Editorial > > > -- Section 6.2. Typo. s/authetification/authentication/ > > > > > > -- Section 6.3. Typo. s/Extentions/Extensions/ > > > > > > > > > > > > > Thanks will be fixed. > > > > Do the above proposed changes address your comments? > > > > Ciao > > > > L. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
