Kyle Rose <[email protected]> writes:
> What exactly is the issue here? You mentioned a client being tricked
> into thinking it has connected to itself, but I think I need you to
> spell out the worry here. In my earlier post, I was thinking it was
> sufficient for an application to know it is (at least) one end of a
> session identified by a particular SID, but I'm perfectly willing to
> believe I'm missing something subtle here.
An example of something I'm involved with that obviously doesn't use
TCPINC but might well if it were widely available is stellar-core
(www.stellar.org). It uses a peer-to-peer overlay network to multicast
messages, with pairwise authentication to make sure you are talking to
the nodes you think you are talking to (as opposed to random people who
might try to DoS you). You also hear your own messages, a bit like the
loopback interface. If you didn't have roles and just signed session
IDs, you'd need some other logic to make sure that you really are
talking to yourself. Otherwise, anyone could just throw your
authentication signature back in your face.
Now since the system doesn't use simultaneous open, you could use the
active/passive opener status as the role. But this makes it harder to
abstract away authentication. Ideally, in the long-term we would have
libraries for authentication where you just hand the library a file
descriptor and credentials and everything works, including the case of
simultaneous open if that's ever used.
The more general point is that domain separation is extremely important
in the use of digital signatures and MACs, and having explicit roles
make it harder for people to mess that up.
> Yeah, I am worried we're expending too much mental energy on SO
> itself. But part of the reason I'm glad it was brought up is that I
> still have no real idea what the TCP establishment thinks about the
> expendability of SO considerations. I'd hate to put a lot of work into
> something and have the tsv AD or IESG remand it because it turns out a
> lot more people care about SO than we currently guess. That having
> been said, my suspicion is that it won't be a problem if the naive
> failure mode for an unmodified SO-based app, both endpoints of which
> support TCPINC, is to fall back to unencrypted TCP. I can believe they
> would have a problem with a failure mode in which SO applications fail
> to connect.
Yes, that's why we chose point 2 on the four-point scale that arose out
of the last TCP-SO discussion on the mailing list:
https://tools.ietf.org/html/draft-ietf-tcpinc-tcpeno-00#section-6.2
I think given the present discussion, I might revise points 3 and 4 to
say it would either require a tie-breaker, or place the onus of role
assignment on encryption specs, thereby potentially incurring additional
computation or round trips.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
