[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-ciph-cbc-02.txt
>>>>> "Bill" == Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:
>> P.S. I suggest that when we revise the text of this draft, that
>> we word it as saying that implementations SHOULD reject weak keys
>> and request a new SA, but to not claim to have an exhaustive
>> listing of all possible weak keys in the document. That way, when
>> researchers come up with new and interesting weak keys in IDEA,
>> implementations be updated without implementors worrying about
>> violating the spec.
Bill> I'm a little leery about this, because it means that different
Bill> implementations would have different ideas about what
Bill> constitutes a weak key, which could lead to rarely-occurring,
Bill> difficult-to-diagnose interoperability glitches when the shared
Bill> key ends up being "weak" and one endpoint detects this and the
Bill> other doesn't.
I don't see any alternative.
Clearly you have to be able to deal with a situation where one side
rejects a key that the other doesn't. The alternative is to prohibit
the checking for weak keys other than the ones known at V1 time and
listed in the V1 documents. If the idea of checking for weak keys has
any merit at all (and I believe it does) then it clearly has to be
possible to check according to the latest and best knowledge.
This is a very simple case of designing a protocol for extensibility.
It's well known how to do this -- surely we can get it right in this
case?
It seems to me that all that's necessary is to allow each side to
decline to use the negotiated parameters once it finds out what the
key is. If all else fails it can do that by considering the SA to be
expired already and applying the usual mechanisms.
paul
Follow-Ups:
References: