Bryan Ford <[email protected]> writes:
> There are two simple ways of handling authentication, in this
> scenario, depending on whether and how much you care about
> distinguishing “which endpoint is which” in the process.
Exactly. The fact that applications currently have to chose between
multiple ways of doing this means they may get it wrong. Whereas having
a session ID and a role is pretty simple.
Big picture, the goal is that we will basically get TCPINC right, which
means most vulnerabilities will arise out of misuse of the API. So we
really want to keep it as simple as possible.
> Where would this create an extra round-trip? To me everything seems
> exactly the same in terms of round-trips. In the client/server
> “common case” scenario:
>
> 1. A (client) RSA-encrypts a secret S_A and sends it to B as part of
> its INIT packet.
And where did A get B's public key? By that point an asymmetric
protocol would probably have allowed B to send data. Besides, why pay
the price of two RSA decryptions when you only need one?
> And I think it’s more important for tcpcrypt not to break TCP’s model
> precisely because tcpcrypt is (rightly) positioned as something
> readily implementable in the kernel basically as an extension to the
> TCP stack itself.
But how is TCP's model symmetric? Simultaneous open is this weird
fringe case that didn't even work until we had NATs and firewalls to
suppress SYNs that would otherwise trigger RST packets. Even now it
basically only works through particular kinds of NATs. We can barely
seem to find any examples of its use in practice. Other than that, TCP
is full of asymmetries on both the connection setup and shutdown.
Someone with more historical perspective can correct me if I'm wrong,
but it doesn't appear as though symmetry was a particular design goal of
TCP.
> How to do that seems pretty clear to me, but perhaps I need to go do a
> more thorough reading of the TCP-ENO draft and suggest specific text.
> I’ll try to do that as soon as I have a moment.
I think the best way to work through these things is with packet flow
diagrams. For example, if your symmetric RSA example looks something
like this:
A -> B: SYN(ENO)
B -> A: SYN-ACK(ENO)
A -> B: (ENO) PKA
B -> A: PKB, {NB}_PKA
A -> B: {NA}_PKB
A -> B: data
B -> A: data
Then it takes 2.5 round trips before B can send any data to A (using
keys derived from NA, NB, PKA, PKB), vs. 1.5 in the simpler protocol
where the session keys are derived from just PKA and NB (plus probably
some other nonces not shown):
A -> B: SYN(ENO)
B -> A: SYN-ACK(ENO)
A -> B: (ENO) PKA
B -> A: {NB}_PKA
B -> A: data
A -> B: data
The other major advantage of the second (asymmetric) diagram is that it
supports very high connection rates at the passive opener, because with
low exponents RSA encryption can be much faster than decryption. So the
crypto for the symmetric RSA protocol isn't "just" twice as expensive on
the server, but on my machine about 33x more expensive. The discrepancy
grows linearly with modulus size, too, since decryption is O(n^3) and
encryption O(n^2).
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
