[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed changes to the DES-CBC, HMAC and Replay Prevetion Security Transform.
I think you might have missed the point if I understand your earlier
postings. If I'm correct, you thought that I was suggesting that no IV
be used for one and an IV be used only if it was included in the packet.
I'm not suggesting that at all. The current transform says you use an IV
derived from negotiated keying material if one isn't present. That would
be the same. I only would like to see two separate transforms, one where
the derived IV is used, and one where the included IV is used.
Your point about the replay window was lost on me. I never suggested an
infinite replay window, only that I saw no advantage in supporting the
negotiation of replay windows. If my implementation has a 32 bit replay
window and the peer I'm communicating with has no window and requires
packets in order, what do I care? Why should that be negotiated? I had
one person say that there was added vulnerability in using a window versus
requiring packets in order and that negotiating would allow sites to not
allow this vulnerability. I don't see the vulnerability. If my
implementation is guaranteed to drop packets it has seen before, I can't
fathom the vulnerability. If I'm missing something, I'm perfectly willing
to drop my request. I'm simply saying that replay window size is an
implementation detail, the size you choose is up to you.
-Rob
>
>Rob Adams writes:
>> The following are changes I'd like to make to the above document. I've
>> posted comments about the changes to the list and didn't get a lot of
>> comments.
>>
>> I've made the following changes:
>> 1) added a new transform specified by a different IANA number for
>> packets including an IV.
>> 2) made the replay window size NON-negotiated. It is left to the
>> implementation.
>
>I do not particularly like either of these proposals, for reasons I
>have already stated in previous messages.
>
>Perry
>