Valery,
> Got it. In that case, why append NonceRData to InitiatorSignedOctets? Are
> these octets not already contained in RealMessage1 | RealMessage2? (Same
> question for ResponderSignedOctets.)
>
>
>
> This is an interesting point, thank you for bringing it. My
> initial idea was to make changes as small as possible.
>
> I agree that explicitly including nonces in this case seems to
> be not needed. Perhaps it’s safe to remove them.
>
> On the other hand, I heard a lot of times from cryptographers
> that explicit inclusion of some data into some calculation
>
> makes their life easier – they could be sure that all the needed
> data is included regardless of protocol message format.
>
> Thus, I think that it is better to leave explicit nonces so that
> SIGMA proofs remain untouched.
>
As a general rule I agree that the more information signed, the better off
we are. However, since the nonces already appear in the transcript, the
only extra information encoded by appending the peer's nonce is the
identity of the role of the party signing the message (either the initiator
or responder). Perhaps we already encode this information in a different
way? (See comment below.)
> Another minor note here: Why flip the order of the messages between
> initiator and responder? The initator signs RealMessage1 | RealMessage2
> while the responder signs RealMessage2 | RealMessage1. Thinking about the
> implementation, it might be nice to sign the messages in the same order so
> that the signing and verification operations work on the same buffer.
>
>
>
> I don’t have a strong opinion on this. I was only thinking a bit
> about the order.
>
> My gut feeling is that if we make initiator’s an responder’s
> blobs to sign
>
> always different then it is generally preferable from
> cryptography point of view,
>
> but I cannot find any attack where this is exploited in case of
> IKE
>
> (it seems that selfie attack is already impossible due to
> different SK_pi/SK_pr keys).
>
Agreed it's a good idea to encode the role of the signer in the signed
message. Flipping the transcript order is one way to do this, An
alternative would be to include "initiator" or "responder" somewhere in the
message. I'm not sure which one would be better.
>
>
What about the same buffer – sure it depends on implementation,
> but
>
> usually incoming and outgoing messages are kept in two different
> buffers (just because they appear at different times),
>
> thus I don’t think there is a (noticeable) performance penalty.
>
Good point. Plus, you're just going to end up hashing these buffers anyway.
Chris P.
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
