> I agree that spec is a bit of a made up word, here, but we've failed to
> come up with a better one. For what it's worth, you are kind of
> negotiating a document and a protocol. But basically I think we would
> need a more concrete suggestion to do something about this awkwardness.
>
I'll think about this for a while. I don't have a suggestion at the moment.
> So from my limited experience, it seems like one is supposed to ask IANA
> for a specific number to which they reply yes or no, rather than asking
> them to choose the number. I was hoping that since we say you MUST NOT
> implement 69, this would satisfy the objections to option kind
> squatting. (Michael Scharf did at one point suggest he would be okay
> with the statement, "This protocol specification MUST NOT be implemented
> prior to assignment of a TCP option kind number.")
>
> But if it's better to use a symbolic constant like ENO, we can do that,
> too. We'll defer to people who know the process better.
>
Based on the rest of the thread, I'll let you, Joe, and David Black work
this out. It's really outside of my area of expertise.
> Right, the idea here is that if v=0, then it's not a suboption preceded
> by a length byte, but rather a length word. We've tried to clarify the
> language.
>
Here's what you have now:
If the octet following a length byte has the high bit clear (meaning
`v = 0`), then it is not a suboption. Instead, the length byte and
following octet together are interpreted as a length word, as shown in
(#fig:marker-word). The length word encodes an 8-bit value
corresponding to one less than the suboption data length. As with
length bytes, the octet following a length word MUST be a spec
identifier suboption and MUST have `v = 1`.
It still has the problem that it implies a length word starts with a length
byte, and so the second byte must have both v=0 and v=1. I realize I'm
probably being pedantic, but I think it's worth being really precise.
Here's my attempt:
<<EOF
... The sender does so by preceding the suboption with an encoded data
length.
Suboption data lengths are encoded in either one or two octets. If the
length is between 1 and 32 bytes (inclusive), it may be encoded in a single
octet as a suboption with v=1 and cs<0x20, as shown in figure X.
Lengths up to 256 bytes (inclusive) may also be encoded in two octets, the
first of which is a suboption with v=1 and cs<0x20, and the second of which
must have the high bit unset, as shown in figure Y.
The octet following an encoded length MUST be an encryption spec suboption
followed by suboption data (v=1, cs>=0x20). Figure Z shows an example of
such a suboption.
A receiver can distinguish between length encodings of one or two octets by
examining the high bit of the second octet: if it is 0, the length is
encoded in two octets; if it is 1, the length is encoded in a single octet.
In the two-octet case there is no ambiguity with general suboptions (v=0,
cs<0x20) or encryption specs without suboption data (v=0, cs>=0x20), as by
specification neither may have suboption data and so may not follow an
encoded length.
EOF
I've spent an hour on this and I'm still not entirely happy with it. Heh.
(This experience forces me to wonder if there's an easier-to-follow
encoding that has the same characteristics around parsimony of option
space. I doubt it, and I'm sure you've looked.)
Obviously the issue here is what happens in the very distant future if
> ever TCP SYN option space becomes huge, like more than 255 bytes. As
> you point out, there is the separate limitation that each option only
> has one byte of length.
>
> In the previous draft, we figured that in case both problems are fixed
> (total option space an individual option length), we might as well have
> a 12-bit length word. Upon further reflection, we figured that isn't
> super likely. Instead, it may become necessary to split TCP-ENO over
> multiple options, or reference extension options, or something else we
> haven't yet thought of, for which it's better to have completely
> reserved the zzzz bits right now. It will already be a miracle if we
> get >256 bytes of aggregate SYN option space, so there are just too many
> unknowns about whether we'll ever get >256 bytes per individual option.
>
It's also not clear that option space will be useful or recommended for key
agreement shares that don't fit in 256 bytes, e.g., shares for hypothetical
post-quantum key agreement schemes. We're likely to see a huge blow-up in
share size compared to what we have today even with large RSA public keys.
So I think this choice is fine: I was just throwing it in there for
discussion.
> Now, why not hard-code 0's instead of having zzzz? Well, the initial
> 100 bits are how you recognize that you have a length byte/word; the
> meaning of every other value of the high 3 bits is already fully
> specified. However, if we just wrote 1000000, then we haven't addressed
> the question of what 100zzzz means for values of zzzz other than 0000.
> We used the zzzz variable to make sure every possible byte sequence was
> defined (even if the definition for zzzz != 0000 is just abort). Does
> that make sense?
>
I was struggling with this exact problem in composing an alternative
suboption data length description, so I now understand what drove this. All
good.
> > [5.1] q( The session ID MUST depend in a collision-resistant way on fresh
> > data contributed by both sides of the connection. ). Is this clear enough
> > to rule out specs that, for instance, take random data from each side and
> > XOR it? I think it does if "collision-resistance" is interpreted as
> > applying to the set of raw inputs to the session ID computation; it
> doesn't
> > if a spec author interprets it as applying to the string used as the
> input
> > to the collision-resistant compression function they employ to produce
> the
> > final session ID, where that string is some function of the raw inputs.
>
> XOR is not collision-resistant. I'm not sure I understand your second
> interpretation well enough to craft language to rule it out. Do you
> have any suggested language?
>
I'm not sure, because the potential misunderstanding is really subtle.
Let's say a spec says:
session ID = PRF('foo', (client_random XOR server_random) || other inputs)
This is collision-resistant in the sense that the underlying PRF is
collision-resistant, so (wlog) an adversarial client can't for example
choose two different client_randoms for a given server_random and get the
same session ID; but it *can* choose a client_random for any given
server_random such that the XOR of the two is the same, which may result in
the session ID being the same for multiple connections. This isn't a
collision in the PRF: it's a collision in the tuple of inputs to the PRF.
(I'm not sure I'm explaining this clearly; let me know.)
I think your language does literally prohibit this case (the overall
session ID function in my example isn't collision-resistant on its tuple of
inputs), but it's really subtle and spec designers might screw it up. Maybe
I'd be happy with q( The session ID MUST depend in a collision-resistant
way on fresh data contributed by each side of the connection. ). Or maybe
I'd separate out collision-resistance entirely:
<<EOF
o The session ID MUST be collision-resistant on its tuple of inputs.
o The session ID MUST depend on fresh data contributed by each side of
the connection.
o The session ID MUST depend on any public keys, public Diffie-Hellman
parameters, or other public asymmetric cryptographic parameters that are
employed by the encryption spec and have corresponding private data that is
known by only one side of the connection.
o The session ID MUST depend on the negotiation transcript specified in
Section 4.7.
EOF
Now I've created a new problem, which is: does this combination of
constraints imply that the session ID cannot depend only on the first bit
of (for example) the negotiation transcript? I'm not sure; maybe it would
be better to explicitly state that "The negotiation transcript specified in
section 4.7 MUST be included in the tuple of inputs to the session ID
computation."
If I am being too pedantic, feel free to ignore. I am probably going way
beyond what is reasonably required in terms of precision.
> [5.1] q( 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. ). For DH,
> > this seems to imply that the session ID must be a function of the output
> of
> > the key agreement, because all other input to the session ID is public.
> Is
> > this actually necessary, however? I've been struggling with whether it
> even
> > matters if an eavesdropper can compute the session ID from a public
> > transcript: the two required properties seem to be that both ends of the
> > connection can compute it, and that it be unique over all time with
> > overwhelming probability.
>
> This was discussed on the mailing list, and the feeling was that there
> are cases where you might want to generate crypto keys from the session
> ID (for example to authenticate that another connection belongs to the
> same host as the first connection).
>
Sigh... yeah, I remember that conversation now. The problem with allowing
the session ID to be public but not *mandating* that it be regarded as
public is that a deployment using a non-tcpcrypt spec that requires the
session ID to be private might make use of a general TCPINC-aware helper
application that assumes the session ID is public based on tcpcrypt's
requirement that it be public for purposes of bulk signing. It almost seems
inevitable that someone will write such an application, and that someone
will deploy it inappropriately without understanding the disastrous
interaction.
I would personally prefer an exporter facility for channel bindings that
explicitly requires secret input to get secret output, and for the session
ID to be explicitly regarded as public so no one will try to use it
inappropriately. 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.
I do recall Christian mentioning in Buenos Aires that the session ID
shouldn't enable passive tracking of clients, which might imply this
requirement anyway for purposes of derived SIDs used for session caching,
but that might be more appropriate as a requirement for encryption specs
and not within the ENO spec since nothing about ENO mandates the existence
of session caching or reuse of session IDs in the first place.
> [9] The first paragraph here *really* makes me want to figure out a way to
> > conceal "a" from passive eavesdroppers because it means active attackers
> > wouldn't know until it's too late that they can't safely MitM a
> connection.
> > Not sure if there's any way to achieve this. It may be irrelevant because
> > the application-aware bit can be set to 0 for applications that will not
> > function without transport encryption. Maybe that's actually the answer:
> > recommend that the application-aware bit be set to 1 only for application
> > protocols that are willing to function without encryption, and 0 at all
> > other times.
>
> Well, if an eavesdropping ISP starts downgrading only connections with
> a=0, then everyone can just start setting a=1... It could also be that
> if connections are downgraded, an application falls back to some other
> form of encryption...
>
> But I see your point, I just don't know what to do about it, especially
> because in the case of mandatory application-aware mode, you don't want
> to go through the trouble of key exchange in the first place.
>
Yeah, I'm not sure it's worth doing anything about this. I'll file it under
"It would be nice if..."
> Other than the third leg of the handshake, any other non-SYN ENO options
> will be after the key agreement, so can just be encrypted or MACed. But
> to be honest, even that last paragraph seems a little weird to me, and
> is there by request of someone else. I think the idea is that the first
> ACK is part of the TCP handshake, so people might subconsciously think
> it is part of the negotiation transcript. I'm happy to substitute
> whatever wording you want to suggest.
>
This is one I don't feel strongly about. What you have is probably fine.
> Anyway, below are the diffs so far.
>
The rest of the diff looks good.
Kyle
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
