[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Derived versus Explicit technical rationale
I was pretty enervated at Roy's message, so I after writing this, I left
it to percolate for review some hours later, to avoid a caustic tone.
This is as neutral as I am ever likely to become:
> From: Steven Bellovin <smb@research.att.com>
> Historically, RFC-1829 was based on swIPe, which had a sequence number.
>
> 1829 does not have sequence numbers. The text explicitly states that
> IV selection is implementation-dependent, though use of a counter is
> described as meeting the requirements.
>
As I wrote this document, I would hope that I have some knowledge about
what it actually does and does not have in it.
Drafts leading to RFC-1829 started with a field in that position called
"Sequence". There were some doubts expressed that it was unnecessary.
There was also some desire expressed for no IV field at all. And there
were the IPv6 folks that wanted a 96-bit field to align their payloads.
All of these were present in the draft at one time. This is the process
called "compromise" and "consensus building". I once thought that I was
pretty good at those processes.
Obviously, in retrospect, compromise was a mistake, but one of the
co-authors thought that it would be best at the time, and convinced the
others. Perhaps you can understand why I am more resistant to
compromise on the second go around....
Then, once the WG had explored all the options, the discussion baked out
the explicit IVs, leaving only the 32-bit sequence number, and with the
understanding given Karn that 0 could be a negotiable option for
Photuris.
We were ordered to put the 64-bit explicit IV back in. This was done.
But the language for sequence numbers still remains, and is in fact what
most folks have implemented.
I was very careful to use words such as "acceptable", "sufficiently
robust", "most common", to hint that this was the best way to implement.
I took a lot of heat for that at the time.
> A number of people -- including me -- objected to the swIPe sequence
> number. At the time, the cryptographic importance was not understood.
Yes, I remember that. I remember even farther back when swIPe had no
sequence number field, as the IP Identification field was used for the
same facility. In those early days, the argument was whether 16-bits
was enough to detect replay, and whether the IP field was consistently
implemented. Field testing showed that it was not.
But, sequence numbers of one form or another, both to protect against
replay and to use as an IV for DES, were always present from the very
first Karn diagrams that I saw in '92.
And as noted, I have a very old draft that has been delayed politically
for a couple of years describing enhancements for AH and ESP with replay
protection. That old draft was extracted from an even older draft. I've
been advocating replay detection for at least 4 years. (Sound of hand
patting back.) Glad other folks are catching up.
> Implicit may be stronger, but by an infinitesimal amount.
>...
> The size difference, though measurable, is quite small.
>...
> I do have a preference for explicit IVs.
>
OK, here we have a non-technical qualitative judgement. I have given
very explicit technical numbers. One of us judges them significant, the
other "infinitesimal" and "small".
Now, what I do not understand, given that _any_ measurable quantitative
difference exists, why someone would _not_ prefer the strongest and
smallest?
> The only choice I'd be unhappy with is one that mandated implicit IVs.
> That would rule out ciphers that required an explicit IV for some reason.
>
> In other words, I don't care very much about explicit vs. implicit IVs
> for DES. I don't think it makes any difference at all. It may matter
> for other ciphers.
>...
> If people want to change it, at this date, feel free -- *if* we can get
> the !@#$%^& drafts *done* without further delay. My line in the sand
> is if someone wants to mandate implicit IVs for all encryption algorithms.
>
We agree. I have long advocated having the IV description in each
cipher document, rather than one global requirement.
I have no desire to mandate one way for _all_ ciphers.
I do wish that those ciphers that can be done with in smallest and
strongest fashion use that method. That includes all of the block
cipher drafts posted to date.
I once was willing to compromise that some would have explicit and
others would have derived, and the choice would be made by the designer.
However, the "other side" has abandoned the compromise. Should I alone
continue to honor the agreement?
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