On 23/08/2015 17:26 pm, David Mazieres wrote:
Eric Rescorla <[email protected]> writes:
.... Ultimately this comes down to a question of
subjective design priorities. I'd like to hear how you and other
working group members answer the following two questions a scale of 1 to
10:
A. How much do you care about conserving TCP option space?
B. How much do you care about simultaneous open.
For me, I'd rate A a 9/10 and rate B a 5/10, which is why TCP-ENO looks
the way it does.
For me - I'd rate B as lower, a 2. But I'd really like to find out why
this even exists. Is there some way for someone who's got the kit to go
out and measure how & where simultaneous opens are happening?
Without some data, this discussion is too theoretical; I'd suggest
dropping simultaneous open until someone can provide the fuller case.
S 4.1.
Given that session IDs are required to be unique, why bother with the
spec-id prefix?
Precisely to guarantee this uniqueness. If one spec uses SHA-256 for
session IDs and another uses Keccak, no standard cryptographic
assumption implies uniqueness without that tag byte.
Can you unpack this some?
Let's say that we can compute two transcripts, A and B, such that
SHA-256(A) == KECCAK-256(B). This doesn't violate any standard
cryptographic assumptions. Yet without the tag byte, it would be
devastating to TCP-ENO's security in the event that different specs use
different hash functions.
That doesn't work for me. If someone can compute that, then
(a) we've got much bigger problems with the hashes, and both of them
needed to be deprecated a few years back,
(b) most all other protocols are in deep-doo-doo and
(c) this is TCPINC - we really don't care that much if the attacker
can just kick the packets and force TCP to plaintext.
IOW, accept that risk. Trust the crypto - it's the strongest thing
we've got.
Or did I miss something?
iang
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
