Subject: Re: [keyassure] Don't modify DNS server algorithms

From: Ondřej Surý <[email-masked]>
Date: Tue, 01 Feb 2011 11:10:46 +0100

On 31.1.2011 21:05, John Gilmore wrote:
> Anyone who designs a simple new protocol on the theory that we'll have
> to modify the algorithms in all the DNS servers is pushing their luck.

I don't think that anybody said that the modification of the DNS 
server-side algorithm is a requirement for DANE work.  It could be 
viewed as a nice-to-have optimization (which is same for A+AAAA or any 
other attempts which didn't go through the dnsext), but that's really an 
DNSEXT work and we should not even slightly assume that this will ever 
happen.  (But yes, EDNSx which would allow multiple queries (f.e. just 
in-the-bailiwick) would be nice to have, but it also would have to be 
very carefully designed.)

Anyway everybody please let's stick to the topic which is Issue#1, thanks.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 01 Feb 2011 11:14:57 +0100

On 31.1.2011 17:29, Simon Josefsson wrote:
> Ondřej Surý<[email-masked]>  writes:
>
>> Combination of 1. and 2.:
>> 5. Prefacing the host name with a service name and a port number:
>> (_110._pop.mail.example.com).
>>
>> 6. Same as 5, but with a protocol selector:
>> (f.e. tcp_110._pop.mail.example.com)
>
> I dislike any solution that uses service names (the "_pop"), because I
> haven't seen any explanation what purpose it would serve.  Is there a
> use case for it?

You can have multiple https and multiple pop3s running on the same 
machine?  But you're probably right.

>> And this is an idea I got while reading the archive:
>> 7. Prefacing the host name with a service name and a port number with
>> fallback on every level, ie. all those are valid and looked up and
>> used in this order:
>>   _110._pop.mail.example.com IN TLSA
>>   _pop.mail.example.com IN TLSA
>>   mail.example.com IN TLSA
>>
>> That way we can have quite good flexibility while not making things
>> too complicated (ie. I am able to specify separate certificate for
>> important service running on _443.http.www.example.com and having
>> www.example.com IN TLSA<snake_oil_cert>  for all other certificates at
>> the host name).
>
> This adds roundtrips unless implementations do queries in parallel, and
> the latter creates some extra network packets.  Network traffic is
> cheap, so I kind of like it.

/me too :)

> However I fear some implementations will
> skip the (_443.www.example.com,IN,TLS) query and go directly for the
> (www.example.com,IN,TLS) which kind of destroys the flexibility.

The bad thing is that it doesn't only destroy flexibility, but it also 
destroys the security (the _443.www would be authenticated by www TLSA 
record).  Is this fear of bad implementation shared among other members 
of the DANE?  Isn't that more of issue a security warning, a CVE number 
and force the vendor to fix it?

O.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 1 Feb 2011 13:22:59 +0200

> machine?  But you're probably right.

