[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Calling the question: derived vs. explicit IV
I was disappointed with the factual inaccuracies, misleading and
inconsistent statements in this co-chair's posting, and had
requested a correction. But, none has been forthcoming.
I also take umbrage at the personal attack in the last paragraph.
I believe these inaccuracies poison the straw poll.
Rather than arguing, I present the following questions:
> Date: Fri, 1 Aug 1997 14:27:20 -0400
> From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
>
> Date: Fri, 1 Aug 97 14:32:52 GMT
> From: "William Allen Simpson" <wsimpson@greendragon.com>
>
> In favor of Derived:
>
> 2) Maintains complete backward compatibility with RFCs 1829 and 1851.
> All shipping implementations already support the derived IV.
>
> Not true. It is not _complete_ backwards compatibility. RFC 1829
> support's no IV, 32-bit IV, and 64-bit IV. The compatibility you
> propose only works using RFC 1829-style 32-bit IV.
>
Please indicate the page and line in RFC-1829 which "support's" [sic]
"no IV"?
Please indicate which specific shipping vendor implementations of
RFC-1829 do not support 32-bit derived IV, instead supporting only some
other IV, preventing this from being _complete_ backward compatibility?
> In addition the handling of sequence number wrapping means that there is
> yet another compatibility issue. This can be solved having the ESP
> engine know something about whether the key management was manually done
> or not. However, that's an abstraction violation, and it certainly adds
> to the complexity of the implementation simply to have this
> "compatibility".
>
Please indicate where RFC-1829 supports "sequence number wrapping"?
Please indicate where "sequence number wrapping" is required to be
handled in draft-ipsec-ciph-des-derived?
Please indicate where "sequence number wrapping" is required to be
handled for manual keying in ESP?
BTW, there is a MUST in the Kent ESP draft that is in error, as there is
also no requirement for enforcement of anti-replay. The draft is
self-inconsistent. As has been noted several times on this list.
Of course, _all_ SPI managers need to know what key engine was used for
configuration. Otherwise, it might try to trigger the automated engine
when it had been manually keyed -- resulting in a security breach -- for
DNS, DHCP, and other scenarios where the key must be manually
administrated to avoid the chicken-and-egg problem. How _is_ your code
coming along?
> 3) Will reduce administrative and operational confusion. A change to
> explicit IV would "obsolete" thousands of fielded units, and create
> a user support nightmare.
>
> No so. The fielded units do not support key management. The assumption
> which I'm making here is that manual keying will continue to use RFC
> 1829.
Are you saying that there will be two (or more) supported domains of
interpretation, one for manual keying and another for Oakley/ISAKMP?
Are you saying that it will be the official policy of the IETF that
RFC-1829 and its successors will advance to Internet Standard as the
method to use for manual keying?
> The new units that support key management will support explicit
> IV's; if they choose to support manual keying for compatibility with
> said "thousands of fielded units" (and the market will decide whether or
> not that's necessary), they can simply support RFC 1829. It's not that
> much code to support both.
>
Are you saying that this "much code" does not add "to the complexity of
the implementation" (your objection above)?
How is this a consistent position?
> 4) Interoperable code will be more rapidly deployed.
>
> The vendors who participated in the ANX interoperability demo were using
> explicit IV's.
>
Were all ANX vendors using explicit IVs?
Were all ANX vendors interoperable with RFC-1829 manual keying?
How would such vendors "more rapidly" deploy interoperable code that is
not interoperable with currently fielded implementations?
(I was there, I happen to know the answers already.)
> 5) Any change to explicit must show GREATER cryptographic strength.
>
> Derived has been show to give somewhat stronger protection of the
> first block than explicit. Estimates are from 2**7 to 2**16
> depending on environment.
>
> Not true. We will be using an MAC to protect the packets against other
> attacks; this means that your posited attack of being able to modify the
> first block is simply not an issue.
>
Is a MAC required or optional?
Is a MAC required in manual-keyed scenarios between two single user hosts?
Is a MAC required in manual-keyed scenarios between a single user host
and a multi-user host or firewall?
> As far as Bill's counting of noses of who is for and who is against,
> there are a number of in his lists for which I haven't seen a clear
> statement on this position, and a number of people who have stated a
> position which he neglected to put on his lists. I am keeping track of
> messages sent both to the list and to me privately; however, I'd ask
> that folks send their preferences to the list, if at all possible.
>
You question my integrity?
I very carefully counted every message sent to the list in the previous
two months.
I did not count messages sent privately. They do not count.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: