ietf
[Top] [All Lists]

Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)

2006-10-03 04:45:04

On Oct 3, 2006, at 3:36 AM, Iljitsch van Beijnum wrote:

I don't quite see what happens when the new key isn't present on both systems and timestamps start to expire, but that should be solvable in one way or another.

The purposes of the TCP-MD5 protocol is to ensure that two TCPs that don't have the same keys can't communicate. I think it accomplishes that, sooner or later.

Your concern is that it might be too frisky getting there. I'm proposing that you be in control of how quickly you get there by how you set the "delete" timer.

Suggestion: don't start sending ALL traffic with all keys, just throw in a copy of a packet signed with the new key once in a while and keep using just the old key for most traffic until a packet with the new key is received from the other side.

Well, one approach to my "optimization" would be start sending all new traffic with the new key, but retransmit with the old key. That *does* require at least an operational change to the protocol implementation, although not a change to the protocol itself. It also means that during the period that only Alice thinks there are two active keys, we can't move very quickly.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf