On Nov 5, 2015, at 10:44 AM, David Mazieres <[email protected]> wrote: > 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.
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.
If you DO care about distinguishing the endpoints: authenticate based on an
ordered pair of the session identifiers or (based on a hash of that ordered
pair if you care about its size). For example, if A and B are the participants
involved and we call the two directional session IDs “AtoB” and “BtoA”, then A
authenticates its end by signing the (optionally hashed) ordered pair {AtoB,
BtoA}, and B authenticates its end by signing the (optionally hashed) ordered
pair {BtoA, AtoB}.
If you DON’T care about distinguishing the endpoints: as Kyle suggests, just
lexicographically sort the AtoB and BtoA session IDs, and either authenticate
that pair or a hash of it if you care about size. Then both endpoints are
simply saying, “I attest that one of the endpoints of this session speaks for
me”, without saying which one. This can sometimes be desirable: e.g., some
[partially-]deniable authentication protocols depend on precisely this
property. If you are one of the parties (e.g., A), you presumably know who you
are and only care about verifying who the other party is.
I don’t have a strong position on which of these approaches is better, but it
seems nice that the symmetric protocol design makes either or both of them
trivial to accomplish, which may depend on the needs and requirements of the
application.
>>> 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.
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.
2. B (server) RSA-encrypts a secret S_B and sends it to A as part of its INIT
packet. B now already has all the information it needs to construct a joint
master secret: e.g., it uses the ordered pair {S_A,S_B} to form the master
secret for the AtoB direction, and uses the distinct ordered pair {S_B,S_A} to
form the master secret for the BtoA direction. B can start using this master
secret immediately to start encrypting and sending data to A without waiting
for further communication from A. Exactly the same as in the ECDH case.
3. A (client) finally receives B’s encrypted S_B decrypts it, and can now
compute the same two master secrets and start sending encrypted data to B.
Again, exactly as if A had been waiting for an ECDH public-key from B with
which to do DH key exchange.
Of course, if A wants to send encrypted data to B from the very first message
(#1 above) it needs to play “zero-round-trip” games just like TLS 1.3
presumably using state cached from a previous session, but that’s another topic
and seems like it still would work the same way whether based on ECDH or a pair
of RSA-encrypted secrets.
Regardless, I’m not suggesting that we “should” bother specifying or
implementing the RSA variation unless the WG feels it’s worth the trouble - but
at any rate it seems like the option is there and presents no additional
difficulty beyond ECDH.
>>> 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.
I’m still waiting to hear how the symmetric design makes anything trickier,
either for tcpcrypt itself or for the application using it. ;)
> 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:
I think it may be reasonable to keep the "tie-breaker bit” or something
equivalent in the TCP-ENO specification, because some protocols we might want
to negotiate with it (e.g., TLS) may have baked-in assumptions about a
passive/active asymmetry. But if the two endpoints both support and happen to
decide on tcpcrypt, it would be nice if they simply never needed to use the
tie-breaker bit for anything, and hence don't have to run the risk of things
breaking even in the (however potentially rare) case of simultaneous open. The
fact that other protocols break TCP’s symmetric model doesn’t mean that yours
needs to break it as well. ;)
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. Creating another
user-space protocol with baked-in passive/active asymmetry like TLS would not
be inconsistent with existing practice (e.g., TLS), but creating a protocol
intended for kernel-space implementation with such a baked-in asymmetry
assumption would be a much bigger divergence from the tradition of kernel-space
TCP extensions.
> 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.
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.
Cheers
Bryan
>
> David
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
