Subject: [dane] A different approach to SRV discovery.

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 3 May 2013 12:49:02 -0400

It has been apparent to me for several years that the IETF needs to have a
better approach to service discovery and that SRV like technologies should
be a part of that solution.

Making DANE work with SRV discovery seems to be a good idea. But it is a
piecemeal approach that I think is unlikely to help adoption of DANE or SRV
type discovery. Rather than look at the problem from the point of view of
making two existing technologies play nice together, it is better to
approach the bigger problem we are trying to solve.

I don't think DANE can be made to work nicely with SRV, NAPTR and the rest
as people would like. But working the other way around and proposing a new
discovery record that has support for DANE built in does allow a 'fluent'
result.

Proposing new discovery mechanisms is not to be done lightly but neither
SRV nor NAPTR is adequate for Web Services in any case. SRV only provides a
redirection to a domain name, Web Services require the ability to host
multiple Web Services on the same server under the same domain name. Hence
the need for the URI proposal. SRV records don't have quite enough power,
NAPTR records have too much. They were designed to support URN discovery
and not service discovery.

Constraints:

1) The IETF has three separate prefix based discovery mechanisms: SRV,
NAPTR and URI (proposed) in addition to A and AAAA.

1a) Protocol designers should not choose the discovery mechanism because
the constraints that affect the choice of mechanism are all constraints
that fall on the network administrator deploying the system.

1b) The design of DNS makes the use of multiple records for the same
purpose highly unsatisfactory and inefficient.

1c) SRV and NAPTR are already deployed and so any accommodations have to be
made in DANE.

2) The IETF has also proposed two separate mechanisms for asserting a PKI
policy information. There is DANE and there is HTTP certificate pinning.

3) Application providers tell us that they will only perform a limited
number of DNS lookups to support discovery. At the moment they are required
to do A, AAAA, and possibly SRV or NAPTR as well plus potentially a whole
additional resolution chain afterward.

Assertions

A1: There should not be a choice between mechanisms, there should instead
be an order of precedence so that if there is a record of type X it will
take precedence over all the other types of record.

A2: Rather than trying to force a choice between mechanisms asserting or
pinning a public key, the discovery mechanism should be agnostic and
support both.

These considerations result in the following design. We introduce a new
record, the URII record that has the same syntax as the existing URI record
proposal but instead of the target being just a URI, it is a URI followed
by optional discovery parameters:

_service1.example.com URII 10 10 "https://ws.example.com/service1/"
_service2.example.com URII 10 10 "https://ws.example.com/service2/ dane"
_service3.example.com URII 10 10 "https://ws.example.com/service3/ pin=foo"

Service1 simply redirects to a Web Service URI just like the current URI
scheme does.

Service2 and Service3 have a redirect but also provide TLS policy
information. In the first case the discovery record says 'look for DANE
records' in the second case the HTTP pinning data is specified.

Note that the discovery parameters could also tell us other things we might
want to know, whether to look for an A or AAAA record for example.

Rules for processing URII records would be as follows:

1) If a URII record set is present it takes precedence over all A, AAAA,
SRV, NAPTR and URI record sets.

2) Unless the specification of the Web Service explicitly states that other
record types are not supported, Web Services MUST specify A, AAAA, SRV or
NAPTR records to support discovery by clients that do not support URII.

The motivation behind this particular dance is to enable optimization and
rationalization of the discovery process as a whole rather than piecemeal
additions that create even more complexity.

The DNS protocol only supports queries for one RR type at a time, there are
multiple areas of interest that would all like to add in a little nugget of
information into the discovery process.

Special pleading is not going to work. There is never going to be consensus
that applications should support DANE or TLS cert pinning or any one of the
dozens of schemes that have been proposed. At the moment everyone
concentrates on the arguments why their pet project should have priority.
That is not productive.

If we are going to get anywhere then it has got to stop being a choice
between extended discovery for DANE vs extended discovery for other
purposes. We have to have one mechanism that can satisfy every requirement
to hook a little bit of extra data into the discovery process if any of
those requirements is going to be satisfied.

-- 
Website: http://hallambaker.com/

---

From: Paul Wouters <[email-masked]>
Date: Sun, 5 May 2013 12:46:10 -0400 (EDT)

On Fri, 3 May 2013, Phillip Hallam-Baker wrote:

> 2) The IETF has also proposed two separate mechanisms for asserting a PKI policy information. There is DANE and there is HTTP
> certificate pinning.

> _service3.example.com URII 10 10 "https://ws.example.com/service3/ pin=foo"

If you trust the DNS for certificate information, then pinning is not
needed. The whole idea behind pinning as I understood it was that people
don't want trust the DNS.

