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

[Ben Schwartz <[e-mail]>]

On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker <[e-mail]
> wrote:

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

What you're proposing does sound like a completely new handshake.  To be
clear, this proposal makes no change to TLS.


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

Could you point me to which document you're referring to?


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

I'm not sure I understand this distinction.

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

How many DNS and destination roundtrips does this require?  My impression
is that SRV records have proven unpopular in part because they generally
add a DNS roundtrip delay to each initial connection.


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