Yoav Nir writes:
> The title is "New Safe Curves for IKEv2 Key Agreement”, which I
> think is slightly better than the CFRG draft ("Elliptic Curves for
> Security”), but perhaps too generic. Maybe we should follow the
> example of the TLS draft (“Curve25519 and Curve448 for Transport
> Layer Security (TLS)”) and title it “Curve25519 and Curve448 for
> IKEv2 Key Agreement”.That title looks good. > I tried to follow the example of the TLS draft where the public keys > are strings of octets while the private (or “secret”) keys are > numbers. I see that I missed that in section 3.1. How about: > > OLD: > o The Key Exchange Data is 32 octets encoded as an array of bytes in > little-endian order as described in section 8 of [CFRG-Curves] > NEW: > o The Key Exchange Data is a 32-octet public key as described in > section 8 of [CFRG-Curves] I think this is better, i.e. keep the reference. > > 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? > > Tough one. The draft says something about implementation > fingerprinting, but if some implementations drop this at the IKE > level and some don’t that’s is a new avenue for fingerprinting. Yep. > I don’t know which one is right. In any case, *if* you make the > check *and* it fails *then* it’s appropriate to send an > INVALID_SYNTAX (although I don’t understand why RFC 6989 recommends > that over INVALID_KE_PAYLOAD) notification. If we would use INVALID_KE_PAYLOAD then we would need to send list of acceptable groups in it, and it would be stupid to say that when other end is using group X, that INVALID_KE_PAYLOAD(use group X)... INVALID_SYNTAX tells that other end something that was invalid from the protocol point of view, i.e. in this case it sent payload which had bit set, where standard says it MUST not be set. I think we either should say MUST, or MUST NOT (I do not really care which one), but not SHOULD... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
