Yuchung Cheng <[email protected]> writes:
> Section 2: tcp-crypt avoid unnecessary round trips. not clear which
> RTTs it saves?
I guess this is compared to other hypothetical designs that maybe incur
an additional round trip to negotiate a public key algorithm or that
don't support session caching. Admittedly this is pretty unclear from
context. Perhaps a better phrasing would be "Require the minimum number
of round trips given the constraints of SYN segments" or something.
> section 3.4: how big (roughly) are INIT{1,2} ?
They are variable length based on the key agreement algorithm specified.
For example, with P-256, INIT2 would be 74 bytes and INIT1 would be 73+N
where N is the number of proposed symmetric ciphers. We anticipate the
ignored data at the end will be zero bytes, but figured that for forward
compatibility it would be better just to require hosts to ignore any
additional data at the end of the message.
> section 3.6:
> "The output of this operation is either "P", a plaintext value, or the
> special symbol FAIL. In the latter case, the implementation MAY
> either ignore the frame or terminate the connection."
> why it's a MAY not SHOULD or even MUST?
> and terminate by RST or FIN?
Ah, good catch. I think this is a bug. We mean may in the colloquial
sense of you may chose between A or B, but clearly in an RFC2119 sense
you MUST do (one of A or B).
> section 3.9 keep-alive:
> unclear what this protects: the receiver still need to support the
> traditional keep-alive probes so it's still vulnerable?
The attack here is that host A transmits some sensitive information to B
and then gets severed from the network before it can close the
connection. Meanwhile, the attacker sends unencrypted keepalives and
acks to convince B to hold the connection open for some really long time
like a week. This then gives the attacker considerable time to
compromise host B and extract the session key (via coldboot or
whatever).
What we are saying is that B should initiate a rekey, and if it isn't
successful after some period of time just abort the connection and wipe
the keys. So now the attacker only has a few minutes to compromise host
B after host A goes away.
> section 10.
> "To gain middlebox compatibility, tcpcrypt does not protect TCP
> headers. " this is confusing b/c section 3.7 is about protecting tcp
> headers.
Right. Maybe a better way to phrase this is that tcpcrypt is tolerant
of middleboxes significantly altering the TCP header including
coalescing or resegmenting connections. It protects FIN and URG, but
nothing else, opening connections up to many DoS attacks including
desynchronization, RST injection, and suppressing rekey bits.
> also, any data on tcp-crypt performance on multiple core machines?
> e.g. cps of 1 byte transfer.
So far our data is on the old (pre-TLV) protocol. We will have to
measure again now.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
