[anonsec] 3401 and highjacking
touch at ISI.EDU
Thu Feb 23 15:28:04 PST 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
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
> 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
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.
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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the ANONSEC