[anonsec] 3401 and highjacking

[Joe Touch]

-----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-----