To be useful that would require multiple services with distinct keys
sharing the same port(!). Without explicit muxing like tcpmux (tcp/1;
who uses that anymore???) it would be seriously fragile (or downright
impossible) with many service pairs (server goes first services,
services that can't be reliably be sniffed).

If you have say 2 HTTPSs and 2 POP3Ss, you could stuff them to say,
ports 80 (HTTP vs. TLS can be sniffed), 443 for HTTPS and
995 and 996 for POP3S.

That would give four ports, 80, 443, 995 and 996 with no conflicts
that would need service labels.

So I don't see any need for service labels unless supporting seriously
obsolete stuff like tcpmux. Port labels are enough.

-Ilari

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 01 Feb 2011 09:01:23 -0500

On Thu, 2011-01-27 at 12:14 -0500, Warren Kumari wrote: 
> Ondrej and I would like to call #1 (and #17) soon, but would like to  
> get a little clarification / restatement of folks views...
> 
> When looking up TLSA records, would folk prefer querying for:
> 
> 1: Just a hostname (mail.example.com) and pick from the returned  
> records.

Let's subdivide:
1a: Each record is acceptable for any port.
1b: Each record says which port it is for. 

> 2: Looking up a name prefixed with a port (_443.www.example.com) or  
> port and proto (_443._tcp.www.example.com).
> An application could optimize beyond this, but this defines what is  
> required to look up.

Philosophically, I prefer 2 including the transport protocol (to spell
everything out) because the client asks for precisely the information it
needs.  Compared to 1b, the different owner names might make it easier
for the various services to automatically administer their own TLSA
records (as Phill envisioned) without stepping on each other.

The only problem is making 2 work with CNAMEs and wildcards, the same
problem faced by SRV.  (IMO, it's a pity this interaction wasn't
specified the way we want originally, but there might be other
considerations I'm not aware of.)  Phill described some grand plans.  I
would just propose that the client check for CNAME at www.example.com or
TLSA at _443._tcp.www.example.com in unspecified order (they should not
both exist), and if a CNAME at www.example.com is found, query the
prefixed version of the target name.  The client would not honor a CNAME
at _443._tcp.www.example.com.  DNS admins who want to apply TLSA to a
wildcard set of host names can use a wildcard CNAME first and then put
the TLSA at the target name.

I am unhappy with 1a.  I wouldn't like to build the assumption that
ports at the same host name are at the same security level into DANE,
and I really don't see what's so hard about specifying the port on which
you are going to use the certificate.  And quite apart from security
levels, binding a different certificate to each port is the only way to
prevent connection diversion among ports at the TLS level (where it
should be prevented) since SNI currently does not do ports.

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Feb 2011 13:51:15 -0500 (EST)

> obsolete stuff like tcpmux. Port labels are enough.

And those can also be avoided by using a separate FQDN for seperate
security level services pointing to the same A record.

I have not been convinced by the artificially created examples we need
any sub-labelling.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Feb 2011 13:54:51 -0500 (EST)

> ports at the same host name are at the same security level into DANE,

insecure.example.com. IN A 1.2.3.4
secure.example.com. IN A 1.2.3.4
insecure.example.com. IN TLSA x snakeoilcert
secure.example.com. IN TLSA x securecert

Now you have different security levels to the same host on 1.2.3.4,
without the added parsing/complexity/uglyness of _modifiers.

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 02 Feb 2011 09:43:18 +0100

> security level services pointing to the same A record.

Yes, they can be avoided, but I don't think we want to push specific 
work with DNS to the DANE users.

> I have not been convinced by the artificially created examples we need

I know that you're not.  Hence the call for consensus, so we know the 
opinion of the working group, and we can move forward.

Ondřej

---

From: James Cloos <[email-masked]>
Date: Wed, 02 Feb 2011 15:56:29 -0500

>>>>> "MM" == Matt McCutchen <[email-masked]> writes:

MM> I would just propose that the client check for CNAME at www.example.com
MM> or TLSA at _443._tcp.www.example.com in unspecified order (they should
MM> not both exist), and if a CNAME at www.example.com is found, query
MM> the prefixed version of the target name.  The client would not honor
MM> a CNAME at _443._tcp.www.example.com.  DNS admins who want to apply
MM> TLSA to a wildcard set of host names can use a wildcard CNAME first
MM> and then put the TLSA at the target name.

Those are not awful.  They probably make prefixes usable.

(And perhaps should be used for existing SRV usages, too.)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 3 Feb 2011 13:51:47 +0100

> without the added parsing/complexity/uglyness of _modifiers.

Hmm, and what's the canonical hostname for 1.2.3.4 in this case ?
Thinking over it, and hearing the answers, I think I'd vote for the

_port._protocol.host.tld SRV

solution.
My rationale:
Everything can be configured both for single hostnames and multiple
ones, but it takes less records in a zone for this sulution compared to
the TLSA solution.

"good looks", "ugliness" or "readability" are no criteria for me.
Smaller size of the zone is.

For the SRV solution, I only need 1 A and 2 SRV records makes 3.
For the TLSA sollution, I need 2 A and 2 TLSA records makes 4.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 03 Feb 2011 06:28:51 -0800

> For the TLSA sollution, I need 2 A and 2 TLSA records makes 4.

Just to be clear: are you proposing that TLSA records can *only* be 
returned in SRV requests, and that they can't be requested on their own 
using "_port._protocol.host.tld TLSA"?

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 3 Feb 2011 16:10:00 +0100

> using "_port._protocol.host.tld TLSA"?

I was only comparing the "_port._protocol.host.tld" vs the "hostname per
service offered" as solution for the question Ondřej originally asked
about which QNAME to use.

Which RRTYPE to use is the next question Ondřej is going to pose I believe:

"I was planning to open separate issue# on what to include into DNS name
after we get consensus on that we want to have solution based on
prefix+hostname in QNAME. As opposed to just having hostname in QNAME,
or some interaction with SRV record. I felt that if we slowly narrow the
topic it will not divert that much in the mailing list."

- -- 
Antoin Verschuren

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 03 Feb 2011 20:16:22 -0500

> without the added parsing/complexity/uglyness of _modifiers.

- There is no parsing, only construction.  The client gets a TLSA record
back by virtue of constructing the _port._transport.host string the same
way the DNS admin did when publishing the data.

- I do not see what is complex or ugly about stating the transport
protocol and port number your service listens on.  This way, TLSA layers
neatly onto our transport protocols to provide the abstraction of an
authenticated (D)TLS connection over Foo Transport Protocol to an
arbitrary (DNS name, port) pair; generic TLS tools such as stunnel can
take advantage of this.  In contrast, using subdomain names that are not
standardized anywhere and thus liable to be chosen differently for the
same service type (smtp.foo.com, mail.bar.com, ...) has the potential to
be ugly, and using the same certificate for multiple services at the
same name exposes you to cross-protocol attacks.

If the admin does not want to type out the _port._transport.host format,
surely there will be GUIs like the ones for port forwarding on home
routers today that let him pick the transport protocol and service type
(assuming the default port) from a menu.  But I really don't think this
is an imposition.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 03 Feb 2011 20:30:30 -0500

On Thu, 2011-02-03 at 20:16 -0500, Matt McCutchen wrote:
> using the same certificate for multiple services at the

To clarify: even if the services are at the same security level, the
case in which a MITM diverts the connection to a service other than the
one the client wanted should be caught at the TLS level.

TLS is designed to be capable of providing a strong guarantee: if your
connection goes through, you are talking to the service you wanted.
Let's not weaken this by being sloppy with the naming.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 03 Feb 2011 23:11:14 -0500

> (And perhaps should be used for existing SRV usages, too.)

That's what I was hoping to achieve.  I appreciate the vote of
confidence.  :)

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Feb 2011 21:06:11 +0100 (MET)

> Let's not weaken this by being sloppy with the naming.

You're confusing two things here:

Per section 1. Introduction, last sentence of all existing TLS specs,
the TLS protocol is completely agnositc about naming, and technically,
completely agnostic about PKIX, X.509 certs and certificate paths.

Many implementations of TLS go far beyond the TLS protocol spec and
provide complimentary code to applications that performs server
endpoint identification as described in rfc-2818 and performs
PKIX cert path validation per default, offering application
callers possibilities to obtain details and override negative
results from PKIX processing.

If there is a possibility for cross-protocol attacks, then this
is not a result of a failure within TLS, but a failure of the
apps in correctly identifying and distinguishing TLS server endpoints.

In the traditional approach of server endpoint identification
described in rfc-2818, endpoints are distinguished and identified
at the granularity of "hostname".  TLSA records of the form

   _443._tcp.www.example.com   TLSA   (server-cert|server-cert-hash)

would allow to distinguish server endpoints at the granularity
(port+protocol+hostname).  With this scheme it is possible
to prevent "cross-protocol attacks" by assigning distinct
credentials to distinct protocols.  (There is no protection
if the services share a single credential, though).

The big advantage of doing this in DNS rather than within the
server/service certificate is that it is easier on the
admin side--you don't have to rekey the service when you want
to run it on a different port.  TCP ports are a very limited
resource that is assigned on a first-come-first-served basis,
and it is not uncommon to have multiple distinct instances
of a particular service/protocol listening on distinct ports
of a single host(name).

-Martin

---

From: James Cloos <[email-masked]>
Date: Fri, 04 Feb 2011 19:38:41 -0500

>> (And perhaps should be used for existing SRV usages, too.)

MM> That's what I was hoping to achieve.  I appreciate the vote
MM> of confidence.  :)

