Kyle Rose <[email protected]> writes:
>> Having two session IDs could also make things a lot more
>> complicated for applications.
>
> I don't know that there's any particular reason to have unidirectional
> SIDs, only a way to construct a single SID in a way that does not
> depend on designating either end of the connection as A or B.
But then how do you do authentication? You need a way of saying thing
slike, "this end of this connection speaks for this user," which means
you need to name the connection and the end. It might help if someone
re-did the examples from the API document under the proposed symmetric
scheme.
>> Second, just because currently we are using ECDHE does not mean that we
>> always will be.
>
> If you're using RSA, both sides could encrypt a secret and then order
> the two lexicographically to make the PMS. Of course, you'd have to
> agree to use RSA or ECDHE in advance, but you're already doing that
> via TCP-ENO.
But you don't want both sides to encrypt a secret--you only want one
side to encrypt a secret with RSA. Otherwise you are potentially adding
another round trip time in the normal case, not to mention expending a
lot of unnecessary CPU time that can limit connections per second on a
busy server.
>> Third, the working group has been unable to identify a good application
>> of simultaneous open that A) would benefit from tcpinc, and B) is harmed
>> by the current b bit mechanism.
>
> Sure. All the above having been said, I don't know how much effort
> should be put into supporting simultaneous open; my instinct, however,
> is to support it transparently if it doesn't overly complicate
> matters. I don't think these changes overly complicate the protocol.
I think we are all in favor of supporting it transparently if that can
be done so for free. But if doing so potentially means adding round
trip times, or preventing public key encryption from being used for key
exchange, or making application-level implementation of authentication
trickier, then we have to make a trade-off.
Section 6.1 of the ENO document lays out four levels of TCP-SO support
and picks one of them. We are open to arguments for other design
points, but it would require either A) demonstrating a need for
transparent simultaneous open, or B) demonstrating (via working out
packet flows) that the cost would be negligible. So far, proposals have
all done at least one of the following undesirable things:
* Consume a lot of option space even in the normal (three-way
handshake) mode of operation, by including a tie breaker in every
active open SYN,
* Prevent use of public key encryption in future specs (by requiring
symmetry),
* Add extra round trips and CPU time (by requiring twice the number of
public key ciphertexts),
* Complicate the API on top of which applications will implement
authentication by getting rid of roles and adding extra
uni-directional session IDs, and/or
* Require each encryption spec to devise its own means of coping with
simultaneous open, again dirtying the application-level abstraction.
In my opinion, none of those trade-offs is worth it. But if I'm missing
something and there's a cheap way of getting transparent simultaneous
open (what we call level 4 in the ENO draft), then I'd love to hear it.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
