Re: [DNSOP] Proposal for a new record type: SNI

[Phillip Hallam-Baker <[e-mail]>]

I really don't like the proposal at all. The idea of beginning the TLS
handshake in DNS is sound. But it is a completely new handshake and
authentication layer.

Right now we have a bit of a mess with service discovery. We have a solid
proposal that makes sense written up as a standard and we have a lot of
folk saying we should do something different, either for legacy reasons or
because they find it impure.

The solid proposal is as follows:

* Discover all services using SRV *without exception*

* Use TXT records to provide additional data *that is required for
discovery and binding*

* TXT records may be bound to the service definition, thus covering all
hosts or be bound to a specific host instance.

* Domain names used for services MAY use CNAME or DNAME. Domain names that
identify services MUST NOT.

* Treat everything else as legacy. Expect Port numbers to be supplanted by
SRV prefixes. Accept that TLSA is dead. Don't tilt at windmills with yet
more discovery schemes.

I see a distinction between Hosts and Services. An internet service is
defined by an SRV prefix. A Host has a unique IP address and may support
multiple services which may also share ports.

If the objective is to conceal the service name being connected to, it
follows that any key used to conceal the service negotiation must be bound
to the host rather than the service.

The protocol that these constraints points to would use a lightweight key
agreement with a client supplied nonce and a host specific DNS key to
protect the initial TLS key agreement and then feed that key as one of the
inputs into the KDF for the service level key agreement.

One bonus of this approach is that if you don't care about authentication,
you can dispense with the service authentication altogether and use
encryption based on the host encryption alone. TLS is designed to provide
service authentication that is its purpose and the reason for most of the
complexity.