I wanted to think about it some more, but I do agree that what you
propose is the right solution.

-JimC

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 04 Feb 2011 22:43:44 -0500

On Fri, 2011-02-04 at 21:06 +0100, Martin Rex wrote: 
> You're confusing two things here: [...]

I did not intend to do so.  I understand that naming and certificate
acceptance criteria are outside the scope of TLS per se.  By the "TLS
level", I meant the facility that provides TLS connections with server
authentication to applications.

> TLSA records of the form

Right.  If SNI would include the transport+port, having the server check
that information would be another way to prevent the attacks.  However,
I'm thinking it may be better design for each service to have a
credential valid only for the name+transport+port combinations it is
capable of serving.  This will hopefully be less of a PITA to arrange
with DANE than under the traditional public CA system.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 5 Feb 2011 12:53:39 -0500

> propose is the right solution.

I think this solution can be made to work, but it is not the best solution
that we can achieve.

In addition to the IPv4 exhaustion issue, the IETF has been facing a port
exhaustion issue as well for some time. And so there has been a push to move
to use DNS protocol prefixes to fix that problem.

I see two very distinct sets of requirements by application protocol:

1) How to deal with widely deployed legacy protocols requiring low latency
connection establishment.

2)  How to deal with new protocols and protocols that do not require
optimization

The first is essentially use of HTTP for Web browsing. There are other
protocols in use, but none where the impact of DNS connection establishment
is anywhere near a dominant impact on performance.

So it really is quite appropriate to treat HTTP as a special case, indeed
HTTP specifically for use in Web Browsing as opposed to using it as a Web
Services transport, firewall bypass protocol or whatever.

As far as mechanism goes, I see two distinct conditions to support

1) Where the connection is established by the DNS name directly

