-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: ... >> I.e., what is the motivation for BTNS that does not include - if not >> focus - on transport protection? > > Channel binding functionality does not explicitly demand transport layer > protection. Channel binding isn't a motivation for BTNS. BTNS is a place where we are exploring it. >> ... >> RTP is used for VoIP, which is becoming more common, as we hope will be >> DCCP and SCTP. Then there are infrastructure protocols, like >> ISIS-over-IP. i.e., not all of these are as likely to be used as others, >> but there are more than 2. > > And RTP users developed SRTP as an alternative to using IPsec, so ... That's what I'd like to avoid by encouraging using a cross-transport solution, e.g., at the network layer. >> However, SSL/TLS is a red-herring here anyway; it doesn't protect the >> transport layer. TCP/MD5 is the comparable protocol for potential BTNS >> users; there is no equivalent for UDP, and we'd need to reinvent it for >> every other transport protocol in use (at least the handful above) as >> well. > > I agree that the TCP/MD5 hack offers transport layer integrity, but that > does not make it comparable to either IPsec or SSL/TLS. We have been talking about BTNS use cases; as I noted before, one (the original one, and at least one of the current ones) is to protect the transport layer. I *fully* agree with the fact that TCP/MD5 doesn't offer the same protection as IPsec, but it does protect the transport layer. That differentiates it from TLS. > My recollection from the BOF was that only some of the cited motivations > for BTNS explicitly cite transport layer protection. When applications > want to use lower layer security mechanisms to enable higher performance > via off-loading crypto to a different processor, that can be achieved > via SSL/TLS, for example. Performance issues were taken off the table at the BOF altogether. I agree with the rest of the conclusion above, though, but it doesn't seem relevant to BTNS. > I think the crux of our possible disagreement is that you see every BTNS > motivation as demanding protection for the transport layer protocol, > whole I see only one of cited motivations as emphasizing this requirement. > > Steve I agree completely; I'm still trying to understand a motivation that doesn't include that requirement, though. The only ones above that seem to be put forth (correct if wrong, please) are: - performance offloading but performance was taken off the table for BTNS during the BOF - channel binding which could be useful with or without BTNS, i.e., it binds an application identity to a network identity (but the latter need not be ephemeral) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/kUEE5f5cImnZrsRAsazAJoDi54/LXulqGIwcqpqbMuLNpHbjQCdHQ95 NhPTx1Iuud4XFQsXOMhncK8= =dCVk -----END PGP SIGNATURE-----
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.