>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> Alvaro Herrera <alvherre@commandprompt.com> writes:>> I wonder if we can do something diffie-hellman'ish, where we
have>>a parameter exchanged in the initial SSL'ed handshake, which is>> later used to generate new cancel keys each
timethe previous one>> is used.
Tom> Seems like the risk of getting out of sync would outweigh anyTom> benefits. Lose one cancel message in the
network,you have noTom> hope of getting any more accepted.
That's easily solved: when the client wants to do a cancel, have it
send, in place of the actual cancel key, an integer N and the value
HMAC(k,N) where k is the cancel key. Replay is prevented by requiring
the value of N to be strictly greater than any previous value
successfully used for this session. (Since we already have md5 code,
HMAC-MD5 would be the obvious choice.)
Migration to this could probably be handled without a version change
to the protocol, by defining a new SecureCancelRequest message and a
GUC to control whether the old CancelRequest message is accepted or
ignored. The key length for the cancel key can be increased with a
minor-version change to the protocol (if client asks for protocol 3.1,
send it a longer key, otherwise a shorter one).
--
Andrew (irc:RhodiumToad)
