Jana Iyengar <[email protected]> writes: > Hmm ... This seems like a potential rathole. This is a MITM attack > (though I don't understand it fully), and TCPINC is expressly not > protecting against such attacks, right? I may still not understand the > value proposition of TCPINC, but that would be a different thread on a > different list, I think. This attack, as several other attacks are bound > to be, seems to be out of scope for this wg.
The value proposition comes from separating the encryption from authentication, because it makes it easier to test the two parts independently. It just so happens that both TCPINC proposals have this property, so if ever either of them gets to the point that people are doing certificate validation of the TCPINC session ID, the validation code may be easier to test. Also, people may use multiple techniques to protect session IDs, such as a certificate and a password or two-factor mechanism, mitigating the effects of forgetting to check the certificate. However, by the time this happens, TLS channel bindings may be in more widespread use, too. So I wouldn't say it's directly relevant to TCPINC's charter, so much as a side benefit of getting to design a protocol in 2015 when we understand these architectural issues better. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
