Firstly the name of the draft is bit misleading, as this defines both curve25519 and Curve448 keys not only curve25519.
This document is bit confusing as some of the values are defined as "strings of 32 octets", some are defined as 255/448-bit numbers having certain properties (high bit set, n lowest bits unset), but then later it mixes these. For example the public key is defined of "string of 32 octets", but then section 3.1 says that it is "32 octets encoded as an array of bytes in little-endian order...". As we are talking about the string of 32 octets, talking about it being litt-endian is confusing. I would assume that section 8 of [CFRG-Curves] would define how to convert the internal number to 32-octet string, so leaving out the "little-endian order" from this draft would be clearer. In the section 3.2 recipient tests there is discussion about checking that the public key 32-octet string will have last byte in such way that high-order bit of it is not set. If this is property of the func(d, G) for curve25519, and curve448, how can we ever get public values having that bit set? So why it is only SHOULD to reject that public key? I mean if we receive such public key, that clearly means that other end is either attacker, or working incorrectly, and we MUST always reject it. Or if there is no security issues accepting such public keys, then why not just say that no checks needs to be done. If we reject such public key, what behavior should happen in IKE level? Error message, drop silently? Same as RFC6989? In the security considerations section the 2nd last paragraph only mentions that Curve25519 explictly, but does not mention curve448. Is there difference between them, or should the text say "This is widely seen as a security advantage for these curves, since...". Typos: In section A.1.1 s/mutliplying/multiplying/ The test vectors should most likely also include Curve448 test vectors, and perhaps even full IKEv2 KE payloads... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
