Hello again Benjamin: About your discuss below we published -18 that has text from Rene that removes the uncertainty on compression. Please have a look at https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18 and let us know if the diffs correct the issue properly.
Many thanks again Pascal > -----Original Message----- > From: Benjamin Kaduk via Datatracker <[email protected]> > Sent: samedi 1 février 2020 00:19 > To: The IESG <[email protected]> > Cc: [email protected]; Shwetha Bhandari (shwethab) > <[email protected]>; [email protected]; Shwetha Bhandari (shwethab) > <[email protected]>; [email protected] > Subject: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS > and COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-6lo-ap-nd-15: 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-6lo-ap-nd/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The CIPO description specifies that a 5-bit Reserved1 field and a 13-bit > Public > Key Length field are combined to fit into a 16 (not 18)-bit space. > (The Figure shows the Public Key Length field as 11 bits.) > > 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? > > Per my comment on Section 4.4, there may be some implicit > expectation/requirement of 128+-bit ROVRs for AP-ND, but I didn't find where > such a requirement was stated. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this well-written document! It will be good to see this stuff > getting > deployed. > > What's the risk of DoS via (short) address exhaustion in terms of 6LBR > resources (as distinct from 6LR resources mentioned at the end of Section > 7.1)? > > Section 1 > > In this specification, a 6LN generates a cryptographic ID (Crypto-ID) > and places it in the ROVR field during the registration of one (or > more) of its addresses with the 6LR(s). Proof of ownership of the > Crypto-ID is passed with the first registration exchange to a new > 6LR, and enforced at the 6LR. The 6LR validates ownership of the > cryptographic ID before it creates any new registration state, or > changes existing information. > > I'll read on and see, but how much trust does this imply that we require of > all > 6LRs (as opposed to the 6LBR, which is kind of required to be pretty trusted)? > [ed.: basically complete trust is required] > > The protected address registration protocol proposed in this document > enables Source Address Validation (SAVI) [RFC7039]. This ensures > that only the actual owner uses a registered address in the IPv6 > source address field. A 6LN can only use a 6LR for forwarding > packets only if it has previously registered the address used in the > source field of the IPv6 packet. > > nit: this last sentence is written as if we not only enable, but also > require, SAVI. > > The 6lo adaptation layer in [RFC4944] and [RFC6282] requires a device > to form its IPv6 addresses based on its Layer-2 address to enable a > better compression. This is incompatible with Secure Neighbor > Discovery (SeND) [RFC3971] and Cryptographically Generated Addresses > (CGAs) [RFC3972], since they derive the Interface ID (IID) in IPv6 > addresses with cryptographic keys. > > Are we going to have some further discussion of the scope of that loss of > functionality and/or alternative mechanisms to achieve those goals, or is this > statement just intended to note the incompatibility? > > Section 3 > > The proof requires the support of Elliptic Curve Cryptography (ECC) > and that of a hash function as detailed in Section 6.2. To enable > the verification of the proof, the registering node needs to supply > certain parameters including a Nonce and a signature that will > demonstrate that the node has the private-key corresponding to the > public-key used to build the Crypto-ID. > > nit: the proof itself may only indirectly involve a hash, since we use non- > prehash Ed25519 (but the hash function is still needed to generate the Crypto- > ID itself). > > nit(?): I think we tend to see "possesses the private key" more often than > "has > the private-key", for parallelism with the "proof of possession" term of art. > > 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 > > nit: this could be misread as saying that the Table is authoritative, not the > registry. > > 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... > > Section 4.2 > > nit: I confess I'm missing what compels us to produce a de novo definition of > the "Status" field (and Length field) as opposed to deferring to the RFC > 8505 definition, as we do for most of the other fields. > > Section 4.3 > > Crypto-Type: 8-bit unsigned integer. The type of cryptographic > algorithm used in calculation Crypto-ID (see Table 2 in > Section 8.3). Although the different signature schemes target > similar cryptographic strength, they rely on different curves, > hash functions, signature algorithms, and/or representation > conventions. > > While the currently-defined signature schemes target similar cryptographic > strength, do we need to imply that all future ones will also target a similar > strength (especially since Section 8.3 admits the possibility of "better > security")? > > Modifier: 8-bit unsigned integer. Set to an arbitrary value by the > creator of the Crypto-ID. The role of the modifier is to enable > the formation of multiple Crypto-IDs from a same key pair, which > reduces the traceability and thus improves the privacy of a > constrained node that could not maintain many key-pairs. > > It may be worth digging in a little further to the threat model being > addressed > here -- while I laud the ability to have multiple Crypto-IDs from a single > keypair, > it seems that the tracking-prevention this affords implies an attacker who can > observe Crypto-IDs, most likely at multiple points in the network. Are > Crypto- > IDs used for anything other than EAROs? I don't have a great sense for how > likely it is that an attacker in position to observe (a subset of) EAROs > would not > also be in a position to observe at least one associated CIPO, which includes > all > the information needed to generate the Crypto-ID other than the Modifier. > With only an 8-bit Modifier space, brute-forcing the other possible Crypto-IDs > for that keypair is not terribly strenuous, whereas allowing for a > (potentially > variable length?) larger Modifier, say 64 bits, would substantially increase > the > work-factor needed to predict (and store!) other Crypto-IDs that might be used > for this keypair. Given that the CIPO already carries the public key itself, > it's > not entirely clear how space-constrained we are so as to limit this to just > 8 bits of modifier. > > Padding: A variable-length field completing the Public Key field to > align to the next 8-bytes boundary. > > (MUST be set to zero by sender and ignored by receiver, as well?) > > The implementation of multiple hash functions in a constrained > devices may consume excessive amounts of program memory. > > But multiple signature algorithm implementations will not? > > Section 4.4 > > Is there some more discussion to have about how NDPSO includes only a > specific fixed set of information under the signature but RSAO signs all > options > that appear prior to it in the message? > > nit: style suggests parallelism between the Section 4.3 and 4.4 introductory > remarks (e.g., "this specification defines the NDP Signature Option (NDPSO)"). > > 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. The > hash that can be used as index is the 128 leftmost bits of the ROVR > field in the EARO. > > nit: this last sentence perhaps leaves more context implicit than the reader > might like; I suggest "Instead, the leftmost 128 bits of the ROVR field in the > sibling EARO are used to lookup the key used for signature verification, > [left- > padded with zeros if needed]". (I added the part in square brackets because > I'm not sure that anything guarantees the ROVR will actually contain > 128 bits -- when AP-ND is not in use its typically just 64 bits, right?) > > Pad Length: 8-bit unsigned integer. The length of the Padding > field. > > (In octets?) > > Padding: A variable-length field making the option length a multiple > of 8, containing as many octets as specified in the Pad Length > field. Typically there is no need of a padding and the field is > NULL. > > Just to check: nothing requires the use of minimal-length padding to achieve > the required alignment, and padding of 200+ bytes is permitted by the spec, > albeit silly? > > Section 6 > > This specification enables the 6LR to verify the ownership of the > binding at any time assuming that the "C" flag is set. The > verification prevents other nodes from stealing the address and > trying to attract traffic for that address or use it as their source > address. > > nit: I think that the verification cannot be done unilaterally by the 6LR, so > maybe "enables the 6LR to challenge the node to verify its ownership of the > binding at any time" is better. > > A node may use multiple IPv6 addresses at the same time. The node > MAY use the same Crypto-ID, to prove the ownership of multiple IPv6 > addresses. The separation of the address and the cryptographic > > nit: no comma > > material avoids the constrained device to compute multiple keys for > > nit: "avoids the need for" > > multiple addresses. The registration process allows the node to use > the same Crypto-ID for all of its addresses. > > nit(?): We could potentially mention again the ability to use different > Crypto- > IDs with a single keypair, though there's not any clear need to do so. > > Section 6.1 > > Mostly just for my own elucidation, where is it first specified to put the > address > being registered in the Target Address field of the NS message? > > detrimental to the battery lifetime. Alternatively, the device may > use an always-incrementing value saved in the same stable storage as > the key, so they are lost together, and starting at a best effort > random value, either as Nonce value or as a component to its > computation. > > nit: "as the Nonce value". > > and the NDPSO containing the signature. The information associated > to a Crypto-ID stored by the 6LR on the first NS exchange where it > appears. The 6LR MUST store the CIPO parameters associated with the > > nit: I think there's a verb missing in this sentence ("MUST be"?) > > |------- NS with EARO, CIPO, NonceLN and NDPSO -------->| > > (This still includes the Crypto-ID, even if there's not room in the figure to > explicition indicate that, right?) > > * Upon the first exchange with a 6LR, a 6LN will be challenged to > prove ownership of the Crypto-ID and the Target Address being > > How is the "first exchange" tracked? Just whether the 6LR knows about the > registered IPv6 address, or the L2 address, or something else? In > particular, if a > 6LR has cached an IP address/ROVR binding, and an attacker tries to join that > 6LR with that address/ROVR, what controls whether the 6LR will challenge the > attacker's 6LN? Is it purely at the 6LR's discretion? > > * The challenge is triggered when the registration for a Source > Link-Layer Address is not verifiable either at the 6LR or the > 6LBR. In the latter case, the 6LBR returns a status of > "Validation Requested" in the DAR/DAC exchange, which is echoed by > the 6LR in the NA (EARO) back to the registering node. The > challenge MUST NOT alter a valid registration in the 6LR or the > 6LBR. > > nit(?): the previous bullet describes a case where the 6LR MUST issue a > challenge; my understanding is that this bullet describes an additional way in > which challenges can occur (i.e., when the 6LBR doesn't know about the > address registration either). Stylistically, it might be more clear to > reword this > as being an "additional case" on top of the previous one, as opposed to the > current wording which tries to be very general about when a challenge can > happen, which is neither a parallel construction to the previous bullet nor > particularly clear about what new information is being conveyed by this > bullet. > > * In order to validate the ownership, the 6LR performs the same > steps as the 6LN and rebuilds the Crypto-ID based on the > parameters in the CIPO. If the rebuilt Crypto-ID matches the > ROVR, the 6LN also verifies the signature contained in the NDPSO > option. If at that point the signature in the NDPSO option can be > verified, then the validation succeeds. Otherwise the validation > fails. > > I worry a little bit that we haven't fully specified the entire list of steps > the 6LR > takes to follow the cryptographic chain and validate that the 6LN holds the > key > in question and registers the address in question to the Crypto-ID in > question. I > don't have a specific thing in mind that the 6LR might forget, but if we > explicitly state what things are bound to what other things, the 6LR is less > likely > to make a security-relevant mistake. > > Section 6.2 > > Might we want to include the Modifier or the Crypto-ID itself in the signed > data, in addition to the public key, to avoid any potential misbinding? > > 2. JWK-encoded public key > > [just to check: JWK-encoding means that we have an injective map and aren't > subject to some sort of extension attack? Not that such a thing would be easy > to pull off, with a strict registry of Crypto-Types, of course] > > 6. The length of the ROVR field in the NS message containing the > Crypto-ID that was sent. > > nit: is this really the NS "that was sent" as opposed to the NS under > construction that contains the NDPSO? (This is related to my question up in > Section 6.1.) Tying the initial NS to the followup one requires more state on > the 6LR (though the 6LR probably already had to keep state for the Nonce) and > makes some of the verification steps a bit tougher to implement correctly. > > 7. 1-byte (in network byte order) Crypto-Type value sent in the CIPO > option. > > nit: Is there any byte order with distinct representation from network byte > order, for a 1-byte quantity? ;) > > * Depending on the Crypto-Type, apply the hash function on this > concatenation. > > nit: is this clearer as "Apply the hash function (if any) specified by the > Crypto- > Type to the concatenated data"? > > * Depending on the Crypto-Type, sign the hash output with ECDSA (if > curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519 > (PureEdDSA)). > > nit: this text is not very consistent with the idea of an extensible registry > of > Crypto-Types; similar "apply the signature algorithm specified by the Crypto- > Type" language to what I suggested above may be appropriate. > > 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. > > * Depending on the Crypto-Type indicated by the (6LN) in the CIPO, > apply the hash function on this concatenation. > > [similar comment as above] > > * Verify the signature with the public-key received and the locally > computed values. If the verification succeeds, the 6LR and 6LBR > add the state information about the Crypto-ID, public-key and > Target Address being registered to their database. > > This might be a place to reiterate the FCFS nature of address registration, > though it's hardly necessary. > > Section 6.3 > > In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and > the 6LR receives and relays them to the nodes. 6LR and 6LBR > communicate using ICMPv6 Duplicate Address Request (DAR) and > Duplicate Address Confirmation (DAC) messages. The DAR and DAC use > the same message format as NS and NA, but have different ICMPv6 type > values. > > In AP-ND we extend DAR/DAC messages to carry cryptographically > generated ROVR. In a multihop 6LoWPAN, the node exchanges the > messages shown in Figure 6. The 6LBR must identify who owns an > address (EUI-64) to defend it, if there is an attacker on another > 6LR. > > This description feels a little vague to me -- I'm interested in knowing how > the > 6LBR gains confidence that a proof-of-possession was provided to the 6LR, and > how the ROVR gets validated at 6LBR and 6LR when the 6LN in question moves > to a new 6LR. What information remains local to (each) 6LR and what is > communicated between 6LR and 6LBR? > This also relates to the "how trusted are 6LRs?" question I mentioned earlier. > > Section 7 > > It might be appropriate to talk about how the NonceLR and NonceLN combine > to ensure contributory behavior from both 6LR and 6LN, and that each protects > against a different type of replay attack. > > Section 7.1 > > Duplicate Address Detection DoS Attack: Inside the LLN, Duplicate > Addresses are sorted out using the ROVR, which differentiates it > from a movement. DAD coming from the backbone are not forwarded > over the LLN, which provides some protection against DoS attacks > inside the resource-constrained part of the network. Over the > backbone, the EARO option is present in NS/NA messages. This > protects against misinterpreting a movement for a duplication, and > enables the backbone routers to determine which one has the > freshest registration and is thus the best candidate to validate > the registration for the device attached to it. But this > specification does not guarantee that the backbone router claiming > an address over the backbone is not an attacker. > > Where do we specify the behavior of the 6LBR to reject EAROs when the 6LBR > is not the one with the freshest registration? Or do I misunderstand the > discussion of "freshest registration"? > > Replay Attacks Using Nonces (NonceLR and NonceLN) generated by both > the 6LR and 6LN provides an efficient protection against replay > attacks of challenge response flow. The quality of the protection > still depends on the quality of the Nonce, in particular of a > random generator if they are computed that way. > > It's probably worth noting explicitly that we do not require unpredictable > nonces, just non-repeating ones. > > Neighbor Discovery DoS Attack: A rogue node that managed to access > the L2 network may form many addresses and register them using AP- > ND. The perimeter of the attack is all the 6LRs in range of the > attacker. The 6LR MUST protect itself against overflows and > reject excessive registration with a status 2 "Neighbor Cache > Full". This effectively blocks another (honest) 6LN from > registering to the same 6LR, but the 6LN may register to other > 6LRs that are in its range but not in that of the rogue. > > Are there L2 technologies where L2 media keys are tied to L2 address, so a > rogue node might be rate-limited or given a quota based on L2 address? > > Section 7.2 > > address. This specification frees the device to form its addresses > in any fashion, thereby enabling not only 6LoWPAN compression which > derives IPv6 addresses from Layer-2 addresses but also privacy > addresses. > > We noted in Section 1 that the 6lo adaptation layer requires use of > L2-address- > based IPv6 address selection, so it's not clear how it would be valid to use > privacy addresses with this specification. > > Section 7.3 > > We seem to be assuming for these calculations/discussion that the hash used > for calculating the Crypto-ID is a well-behaved cryptographic hash and thus > that random collisions are the only ones possible. It would be worth > mentioning that weaknesses in the hashes associated with a given Crypto-Type > could allow attackers to make more targetted collision attempts. > > The formula for calculating the probability of a collision is 1 - > e^{-k^2/(2n)} where n is the maximum population size (2^64 here, > 1.84E19) and K is the actual population (number of nodes). If the > > nit: minuscule vs. majuscule 'k'/'K' > > Section 7.4 > > The signature schemes referenced in this specification comply with > NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards > [RFC8032] and offer strong algorithmic security at roughly 128-bit > security level. These signature schemes use elliptic curves that > > Do we want to make any forward-looking statement about the expected > strength of future-defined Crypto-Types? ("No" is a fine answer...) > > Section 7.5 > > The text here is more about cross-algorithm attacks than cross-protocol ones. > It would be great to see some text about cross-protocol attacks added, too > (e.g., prohibiting use of the keypair for anything other than AP-ND). > > Section 7.6 > > This specification distributes the challenge and its validation at > the edge of the network, between the 6LN and its 6LR. The central > 6LBR is offloaded, which avoids DOS attacks targeted at that central > entity. This also saves back and forth exchanges across a > > nit: "the central 6LBR is offloaded" reads very oddly, as the offloading is of > work from the 6LBR, but the 6LBR itself remains in place. > > The downside is that the 6LBR needs to trust the 6LR for performing > the checking adequately, and the communication between the 6LR and > the 6LBR must be protected to avoid tempering with the result of the > test. > > I'd prefer to see some more details about the nature of the required > protection > for 6LR/6LBR communications. > > If a 6LR is compromised, it may pretend that it owns any address and > defeat the protection. It may also admit any rogue and let it take > ownership of any address in the network, provided that the 6LR knows > the ROVR field used by the real owner of the address. > > nit: this language could probably be tightened up to be more precise about the > hazards. > > Section 8.3 > > New Crypto-Type values providing similar or better security (with > less code) may be defined in the future. > > I'm not sure what purpose the "with less code" requirement serves. It seems > to needlessly constrain future actions. > > Section 11 > > Curve25519 support is a MAY, so I think RFC 7748 belongs as normative; > likewise for RFCs 8032 and 6234. > > It's probably better to cite RFC 7696 as BCP 201 directly. > > Section B.3 > > It would be great if the document shepherd could diff the paramters listed > here > against [CURVE-REPRESENTATIONS]. > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
