This was truncated when I received the echo, retrying... > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: mardi 4 février 2020 15:14 > To: Benjamin Kaduk <[email protected]> > Cc: The IESG <[email protected]>; [email protected]; Shwetha > Bhandari (shwethab) <[email protected]>; [email protected]; > [email protected] > Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with > DISCUSS and COMMENT) > > Hello Benjamin > > Whao, that was quick. Many thanks again! > > I got a comment on the change to BCP201 and looked it up. Seems there was > a confusion, BCP 201 is RFC 7696 not RFC 7748. So I rolled back the > overload. Did you expect something else? > > I'm publishing 17 for the delta below, we still have the 3 open points. Please > check the diffs at https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd- > 17.txt > > More below: > > > > Why do we need to allow ambiguity/flexibility as to the point > > representation > > > > within a given Crypto-Type value (as opposed to fixing the > > > > representation > > as a > > > > parameter of the Crypto-Type)? Alternately, what does > > "(un)compressed" > > > > mean, as it's not really clarified directly? Furthermore, Table 2 > > > > lists an "(un)compressed" representation for type 0 (over P-256), > > > > but RFC 7518 > > notes > > > > that the compressed representation is not supported for P-256 > > > > (Section 6.2.1.1). I also am not finding the needed codepoints > > > > registered in the > > JOSE > > > > registries to use ECDSA25519 (crypto-type 2) -- do we need to > > > > register anything there? > > > > > > Let us take this one separately in a thread with the co authors > > I keep this item in the thread, to track that it's progressing separately > > > > > Clarifying questions: > > > - This spec is authoritative for listing the elliptic curves and the > > > hash > > functions that it supports, correct? > > > - The registry is authoritative for the setting of values, which may > > > change if > > this draft is obsoleted, is that your point? > > > > I think we have different interpretations. > > I was assuming (based more on general practices than the specific text > > in this document, to be clear) that the idea is that new Crypto-Types > > could be specified and added to the registry, and implementations > > incorporate them, without needing to revise or update this > > specification: the registered Crypto-Type would contain all the > > information needed to integrate with the mechanisms specified here. > > In that mindset, any list of algorithms in this document becomes out > > of date once the first additional Crypto-Type is registered, and the > > question of what algorithms the specification supports is more open-ended > than just the literal words on the page. > > Makes sense to me > > > > > From there I'm unsure what to do. The goal is to keep the focus on > > > the bill > > of material of what needs to be implemented. > > > If that helps I can add (values to be confirmed by IANA) as follows? > > > > > > " The elliptic curves and the hash functions that can be used with this > > > specification are listed in Table 2 in Section 8.3. The signature > > > scheme that specifies which combination is used is signaled by a > > > Crypto-Type (values to be confirmed by IANA) in a new IPv6 ND Crypto- > > > ID Parameters Option (CIPO, see Section 4.3) that contains the > > > parameters that are necessary for the proof, a Nonce option > > > ([RFC3971]) and a NDP Signature option (Section 4.4). > > > " > > > > To make a more concrete question: suppose I wanted to use > SHAKE256/256 > > as a hash function paired with ECDSA on curve25519. What would need > > to happen to enable that? The text above implies that, since > > SHAKE256/256 is not listed in the table, it's not allowed for use with > > this specification, and thus that I'd need to Update this > > specification in order to allow its use. > > The registry has "Specification Required" or "IESG Approval". The "IESG > Approval" path is for the case where the IES approves using the new hash > with the draft as is. > So yes, the spirit is that if the IESG determines that your case can happen > without a change in the spec, the registry could be extended and the spec > applied. > In that context, how does the following work: > > " > The elliptic curves and the hash functions listed in Table 2 in > Section 8.3 can be used with this specification; more may be added in > the future to the IANA registry. The signature scheme that specifies > which combination is used (including the curve and the representation > conventions) is signaled by a Crypto-Type in a new IPv6 ND Crypto-ID > Parameters Option (CIPO, see Section 4.3) that contains the > parameters that are necessary for the proof, a Nonce option > ([RFC3971]) and a NDP Signature option (Section 4.4). The NA(EARO) > is modified to enable a challenge and transport a Nonce option. > " > > Note that this incorporate text to cover the discussion between Rene and Jim > that different representation conventions imply different crypto-ids and > cannot reuse the same keypair > > > > > > > > > > Section 4.1 > > > > > > > > The Crypto-ID is derived from the public key and a modifier as > > > > follows: > > > > > > > > 1. The hash function indicated by the Crypto-Type is applied to the > > > > CIPO. Note that all the reserved and padding bits MUST be set to > > > > zero. > > > > 2. The leftmost bits of the resulting hash, up to the size of the > > > > ROVR field, are used as the Crypto-ID. > > > > > > > > This construction seems to allow for some malleability, in that an > > attacker who > > > > observes a given Crypto-ID and CIPO could produce a related, > > > > valid, > > Crypto-ID > > > > by reducing the ROVR length and truncating what was received. I > > > > haven't attempted to explore what (if any) potential consequences > > > > there are of > > such > > > > malleability, and would like to know if anyone else has already done so. > > It > > > > looks like the NDPSO construction includes the length of the > > > > Crypto-ID, > > so it > > > > would be hard for an attacker to do much with such a truncated > > > > Crypto- > > ID, but > > > > attacks only get better... > > > > > > The point is that the Crypto-ID remains in the 6LBR is its original > > > form, size > > and value. A shorted Crypto-ID is a different Crypto-ID even if bits match. > > Truncated per se does not help vs. any other change. > > > Also, the attacker would have to be on path of the initial > > > registration. If > > that is so, and it wants to update the ROVR, it can do that a lot more. > > > Now, the crypto-ID dictates the size of the ROVR not the other way > > around, so I fixed: > > > " > > > The leftmost bits of the resulting hash, up to the desired size, are > > > used as > > the Crypto-ID. > > > " > > > Anything else I should consider doing? > > > > The only other thing I would *consider* doing (which is not to say > > that it's clear it should be done) is to include the desired size as > > input to the hash. But I don't have any specific reason to do that or > > attack that would be stymied by doing so. > > > > With RFC 8505 the 6LN decides the parameters of the registration without an > indication from the router. So at the moment I cannot figure how to do that > apart from config. We are missing a mechanism to signal the expected > format of the ROVR and other parameters such as recommended lifetimes > for types of addresses, etc..., in the RA messages. That's also in the long > term plan and I'm considering whether to do that at 6lo or 6MAN. 6MAN > would be better but it is slow/reluctant to adopt RFC 8505 for general > purpose. > > > > > The implementation of multiple hash functions in a constrained > > > > devices may consume excessive amounts of program memory. > > > > > > > > But multiple signature algorithm implementations will not? > > > > > > draft-ietf-lwig-curve-representations discussed in the next section > > > enables > > to factorize code, if I understand well. > > > But to your point, what about the following clarification: > > > > > > " > > > The implementation of multiple hash functions in a constrained > > > devices may consume excessive amounts of program memory. This > > > specification enables the use of SHA-256 [RFC6234] for all the > > > supported ECC curves. > > > > Hmm, but Table 2 lists SHA-512 (not SHA-256) for crypto-type 1 (though > > I guess type 2 is SHA-256 on the same curve). > > Yes, I understand that type 2 is less classical but enables the reuse of the > SHA > 256 hash. > I defer to Rene on this. > > > > Per your comment we recommend 128 bits minimum. Keeping it at 64 > > > bits > > was not the intention. > > > Not sure why you meant by sibling; the text would become > > > > > > " > > > As opposed to the RSA Signature Option (RSAO) defined in section 5..2. > > > of SEND [RFC3971], the NDPSO does not have a key hash field. > > > Instead, the leftmost 128 bits of the ROVR field in the EARO are used > > > to retrieve the CIPO that contains the key material used for signature > > > verification, left-padded if needed. > > > > > > " > > > > I think "sibling" was intended to be the case when the EARO and the > > CIPO appear in the same NS as "sibling options" within the NS. > > (Though as you note the CIPO could have been previously received in a > > different message.) This text is probably okay, though I guess the > > reader has to know that there's an EARO associated with the NDPSO. > > > > You right, does not hurt to be more specific. In section 4.4: > > " > An ND message that carries an NDPSO MUST have one and only one EARO. > The EARO MUST contain a Crypto-ID in the ROVR field, and the Crypto- > ID MUST be associated with the keypair used for the Digital Signature > in the NDPSO. > > " > > > > > > > > > > The 6LR on receiving the NDPSO and CIPO options first regenerates > the > > > > Crypto-ID based on the CIPO option to make sure that the leftmost > > > > bits up to the size of the ROVR match. If and only if the > > > > check is > > > > > > > > In the vein of my previous questions about where the Crypto-ID > > > > appears > > and > > > > truncation/malleability, this text seems to leave some room for > > confusion > > > > about how many bits of output are being compared, and compared to > > what. > > > > > > I'm unsure what you mean here. Based on my response above, can you > > please reopen is needed, with some clarification? > > > > I was trying to get at how the NDPSO includes the Crypto-ID length in > > the signed data, but the 6LR has to determine what length to use from > > the length of the ROVR in the NS. This is in general not terribly > > interesting since an on-path attacker could change "anything" that > > would be input to the signature validation, but seemed a little more > > interesting to me because of the way that an attacker could truncate > > the Crypto-ID, and the truncation would not be directly detectable in > > the EARO/ROVR but would only be detected during signature validation. > > That is, the 6LR would replicate the Crypto-ID calculation from the > > CIPO, and the Crypto-ID would *appear* to match up, but the signature > > in the NDPSO would fail to validate. I have in general a preference > > to make the reason for failure apparent closer to the error, if > > possible, but in this specific case the system as a whole seems to > > work okay even though the error is detected "one step later" than it > > could be. (Adding the target output length into the hash input for > > Crypto-ID calculation as I mentioned above as an option would make > > this error detected at the first possible point, when validating the > > Crypto-ID > > calculation.) > > This could be achieved by placing the length of the ROVR in the CIPO. Making > this change. > We already had the ROVR size in the signature. Note that in the signature the > format of that size is not given. Would need 2 bytes if expressed in bytes. > I'd reword to use the option length of the EARO, which is expressed in units > of 8 bytes and is stored in one octet. > Works? > > This leads to sparse changes, but mostly: > > > > > " > > > The signature generated by the 6LN to provide proof-of-ownership of > the private-key is carried in the NDP Signature Option (NDPSO). It > is generated by the 6LN in a fashion that depends on the Crypto-Type > (see Table 2 in Section 8.3) chosen by the 6LN as follows: > > * Concatenate the following in the order listed: > > 1. The 128-bit Message Type tag [RFC3972] (in network byte order). > For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415 > f148 84d0. (The tag value has been generated by the editor of > this specification on random.org). > > <snip> > > 6. 1-byte Option Length of the EARO containing the Crypto-ID. > 7. 1-byte Crypto-Type value sent in the CIPO. > > <snap> > > The 6LR on receiving the NDPSO and CIPO options first checks that the > EARO Length in the CIPO matches the length of the EARO. If so it > regenerates the Crypto-ID based on the CIPO to make sure that the > leftmost bits up to the size of the ROVR match. > > If and only if the check is successful, it tries to verify the > signature in the NDPSO option using the following: > > * Concatenate the following in the order listed: > > 1. 128-bit type tag (in network byte order) > > <snoop> > > 6. 1-byte EARO Length received in the CIPO. > 7. 1-byte Crypto-Type value received in the CIPO. > > " > > > > > > > Perhaps it goes without saying (as part of DAD), but the 6LBR has to > > consult its database of ROVR/IP address to determine what response to > > give in the DAC. Part of my question above was about what state the > > 6LBR needs and what verification the 6LBR does as part of the process > > -- am I correct that it's just checking whether (1) the requested > > address is already registered and (if so) (2) that the ROVR in the > > EARO matches the one registered with the requested address? > > Yes, per RFC 8505, inherited from RFC 6775. I'd say that DAD expressed as > you did is the core function of RFC 6775. > This draft does not really change the 6LBR, just adds the capability to > stimulate a revalidation by the 6LR. > > > > > > > > All together we get: > > > " > > > Replay Attacks Using Nonces (NonceLR and NonceLN) generated by > both > > > the 6LR and 6LN ensure a contributory behavior that provides an > > > efficient protection against replay attacks of the challenge/ > > > response flow. A nonce should never repeat for a same key. The > > > protection depends on the quality of the Nonce computation, e.g.., > > > of a random number generator when used to compute the Nonce. > > > " > > > > I'd consider "A nonce should never repeat for a single key, but nonces > > do not need to be unpredictable for secure operation". > > > Which leads to: > " > > Replay Attacks A nonce should never repeat for a single key, but > nonces do not need to be unpredictable for secure operation. > Using nonces (NonceLR and NonceLN) generated by both the 6LR and > 6LN ensure a contributory behavior that provides an efficient > protection against replay attacks of the challenge/response flow. > The quality of the protection by a random nonce depends on the > random number generator and its parameters (e.g., sense of time). > " > > > > > > > > Twisted the text to > > > " > > > With this specification the 6LN can freely form its IPv6 address(es) > > > in any fashion, thereby enabling either 6LoWPAN compression for IPv6 > > > addresses that are derived from Layer-2 addresses, or temporary > > > addresses, e.g., formed pseudo-randomly and released in relatively > > > short cycles for privacy reasons [RFC8064][RFC8065], that cannot be > > > compressed. > > > > > > " > > > > This text is good. I would suggest changing the Section-1 text, > > though, as the current "requires a device [...] to enable a better > > compression" reads as if the requirement is always present, and that > > the reason for the requirement is to get the compression; instead, the > > situation is (IIUC) that in order to get that compression, the node is > > required to choose its address based on the L2 address. > > > Which gives > > " > With the 6lo adaptation layer in [RFC4944] and [RFC6282], a 6LN can > obtain a better compression for an IPv6 address with an Interface ID > (IID) that is derived from a Layer-2 address. As a side note, this > is incompatible with Secure Neighbor Discovery (SeND) [RFC3971] and > Cryptographically Generated Addresses (CGAs) [RFC3972], since they > derive the IID from cryptographic keys, whereas this specification > separates the IID and the key material. > " > > > > > > > > Text in the main spec has > > > " > > > The assumption is that the 6LR and the 6LBR maintain a security > > association, so there is no need to propagate the proof of ownership > > to the 6LBR. > > > " > > > But I'm not aware of people using anything beyond Layer-2 security. > > > The > > EDAR/EDAC are unicast ICMPv6 messages; what would be your > > recommendation to protect them at L3? > > > > At L3? I don't know of much other than IPsec (or some tunneling solution). > > But by "details" I meant more about whether confidentiality protection > > is required or "merely" integrity protection and source-authentication. > > In this case the merely is enough. The EDAR has the ROVR and the registered > address. Those will appear later in ND flows anyway. > In the main text, : > > " > The assumption is that the 6LR and the 6LBR maintain a security > association to authenticate and protect the integrity of the EDAR and > EDAC messages, so there is no need to propagate the proof of > ownership to the 6LBR. The 6LBR implicitly trusts that the 6LR > performs the verification when the 6LBR requires it, and if there is > no further exchange from the 6LR to remove the state, that the > verification succeeded. > " > > Many more thanks! > > Pascal
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
