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. 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.
RFC 6989 recommends INVALID_SYNTAX because per RFC 7296,
INVALID_KE_PAYLOAD is used for cases where the initiator is expected to
retry the exchange. Incorrect DH values are at best a bug and at worst
an attack, and should not result in an automatic retry.
Thanks,
Yaron
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
