> On Aug 26, 2015, at 9:33 AM, Yaron Sheffer <yaronf.i...@gmail.com> wrote: > >>> 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.
Ah. Makes sense. Section 2.5 has the string “invalid KE payload” several times, so it looked strange. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