> Note that the discovery parameters could also tell us other things we might want to know, whether to look for an A or AAAA record
> for example. 

And then you can merge in the HASTLS requirements too :P

> Special pleading is not going to work. There is never going to be consensus that applications should support DANE or TLS cert
> pinning or any one of the dozens of schemes that have been proposed. At the moment everyone concentrates on the arguments why
> their pet project should have priority. That is not productive.
> 
> If we are going to get anywhere then it has got to stop being a choice between extended discovery for DANE vs extended discovery
> for other purposes. We have to have one mechanism that can satisfy every requirement to hook a little bit of extra data into the
> discovery process if any of those requirements is going to be satisfied.

I'm unclear what problem you are trying to solve. If you trust the dns,
you don't need pinning. If you don't trust the dns, you cannot trust
your new discovery scheme either?

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 5 May 2013 17:36:07 +0000

> don't want trust the DNS.

I thought pinning had more to do with not trusting rogue/compromised
public CAs, than not trusting DNS.  Or in any case little to do
with not trusting DNSSEC.  But either way, publishing DANE TLSA
scales substantially better than pinning, so I agree that pinning
via DNSSEC makes little sense.

> your new discovery scheme either?

The problem as I understand it is a generalization of DCE's CDS
which supported secure registration and discovery of DCE service
endpoints (which proto,addr,port hosts a particular service UUID).

We have MX records for SMTP and SRV records for Kerberos, LDAP, and now
also POP and IMAP.  We also have NAPTR for SIP.

Now that TLS is potentially subject to one of two PKIs, when one
publishes a service address (whether directly as with a URL in an
HTML <a> element or indirectly via some sort of DNS lookup)
complications may arise when the address specifies TLS without
specifying the relevant PKI.

SMTP is lucky in that (email addresses unlike https URLs) can't
specify TLS, thereforre clients can use DANE to securely discover
support for DANE TLS, and thus have on hand not only the protocol
to use, but also the authentication parameters required to use it.

With other services, (where the endpoint is say an https URL) TLS
is signalled separately from DANE, and clients and servers may need
to support two PKIs in parallel at the same service endpoint.

The simplest solution, if one introduce new DNS-based service
location records, is to note that trusting the DNS is unavoidable,
since that's where one gets service location and security parameters.
Therefore, to the extent that any such new mechanism explicitly
specifies TLS, it should I think require and use some form of DANE
key management (be it TLSA or other forms public keys in DNS)
unconditionally.  With new "better than SRV" records there is no
legacy install base to worry about.

-- 
	Viktor.

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 5 May 2013 19:22:38 -0700

> Viktor wrote:
>
> The simplest solution, if one introduce new DNS-based service location
records,
> is to note that trusting the DNS is unavoidable, since that's where one
gets
> service location and security parameters.

I agree with you, up to this point. Yes, the client has no recourse but to
trust the publisher of the service location, since that publisher could
choose to publish whatever it pleases. But then, we have a layer of
indirection. What if the names published in the SRV record are not related
to the name published of the service? What if these were different domains?

-- Christian Huitema

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 May 2013 00:54:32 +0200

On Sun, May 5, 2013 at 6:46 PM, Paul Wouters <[email-masked]> wrote:

>  _service3.example.com URII 10 10 "https://ws.example.com/**service3/<https://ws.example.com/service3/>pin=foo"
>>
>

No, the main reason they were doing pinning was that they did not want to
be dependent on the vagaries and constraints of the DNS infrastructure or
hostage to deployment of DNSSEC.

This is a way to merge that approach back into a DNS-centric approach in a
clean way.

>  Note that the discovery parameters could also tell us other things we
>> might want to know, whether to look for an A or AAAA record
>> for example.
>>
>

Yes, those too, in fact they are quite easy, specify HTTPS as the transport.

>  Special pleading is not going to work. There is never going to be
>> consensus that applications should support DANE or TLS cert
>> pinning or any one of the dozens of schemes that have been proposed. At
>> the moment everyone concentrates on the arguments why
>> between extended discovery for DANE vs extended discovery
>> for other purposes. We have to have one mechanism that can satisfy every
>> requirement to hook a little bit of extra data into the

It has nothing to do with whether you trust the DNS or not. Trust is not a
binary quality for a start.

The issue is how the application discovers that there is useful information
to acquire. At present a client that is using extended discovery typically
has to perform three parallel queries: A, AAAA, SRV. Adding in DANE makes
four and only provides value if the probability of there being a DANE
record is high enough to make the effort worthwhile.

I am suggesting that instead of making three requests we prune it down to
two, the legacy A record request and an additional request that is
extensible and so can tell us if we need to make additional requests.