Subject: [dane] Discovery Abstraction (The place of SRV)

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 16:56:44 -0400

On Thu, Jun 2, 2011 at 3:20 PM, Matt McCutchen <[email-masked]>wrote:
>
> In my view, the reason PKIX/TLS succeeded is that the tools were widely
> available and braindead easy: urlopen("https://hallambaker.com/").  And
> DANE can be a drop-in replacement, as demonstrated by my prototype.
>

We are in agreement, more or less. The difference being that I am working at
one level higher in abstraction.

My objective is to eventually have a library that can resolve
http://hallambaker.com/ and deliver the best connection offered by the
service that my client library can consume with respect to both security and
robustness.

This then makes it much easier to interface this technology with a scripting
language like perl or tcl or javascript.

The way I would do it is as follows:

0) Starting conditions

Domain to connect to: hallambaker.com
SRV prefix of protocol: _http._tcp
Default port assignment (if defined): 80

1) Resolve DANE1 RR for <domain> hallambaker.com

* If not found then terminate
* If the DANE1 record does not specify greater granularity information then
discovery is complete
* If hallambaker.com was an alias or a wildcard name then set the variable
<canonical> to the canonical name value returned

* if the DANE1 record indicates that the additional data is port based then
set the value of <prefix> to the decimal port number, otherwise set the
value of <prefix> to the SRV prefix.

2) Resolve DANE2 RR for domain <prefix>.<canonical>
* If not found then terminate

This particular approach supports wildcards, aliases and different trust
constraints for different services.

More importantly for SRV fans the DANE1 record can have a flag to say 'use
SRV discovery' or 'use URI discovery'. This allows the use of extended
discovery to be added to legacy protocols that did not originally use SRV.
It also allows the SRV discovery process to be made compliant with alias and
wildcard records.

For a more details description of this approach see:

http://tools.ietf.org/html/draft-hallambaker-esrv-01

<http://tools.ietf.org/html/draft-hallambaker-esrv-01>As a practical matter
I can't see how we can make CAA and DANE work under a single RR format
unless there is a way for DANE to address both generic statements that apply
to the whole domain and service specific statements. It has to be possible
to make a CAA statement that applies to the whole domain.
-- 
Website: http://hallambaker.com/

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 02 Jun 2011 17:31:36 -0400

On Thu, 2011-06-02 at 16:56 -0400, Phillip Hallam-Baker wrote:
> service that my client library can consume with respect to both
> security and robustness.
> 
> This then makes it much easier to interface this technology with a
> scripting language like perl or tcl or javascript. [...]

I would like better service discovery too.  But I still do not
understand what you hope to gain design-wise by coupling DANE with
service discovery.  I explained at
https://www.ietf.org/mail-archive/web/keyassure/current/msg01715.html
why I believe (DNS name, transport protocol, port) is the right set of
inputs to DANE.  It follows that DANE should run after that tuple is
determined, i.e., after any applicable service discovery.  My question
stands: "Can you point to any concrete use cases that would benefit from
your proposal?"

Security-related assertions with purposes closer to the application
level than simple TLS server authentication should be pursued separately
from DANE and indeed may be appropriate to integrate with service
discovery.

> As a practical matter I can't see how we can make CAA and DANE work
> under a single RR format unless there is a way for DANE to address
> both generic statements that apply to the whole domain and service
> specific statements. It has to be possible to make a CAA statement
> that applies to the whole domain.

Yes, DANE needs that too.  One case is stated in
https://trac.tools.ietf.org/wg/dane/trac/ticket/23 , but the
considerations for the general case are not really different.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 17:37:32 -0400

1) Efficiency.

My approach is much more efficient than yours when measured over the whole
transaction. The difference is even greater when the DNS is being used to
deliver more than just keys. Knowing that TLS is offered on a connection at
all is much more important to me than the strength of the key. If the client
can't work out that SSL is required at all the strength of the key is moot.

2) Ease of Administration

My approach is much simpler to manage for the typical site since there is an
option of specifying global properties.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 02 Jun 2011 17:49:43 -0400

On Thu, 2011-06-02 at 17:37 -0400, Phillip Hallam-Baker wrote:
> 1) Efficiency.
> 
> My approach is much more efficient than yours when measured over the
> whole transaction. The difference is even greater when the DNS is
> being used to deliver more than just keys.

Are you talking about performance, economy of design, or what?  In my
mind, the performance issues would have to be pretty stark to outweigh
the design considerations I stated.

> Knowing that TLS is offered on a connection at all is much more
> important to me than the strength of the key. If the client can't work
> out that SSL is required at all the strength of the key is moot.

Indeed, you need both, but it does not follow that they should be
coupled.  HASTLS or such will be a win.  For now, we are getting by with
the https: URI scheme and other out-of-band indications.

> My approach is much simpler to manage for the typical site since there
> is an option of specifying global properties.

