Joe, >... > >It wasn't my list; it was a summary of yours (with my misnumbering): >(note that the 4th one, the second #3 above, was listed in the negative >in your list): OK, the reversed polarity of the last item was confusing to me. >... >None of these are solved by SSL; SSL has corresponding solutions for the >first three, but in no case does it protect the transport connection. You are right that SSL/TLS does not protect the transport layer, but that was not what you asked me to address via that list. >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. >... >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 ... >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. 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. 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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.