Re: [tae] New draft: announcing the supported transports via DNS

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Some comments below...

Andrew Yourtchenko wrote:
...
> Also, if we assume "evil middlebox" in the middle, that decides to drop
> this new option, we will have a TCP connection that would not succeed,
> so then still there needs to be a fallback to "plain TCP".
> 
> That's one of the rationales of bringing up the use of DNS in lieu of a
> in-band selection in general - we would still need to be able to
> fallback to probing in the worst case (how frequent is the worst case
> would of course need some more investigation).

Use of the DNS is problematic on many levels:

- - many users have IP addresses they don't control, e.g., assigned by an
ISP, and those ISPs don't offer the ability to register services with
their DNS

- - you're involving a third party in a two-party problem

- - you still have a bootstrapping problem -- by what transport do you
talk to the DNS?
	- if you solve that for DNS, why not use that solution at the
	endpoint?

> Now, a few variables in discussion of selection via a separate protocol
> vs. DNS-based.
> 
> 1) neither actually proves the possibility of the new protocol to
> traverse the middleboxes - so probing is needed for either case. The
> policy enforcement points are (at least now) frequently decoupled from
> the endpoints, so the probing would be needed regardless.
> 
> 2) The separate protocol is more distinct than using a DNS record, so
> requires a separate explicit policy decision and enforcement. (of course
> the actual transport policy needs to be enforced separately for both).
> 
> 3) If the DNS is used, then the failure to pass the particular DNS
> record would mean we can'd do "advanced" transports - however, this does
> not preclude from already starting on the "default" transport - since it
> is not express a requirement, but a desire/proposal.
> If we fail to get the reply using the separate protocol, then we need to
> fallback to default, how do we do that ? (and for in-band negotiation
> within transports, would it suffice to define a single method of
> fallback ?)
> 
> 4) Assuming the decisions re. the advertised transports are relatively
> long-lived, in the case of DNS we should be able to benefit of
> distributed caching, in case the cached replies do not fully correspond,
> the fallback/probing that has to be there anyway, will help to with a
> smoother fallback.
> 
> 5) the caching nature of DNS, while providing a benefit, exposes one new
> attack vector that I did not think of before - which is the
> reconnaissance without the knowledge of the party that advertizes the
> transports. The explicit protocol does not have such a property. This
> may or may not be important.
> 
> 6) Assuming the responder does not change its "default" graph
> on a per-connection basis, it may be more beneficial to "pre-create" the
> proposal and let the initiator do the work of creating the mutable
> "common" graph - DNS might be more appropriate here. OTOH if the server
> *needs* different graphs on a per-session basis, then a separate
> protocol is more appropriate.
> 
> 7) Introduction of the new protocol for negotiation of the new transport
> protocols looks to be the same higher order function of "introducing a
> new protocol", just with a different parameter.
> The more distinctly "new" this protocol is, the more distinct this
> property is. So maybe a combined, staged approach is something to consider.

It sounds like you've talked yourself out of using the DNS, or mostly
so. Is that the case?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrGBEgACgkQE5f5cImnZrsrKwCgsDuDfgbkmvPNJj+HZOZJZAZ8
u84AoIPG8G6Idm4LHaeJdAhFCUBhcI7P
=Vdz+
-----END PGP SIGNATURE-----