As I said, I intend for DANE to have that too.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 18:22:11 -0400

> the design considerations I stated.

I don't see that you have specified anything more than asserting you like
your way better. I don't see that you have given any justification for your
approach at all.

In my view the criteria that are applicable here are functionality,
performance and ease of administration.

What objective criteria are you applying? Could you avoid a reference to an
earlier reply as I have read those and don't see any objective criteria
there.

> the https: URI scheme and other out-of-band indications.

If you want performance then a single framework that can support both types
of data will be more efficient.

> As I said, I intend for DANE to have that too.

Well propose an alternative mechanism for doing so and we can have a bake
off.

But at the moment mine is the only concrete proposal that meets all the
criteria you specify.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 02 Jun 2011 20:31:03 -0400

On Thu, 2011-06-02 at 18:22 -0400, Phillip Hallam-Baker wrote:
> What objective criteria are you applying? Could you avoid a reference
> to an earlier reply as I have read those and don't see any objective
> criteria there.

I agree with your list of functionality, performance, and ease of
administration, though I am de-emphasizing performance for now because I
don't think we have a good idea of how significant the performance
issues will be.  I would add ease of integration with existing tools.

> I don't see that you have specified anything more than asserting you
> like your way better. I don't see that you have given any
> justification for your approach at all.

In the message I previously linked, I asserted that (DNS name, transport
protocol, port) should be the input to DANE because:

(1) The client is bound to know these variables (at least if it does
SNI).

(2) Under the current design of IP, TCP, and SNI and in the absence of
active attacks, the set of certificates that a client might see when
contacting a TLS server is a function of these variables and no others.
Hence there can be no benefit in making the TLSA data a function of
other variables.

I don't see certificate designation in draft-hallambaker-esrv-01.  But
suppose you added it using the existing levels in section 2, namely:

- Domain: (name)
- Service: (name, transport[?], service type)
- Instance: (name, port, transport, service type)

Then there would be no way for existing TLS clients that take the (name,
transport, port) tuple as input to do a DANE lookup.  Such clients
include NSS tstclnt, OpenSSL s_client, and gnutls-cli.  Traditionally,
the port has not been used in the server ID check, but tstclnt in my
modified NSS uses it for the DANE lookup.

> If you want performance then a single framework that can support both
> types of data will be more efficient.

Maybe so.  At this point, it's hard to tell how much it will matter.
We'll have caches in various places, and either scheme in "optimized"
mode would work in a single round trip.

> Well propose an alternative mechanism for doing so and we can have a
> bake off.
> 
> But at the moment mine is the only concrete proposal that meets all
> the criteria you specify.

Right, you got there first.  I don't have a complete proposal that I'm
happy with, but as a starting point consider the following:

If a service type is given, perform service discovery (SRV, ESRV, or
whatever).  Once you have a port, if you are going to use TLS, do a DANE
lookup.  For DANE, and separately for service discovery if it would
start with a prefixed name, canonicalize the unprefixed name first.

On the DNS admin side:

- To make a statement about a whole DNS subtree, use my script (deployed
on mattmccutchen.net but not yet publicly released) that covers the
subtree with DNS wildcards, so that the data will be returned for any
name in the subtree.  As I wrote at
https://trac.tools.ietf.org/wg/dane/trac/ticket/23#comment:2, this is an
ugly solution and I'm hoping for a better one.  I was thinking of having
the client scan the ancestors in DNS, but Ondřej Surý thought that was a
bad idea
(https://www.ietf.org/mail-archive/web/keyassure/current/msg01663.html)

- If you have many names served by the same pool of servers (my favorite
example is *.googleusercontent.com), first collect them with a wildcard
CNAME and put the data at prefix extensions of the target of the CNAME.

-- 
Matt

---

From: Rob Stradling <[email-masked]>
Date: Fri, 10 Jun 2011 10:30:08 +0100

On Friday 03 Jun 2011 01:31:03 Matt McCutchen wrote:
<snip>
> contacting a TLS server is a function of these variables and no others.

Matt, I disagree with "and no others".  The set of cipher suites offered by the 
TLS Client may also influence the set of certificates that the TLS Server 
chooses to send.  For example...

$ openssl s_client -connect tls.secg.org:40023 -cipher RSA 2> /dev/null | grep 
"Certificate chain" -A 3
Certificate chain
 0 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 
1024 Server Certificate/C=CA
   i:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 
1024 Certificate Authority/C=CA
---

$ openssl s_client -connect tls.secg.org:40023 -cipher ECDSA 2> /dev/null | 
grep "Certificate chain" -A 5
Certificate chain
 0 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/ST=Ontario/CN=tls.secg.org ECC 
secp256r1 Server Certificate/C=CA
   i:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC 
secp256r1 Certificate Authority/C=CA
 1 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC 
secp256r1 Certificate Authority/C=CA
   i:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC 
secp256r1 Certificate Authority/C=CA
---

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online