2) Where a prefixed discovery mechanism is involved.

The scheme I propose has essentially the same performance characteristics as
Matt's, I just have slightly different semantics, instead of always looking
for the prefix record, I always look for a record at the unprefixed domain
that may tell me that advanced discovery (SRV, NAPTR, URI) is in use and
that there is more detailed data available or may tell me that there is no
additional data to be found.

It is of course still possible to perform optimistic pre-fetching of the
prefixed records at the start of discovery under my scheme as well.

I don't see this as a 'grand design', I just see it as fitting in with the
existing DNS discovery architecture rather than complicating it. I give the
administrator a straightforward binary choice, either do not differentiate
between trust criteria for services at all, or alternatively employ advanced
discovery to do so.

The clients that are going to make use of these keys are going to have to
have custom code anyway.

One issue I do see with the port prefix approach is that it does not make
much sense with the existing scheme employed to support multi-homing of Web
hosts - multiple A records. For example, if example.com has four hosts, it
will have something like:

$origin example.com
www  CNAME example.com
.    A 10.0.0.1
.    A 10.0.0.2
.    A 10.0.0.3
.    A 10.0.0.4

So now we add a record

_80._http  TLSA  (whatever)

Which binds to a specific port on a non specific IP address. That does not
make much sense to me.

Of course we are trying to get away from using round robin discovery, it is
not a very good approach for load balancing. But the port prefix approach is
not playing nice with the existing proposed alternatives.

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

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 05 Feb 2011 15:48:41 -0500

On Sat, 2011-02-05 at 12:53 -0500, Phillip Hallam-Baker wrote:

> I think this solution can be made to work, but it is not the best
> solution that we can achieve.
> 
> In addition to the IPv4 exhaustion issue, the IETF has been facing a
> port exhaustion issue as well for some time. And so there has been a
> push to move to use DNS protocol prefixes to fix that problem. [...]

> The scheme I propose has essentially the same performance
> characteristics as Matt's, I just have slightly different semantics,
> instead of always looking for the prefix record, I always look for a
> record at the unprefixed domain that may tell me that advanced
> discovery (SRV, NAPTR, URI) is in use and that there is more detailed
> data available or may tell me that there is no additional data to be
> found.
> 
> It is of course still possible to perform optimistic pre-fetching of
> the prefixed records at the start of discovery under my scheme as
> well.
> 
> I don't see this as a 'grand design', I just see it as fitting in with
> the existing DNS discovery architecture rather than complicating it. I
> give the administrator a straightforward binary choice, either do not
> differentiate between trust criteria for services at all, or
> alternatively employ advanced discovery to do so.

I agree that there are problems to be solved with discovery.  What I
don't understand is what you hope to gain by entangling discovery with
DANE.

In my view, binding credentials to the hostname+transport+port tuple to
which the client connects is ideal because:

1. All clients we care about, including generic tools like stunnel and
openssl s_client, go through this stage.  It will be straightforward to
modify them to pass the information to the TLS library.  The library
could even have a single API call "dane_tls_connect(hostname, port)"
that both connects the socket and saves the endpoint info for later
checking, giving us the "secure TCP" primitive we never had (likewise
for other transports), but I suspect there must be reasons why this
approach is not already taken with the hostname.

2. With current SNI, this tuple is exactly what is available to the
server when it chooses a credential to present.  Thus, in the absence of
active attacks, the set of credentials that clients might see when
making a connection is a function only of this tuple.  Finer
distinctions cannot meaningfully be made in DANE.  If people want to
virtual-host multiple service types for the same hostname on the same
port and demultiplex them at the TLS level, that would require support
for service types in both SNI and DANE, but I highly doubt that will
become important.

Can you point to any concrete use cases that would benefit from your
proposal?

> The clients that are going to make use of these keys are going to have
> to have custom code anyway.

Not really.  All one would have to do, using NSS as an example, is
modify SSL_SetURL (a misnomer; it takes only the hostname) to also take
the transport and port and modify the applications to pass that
information.

> One issue I do see with the port prefix approach is that it does not
> make much sense with the existing scheme employed to support
> multi-homing of Web hosts - multiple A records. For example, if
> example.com has four hosts, it will have something like:
> 
> $origin example.com
> www  CNAME example.com
> .    A 10.0.0.1
> .    A 10.0.0.2
> .    A 10.0.0.3
> .    A 10.0.0.4
> 
> So now we add a record
> 
> Which binds to a specific port on a non specific IP address. That does
> not make much sense to me.

Agreed, that is a little goofy.  But it's not a reason to prefer your
combined DANE + discovery proposal because SRV in combination with DANE
as I propose will solve the problem equally well.  And I don't think
it's worth bending over backwards to solve this in DANE if the
application is not prepared to adopt a discovery mechanism.

-- 
Matt