> Okay, I think I have a fix that involves a smaller delta to the text
> than your suggestion. First of all, I have introduce the term "length
> field" (and use it earlier in 4.1 where before we had length byte). Now
> I have in 4.4:
>
> ... There are two kinds of
> length field: length bytes specifying up to 32 bytes of suboption
> data, and length words specifying up to 256 bytes.
>
> Figure 6 shows the format of a length byte...
>
> A suboption preceded by a length byte MUST be a spec identifier ("cs
> >= 0x20") and MUST have "v = 1". Figure 7 shows an example of such a
> suboption...
>
It's also the case that a suboption preceded by a length word must be both
of those things. Maybe I would say "length byte or word" and put it after
the following paragraph:
> If an octet of the form shown in Figure 6 (with the high three bits
> 100) is followed by an octet in which the high bit is clear (meaning
> "v = 0"), then the two octets together form a length word, as shown
> in Figure 8....
>
> A receiver MUST ignore an ENO option in a SYN segment and MUST
> disable encryption if any of the following holds of the ENO option:
>
> 1. A length field indicates that a suboption would extend beyond the
> end of the ENO TCP option,
>
> 2. The "zzzz" bits in a length word are not 0, or
>
> 3. A length byte or word is immediately followed by an octet in the
> range 0x80-0x9f (indicating another length field with no
> intervening spec identifier suboption).
>
Shouldn't this be true for any octet in the range 0x00-0x9f? The only thing
valid after a length field is an encryption spec suboption with data. (In
this interpretation, the first octet of a length word is not a length byte,
which I think is where you're going with this.)
I think this looks good.
> Okay, how about putting all of the collision-resistance requirements
> together into one requirement with subrequirements:
>
> o The session ID MUST depend in a collision-resistant way on all of
> the following (meaning it is computationally infeasible to produce
> collisions of the session ID derivation function unless all of the
> following quantities are identical):
>
I think the part in the parentheses is the critical part that was missing
before, and it avoids my awkward use of the word "tuple". I think this
reformulation looks good.
> > I can't seem to find the thread in the archives; do you
> > recall who was involved in that conversation? I'd like to get their
> input.
>
> You, me, dkg, Martin Thomson, Stephen Farrel, among others. The root of
> the thread is message ID <[email protected]>, which you
> can find here:
>
> https://www.ietf.org/mail-archive/web/tcpinc/current/msg00697.html
>
> But it's easier to navigate in a mail reader.
>
It turns out I had this exact thought here:
https://www.ietf.org/mail-archive/web/tcpinc/current/msg00724.html
But after re-reading the entire thread, I understand how we got to the
language you have now. I think it's fine. Sorry for dredging this up again.
(This is one of the problems with not having thought about the issue in 11
months.)
> Well, there's another thing that if the session ID is not pseudo-random,
> then 33 bytes might not be enough. E.g., a pathological example would
> be a session ID in which the last 12 bytes are always 0.
>
This example seems to be precluded by the requirement:
Unless and until applications disclose information about the
session ID, all but the first byte MUST be computationally
indistinguishable from random bytes to a network eavesdropper.
Kyle
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
