Subject: Re: [dane] CNAMES and Wildcards

From: Leif Johansson <[email-masked]>
Date: Mon, 01 Aug 2011 10:47:14 +0200

> Explain to me what the problem is, ideally by walking through an
> example.

+1 I would love to see an example explaining the issue!

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Aug 2011 15:47:25 -0400

> +1 I would love to see an example explaining the issue!

The issue is that DANE has to use prefixed DNS records and these do not work
in the way that we would want them to.

In particular DNS does not allow wildcards of the form _prefix.*.example.com

Aliases are another problem. If a web site has an alias to map
www.example.com to another domain name we want the user who is following the
alias to still have the security benefit

Aliases are very widely used in the Web world. In most cases the DNS
administration and Web hosting administration are separate (even if handled
by the same company). If a customer edits the 'domain name' of their web
site they are actually changing a CNAME to it.

In other words, if we don't get this right nobody will be able to use DANE
without major changes to their infrastructure which most of the Web hosting
companies are not capable of doing.

For example, a common web hosting approach:

www.hallambaker.com               CNAME  host293939.hostprovider.com
www.dotcrimemanifesto.com   CNAME doftuturemanifesto.blogspot.com

I have two sites there, one is hosted locally by my DNS provider, another is
a blog on blogger.

I don't want to be managing the crypto for either on my DNS provider account
as it is not plugged into the SSL management scheme at either hosting site.
The CNAME is simply a pointer to where the action is.

The problem is that the above will only work for TLSA if I also create
CNAMEs to map the subordinate nodes.
On Sun, Jul 31, 2011 at 9:44 PM, Andrew Sullivan <[email-masked]>
 wrote:

> On Sun, Jul 31, 2011 at 07:34:08PM -0400, Phillip Hallam-Baker wrote:
>
> > Sending text would be appropriate if the issue was a disagreement over
> the
> > precise wording. In this case we do not appear to have agreement on the
> > principle so asking for wording seems premature.
>
> Well, then, perhaps you can explain to me what it is that is wrong
> about "TLSA is another RRTYPE like all other RRTYPES, and it resolves
> in exactly the same way."

>From an implementation point of view the above does not give developers
enough information to have a chance of creating an inter-operable
implementations.

Your language looks simple because you are ignoring the problem entirely.
You are not telling the client what to do when an alias is discovered. You
are not even giving them a definite citation for where they should find out
what to do.

I don't think we need to agree on language. But we do need to agree on a
specification that sets out what steps the client is required to take to
resolve the DANE records for a specific address and in particular what steps
to take when a CNAME or a DNAME is encountered.

For example:

Resolution of TLSA records.

A relying party resolves the TLSA records for the Internet service at port X
of domain D as follows:

1) A prefix label P is formed by appending the underscore '_' character
(ASCII ...) to the decimal value of the port number.

2) The RP issues a query for the TLSA Qtype at P.D

2a) If the query returns a result, the resolution process is complete and
the result is the records returned.

3) The RP issues a query to determine if D is aliased. To do this the RP MAY
issue a query for any Qtype at D.

3a) If the query result does not contain a record indicating an alias
mapping, the resolution process is complete and the result is null.

3b) The query result returns an alias mapping D to A.

4) The RP issues queries for QTYPE TLSA at P.A and for any Qtype at A

4a) If the query for the TLSA record returns a result, the resolution is
complete and the result is the result of the query, otherwise

4b) If the query for A returns an alias mapping to AA and the alias count
limit has not been reached, the RP sets A = AA and repeats step 4

4c) Otherwise the result of the resolution is null.

It looks a little complex set out but it is pretty straightforward in
practice and can be implemented by any DNS interface library that allows
arbitrary DNS records to be resolved. I do not believe that there is any
library out there that will allow you to obtain a TLSA record without being
able to resolve CNAME.

In practice what I would expect to see is:

www.example.com CNAME example.com
_443._port.example.com TLSA fooooo
example.com A 10.1.1.1

Resolve D=example.com X=443   [P= _443._port]

Parallel:
   example.com ? QTYPE=A
      example.com A 10.1.1.1
  _443._port.example.com TLSA ? QTYPE=TLSA
      _443._port.example.com TLSA fooooo

Resolve D=example.com X=443   [P= _443._port]

Parallel:
   www.example.com ? QTYPE=A
      www.example.com CNAME example.com
  _443._port.example.com TLSA ? QTYPE=TLSA
      <null>

Parallel:
   example.com ? QTYPE=A
      example.com A 10.1.1.1
  _443._port.example.com TLSA ? QTYPE=TLSA
      _443._port.example.com TLSA fooooo

The overhead of doing this is irrelevant. The process only requires the RP
to do more work in the case that they would otherwise fail.

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

---

From: Martin Rex <[email-masked]>
Date: Mon, 1 Aug 2011 23:23:58 +0200 (MEST)

I have an extremely bad feeling about the CNAME/DNAME discussions.
What has been proposed/discusses appears to create a security gap
in the DANE architecture, and would make things with DANE work opposite
to without DANE, which is something that looks very dangerous to me.

In all of the example usage scenarios described in rfc6125,
CNAME are irrelevant to the verification of the server certificate,
they're only a less efficient way to obtain an IP-Address for the
purpose of connect()ing the server, they're otherwise invisible/irrelevant
to the server endpoint identification.

The idea and architecture behind DANE is either to provide an independent
confirmation from the authoritative domain owner about a server certificate
from a commercial CA, or to have the DNS domain admin directly provide
the confirmation of a server's certificate and cut the commercial CA
out of the loop (obviating the domain admin to ask a commercial CA
to assert that the domain owner requested a specific server certificate).

With DANE, it is the domain admin who has to add TLSA records into
his zone for his servers, performing a similar role to the CA when
it issues server certificates, and only TLSA records for the original name
should be looked at by DANE clients.

With the original model, if a domain admin wants to outsource a server
to some hosting company, the domain owner would either have to obtain
the server certificate and pass it along to the hosting company, or
pass along an authorization from the DNS admin to the the hosting company
to obtain a server certificate for the outsourced server.

If a DANE-using DNS admin wants to outsource a web-server to a hosting
company, the DNS admin will also have to publish the relevant TLSA
record in his domain, independent of whether the DNS admin creates
the server keypair himself and passes the credential along to the
hosting service or wether the hosting service creates the keypair
and passes the certificate back to the DNS admin for creation
of the TLSA record.

The DNSSEC verification for TLSA only needs to cover the TLSA record
in that case (A records are irrelevant, because IPs are untrusted
in absence of IPsec and presence of NATs anyways).  

(btw. has the original limitation that a CNAME must not point to
 another CNAME been removed from DNS?)

The idea that TLSA is retrieved for what a CNAME resolves to would
make current practise/architecture considerably differ from DANE.

And I might prefer a "well-known" fallback label for DANE to a DNS "*"
wildcard in order to specify a domain-wide preference of a (PKIX) CA.

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 2 Aug 2011 00:35:37 +0200

On 31. 7. 2011, at 20:54, Phillip Hallam-Baker wrote:

> 
> 
> On Sun, Jul 31, 2011 at 12:12 PM, Andrew Sullivan <[email-masked]> wrote:
>> Dear colleagues,
>> 
>> I am sorry I was unable to make the DANE meeting on Friday either in
>> person or remotely.  I was called away on urgent family business.
>> Nevertheless, I have read the document.  I have yet to read a complete
>> and coherent critique of the current text in the document.  In particular,
>> 
>> On Sun, Jul 31, 2011 at 11:23:31AM -0400, Phillip Hallam-Baker wrote:
>> >
>> > By fully addressed I mean that there is a defined algorithm for resolving
>> > DANE DNS RRs that is compatible with administrative use cases for use of
>> > Wildcare and alias (CNAME, DNAME) records.
>> >
>> > The current appendix suggests options but does not mandate a particular
>> > behavior. Thus DNS administrators deploying DANE cannot rely on these
>> > records actually working.
>> 
>> that requirement is completely bogus.  DNS zone operators have and
>> have always had a wide degree of operational freedom with their zones.
> 
> They can stuff records in zones.
> 
> But they can't predict what effect the records will have unless the resolution semantics are defined. And if they can't predict the effect of a configuration they can't use it.

Can you please send an examples where and when do you think the resolution semantics is not defined.  With my DNS glasses on I am just unable to see the problem you are referring to.  CNAME is an internal DNS mechanism and should not be interpreted by end clients, just by DNS resolvers.  Thus the DANE client asks for TLSA at _prefix.example.com and gets the result (or NXDOMAIN) with no knowledge of CNAMEs at all (and the knowledge is not needed).

I clearly doesn't understand what is the case you are worried about.  Could you please clarify more?  Use case or an example would be much appreciated, so we don't get entangled into the words.

>  
>> The above seems to suggest that DANE might try to require one and only
>> one way to use DNAME and CNAME records (not to mention wildcards) in a
>> zone in the presence of RRTYPEs that are the result of DANE work.  But
>> we don't get to make those rules.  All we can do is say, "Here's what
>> you need to take into consideration."  It's the operator's zone.  S/he
>> will do as s/he pleases.  All we can do is suggest tactics to maximize
>> interoperation.
> 
> What is at issue here is a requirement for client application developers.
> 
> The operator can't make an informed decision if different client take different approaches.
> 
> That is why it is a standards issue.

I feel you are probably right that we need to be more specific how the clients should behave (aka just ask for _prefix.example.com).  However I propose that we put this into the DANE operations document the WG agreed to work on instead into the DANE protocol document.

The chairs will work on starting the work on this issue shortly.

O.
P.S.: Sorry for not wrapping.  If somebody knows how to force Mail.app to wrap lines, please send me the hint off-list.
--
 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: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Aug 2011 18:36:35 -0400

That is not how it works in practice with DV certs and there are very good
reasons why 6125 is different.

Reason #1

With a traditional DV cert the objective is to secure the domain name that
the user originally typed in. In other words, user types in www.example.com,
that is the domain that is attested to by the EE cert.

If www.example.com is CNAME to host782832.hostserve.net, we don't want a
cert for hostserve.net appearing in browser chrome. And that trumps use
cases we might otherwise want to support but can't because we can't
differentiate them.

But in the most common hosting case, the customer pays for the cert and
never touches it. The cert is created at the hosting co and never leaves. So
your administrative example does not reflect how certs are managed in the
real world.

Reason #2

RFC 6125 is the way it is because we didn't have deployed DNSSEC at the
time. It is a description of a historical approach.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Aug 2011 18:37:29 -0400

Really, the description of the FSM for resolving records to go in the
OPERATIONS document?

Are you serious?

On Mon, Aug 1, 2011 at 6:35 PM, Ondřej Surý <[email-masked]> wrote:

> > But they can't predict what effect the records will have unless the
> resolution semantics are defined. And if they can't predict the effect of a
> configuration they can't use it.
>
> Can you please send an examples where and when do you think the resolution
> semantics is not defined.  With my DNS glasses on I am just unable to see
> the problem you are referring to.  CNAME is an internal DNS mechanism and
> should not be interpreted by end clients, just by DNS resolvers.  Thus the
> DANE client asks for TLSA at _prefix.example.com and gets the result (or
> NXDOMAIN) with no knowledge of CNAMEs at all (and the knowledge is not
> needed).
>
> I clearly doesn't understand what is the case you are worried about.  Could
> you please clarify more?  Use case or an example would be much appreciated,
> so we don't get entangled into the words.
>
> >
> I feel you are probably right that we need to be more specific how the
> clients should behave (aka just ask for _prefix.example.com).  However I
> propose that we put this into the DANE operations document the WG agreed to
> work on instead into the DANE protocol document.
>
> P.S.: Sorry for not wrapping.  If somebody knows how to force Mail.app to
> wrap lines, please send me the hint off-list.
> --
>  Ondřej Surý

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 2 Aug 2011 00:46:40 +0200

On 1. 8. 2011, at 21:47, Phillip Hallam-Baker wrote:
> A relying party resolves the TLSA records for the Internet service at port X of domain D as follows:
> 
> 1) A prefix label P is formed by appending the underscore '_' character (ASCII ...) to the decimal value of the port number.
> 
> 2a) If the query returns a result, the resolution process is complete and the result is the records returned.
> 
> 3) The RP issues a query to determine if D is aliased. To do this the RP MAY issue a query for any Qtype at D.
> 
> 3a) If the query result does not contain a record indicating an alias mapping, the resolution process is complete and the result is null.
> 
> 4a) If the query for the TLSA record returns a result, the resolution is complete and the result is the result of the query, otherwise
> 
> 4b) If the query for A returns an alias mapping to AA and the alias count limit has not been reached, the RP sets A = AA and repeats step 4
> 
> It looks a little complex set out but it is pretty straightforward in practice and can be implemented by any DNS interface library that allows arbitrary DNS records to be resolved. I do not believe that there is any library out there that will allow you to obtain a TLSA record without being able to resolve CNAME.
> 

I still don't understand why you are so worried by saying:

If you want to secure the www.example.com and example.com you need to have TLSA at both of them.  The current doc is clear on that:

   ; TLSA record for original domin has CNAME to target domain
   ;
   sub5.example.com.          IN CNAME sub6.example.com.
   _443_tcp.sub5.example.com. IN CNAME _443_tcp.sub6.example.com.
   sub6.example.com.          IN A 10.0.0.0
   _443_tcp.sub6.example.com. IN TLSA 1 1 536a570ac49d9ba4...

Your proposal changes the semantics of how the CNAME is interpreted by applications (currently it should not be interpreted at all) and from my viewpoint it doesn't solve any protocol problem.  The problem can be easily solved by provisioning.  And I have seen more then one lengthy argument on DNSEXT that the DNS should not solve the provisioning problems.

Although my position is still the same.  I want to see this clearly stated and explained in the operational document, so it leaves no doubts what the implementors, operators and domain owners should do.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 2 Aug 2011 00:54:29 +0200

On 2. 8. 2011, at 0:37, Phillip Hallam-Baker wrote:

> Really, the description of the FSM for resolving records to go in the OPERATIONS document?
> 
> Are you serious?

I am serious.  I think that current wording in the draft:

   The TLSA RR is not special in the DNS; it acts exactly like any other
   RRtype where the queried name has one or more labels prefixed to the
   base name, such as the SRV RRtype [RFC2782].  This sometimes causes
   confusion for some developers when using DNS aliasing and wildcards.

clearly defines the behaviour from the DNS view.  From DNS point of view there is nothing special about the TLSA record.  DANE wants only one thing from DNS - the new RRtype.  That's all, no more jingles and bells are needed, since the rest will be handled by standard behaviour of the DNS.

However we can go further and explain it more in the operations document, where I think explanatory stuff belongs.

O.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Aug 2011 16:38:03 -0700

> 4c) Otherwise the result of the resolution is null.

Does steps 3 and 4 mean that, if the owner of D does not put in a TLSA record, the owner of A can put in such a record and it will be accepted by the querying party, even if the owner of D doesn't want a TLSA record for their zone?

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Mon, 1 Aug 2011 23:29:45 -0400

> On Aug 1, 2011, at 12:47 PM, Phillip Hallam-Baker wrote:
<snip>
> Does steps 3 and 4 mean that, if the owner of D does not put in a TLSA
> record, the owner of A can put in such a record and it will be
> accepted by the querying party, even if the owner of D doesn't want a
> TLSA record for their zone?

Yes.

I understand that this allows the owner of A to present a completely
different certificate of its own devising instead of a cert provided by
D if D doesn't use DANE to prevent that (maybe the owner of D doesn't
know about DANE or can't use it due to lack of software support).

But what I don't understand is what benefit that gives to the owner of
A that damages the owner of D?  Most things I can think of could be done
even without DANE. Maybe it's normal practice for the owner of D to
provide an HSM with the certificate, and this would allow the owner of A
to use a less-secure key? Still, I'd think that contracts could address
this, or monitoring, or something else.  Even if the owner of D can't
use TLSA for some reason, they can always redirect/withdraw the CNAME.
After that, the the TLSA record in A will be useless for representing D.

Even if it were a problem, I don't know how we'd fix it. Adding support
for a NULL TLSA record provides no benefit, because that's just as
opt-in as the above.  Requiring a TLSA record at the source breaks
wildcards. Using some kind of wildcard DNAME for this doesn't work
because the DNAME doesn't cover the node itself (need BNAME or the like
for that). I suppose we could say that you must check the source and
wildcard support requires (still-draft) BNAME, but that will certainly
hurt the deployment prospects for DANE.

-- 
Scott Schmit

---

From: Scott Schmit <[email-masked]>
Date: Tue, 2 Aug 2011 00:11:20 -0400

On Tue, Aug 02, 2011 at 12:54:29AM +0200, Ondřej Surý wrote:
> clearly defines the behaviour from the DNS view.  From DNS point of
> view there is nothing special about the TLSA record.  DANE wants only
> one thing from DNS - the new RRtype.  That's all, no more jingles and
> bells are needed, since the rest will be handled by standard behaviour
> of the DNS.
> 
> However we can go further and explain it more in the operations
> document, where I think explanatory stuff belongs.

I disagree. The concern isn't that an operator will do:

a.example CNAME b.example
b.example AAAA 2001:db8::1
_443._tcp.b.example TLSA bstuff

and not realize that a query for TLSA at _443._tcp.a.example will return
NXDOMAIN instead of "bstuff".

The issue is that:
1) the user & developer don't know if the above should result in "DANE's
not in use, fall back to normal processing" or if the CNAME should be
followed and the prefix checked there
2) the user & developer don't know what will happen in this case:

a.example CNAME b.example
_443._tcp.a.example TLSA astuff
b.example AAAA 2001:db8::1
_443._tcp.b.example TLSA bstuff

2a) Failure (because the records contradict)?
2b) Fallback (because the records contradict)?
2c) A wins? ("Because it owns the CNAME")
2d) B wins? ("Because that's where the server is & is more likely to be
right")

3) if there's a chain of CNAMEs, what then? First hit? Last hit? All
must match? All must match & be present? Pick one at random?

In other words, nobody is asking about wildcarding or aliasing the TLSA
record itself (the focus of Appendix A). We're wondering what happens if
you wildcard or alias the name the TLSA record is for (the subject).
This is what the wildcard and redirection requirements in the use case
document should be about, though the wording fails to make that clear.

This is a protocol question, not an element of deployment advice. Well,
it can be both, but it has to be clear in the protocol first.

Like I've said before, the best option seems to be "follow the CNAME
chain of the subject to an address record, check the prefix for each
name, and use the first TLSA record you find."

-- 
Scott Schmit

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 2 Aug 2011 07:43:08 +0200

> followed and the prefix checked there

Why would the developer even consider that, given the current text in the draft?
The developer will do something like getrrsetbyname(_443._tcp.a.example, TLSA) and get back NXDOMAIN. Trying to detect the end of the CNAME chain requires a lot more work.

> 2d) B wins? ("Because that's where the server is & is more likely to be

What happens depends on what name the user started with - this is a perfect valid scenario for TLS when using SNI (RFC 4366) and a & b has different certs (even though they live on the same endpoint).

> must match? All must match & be present? Pick one at random?

DANE works just like any other application using DNS - nothing special here. DNS is QNAME/QCLASS/QTYPE -> ANSWER. You do NOT look at stuff in the middle of that process.

> name, and use the first TLSA record you find."

No other protocol is using this approach, it is not easy to implement and it is not best current practice for developers.

	jakob

---

From: Leif Johansson <[email-masked]>
Date: Tue, 02 Aug 2011 10:30:37 +0200

> in the way that we would want them to.

After having read the threads on this I think I understand that the
problem is really that you have requirements on DANE beyond what is
provided by DNS currently: support for general CNAME and wildcard-
based delegation.

While these requirements may be interesting I'm not sure why they
are particular to DANE. Many uses of SRV records would seem to have
the same "problem" for instance.

	Cheers Leif

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Aug 2011 08:22:43 -0400

On Tue, Aug 2, 2011 at 4:30 AM, Leif Johansson <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

1) SRV is a form of alias so the issue there is not so critical, the
following records have similar effect:

www.example.com  CNAME alias.example.com
www.example.com  SRV 1 1 80 alias.example.com

2) Use of SRV has in practice been made much more restrictive than we would
wish precisely because it does not address these issues as we would wish.

3) The DNS protocol considers prefixing a name to create a completely
different name. That is certainly not the semantics that use of prefixes is
trying to create.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 02 Aug 2011 15:04:38 +0200

> www.example.com  SRV 1 1 80 alias.example.com

But that is not the common use of SRV records - a more representative
example would be one for the XMPP server for a domain:

_xmpp-server._tcp.example.org IN SRV 5 0 5269 xmpp.example.com

Evidently users have learned to live with adding not only one but
multiple entries like that to their domain (look at any zone enabled
for google apps for instance).

Note that in this case there are even comparable security implications
since the XMPP call-back server-2-server authentication relies on
those SRV records.

I re-iterate: how is the use of SRV records for locating XMPP servers
fundamentally different from TLSA?

	Cheers Leif

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 2 Aug 2011 14:21:28 +0100

Hi Folks,
 I'm sure I will regret this, but sign me up as yet another person who has no idea what PHB sees is a problem.

Your first comment on SRVs seems plain wrong, so I guess I must be misunderstanding.
[example of functional CNAME is:: dig news.bbc.co.uk A. I would not expect
 the same effect in my browser if they had put an SRV at the same owner]

Your second one invokes a "we" and "wish", but it is really not clear who we are
 and what we wish in common.

Your third statement is a curate's egg. The first sentence I understand (although
most folk seem to prefer the term different "owner"). The second sentence seem
certain about something, but I have no idea what.

Please clarify, as I'm not alone in simply missing the point here.

all the best,
  Lawrence

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 2 Aug 2011 15:34:54 +0200

> followed and the prefix checked there

user & developer should issue a standard DNS query for _443._tcp.example.com
and use whatever record the DNS resolver returns.  CNAME is an internal

> 2d) B wins? ("Because that's where the server is & is more likely to be

2c) is right, because that's how the DNS works right now.

> must match? All must match & be present? Pick one at random?

Same algorithm.  Issue a standard DNS query for TLSA and use whatever
the resolver will return to you.  CNAME will be processed by your resolver
(or resolver library).

> it can be both, but it has to be clear in the protocol first.

My opinion might be obscured by my DNS-centric view, but I still fail to
see what needs to be clarified in the protocol.  Application requesting
the TLSA will issue _port._proto.example.com for 'example.com'.  It's
exactly the same way how you request an IP address.  You issue a query
for IN AAAA / IN A to your resolver library and don't care if there is
a CNAME, DNAME or chains of CNAME/DNAMEs.

This simplest solution (e.g. don't do any extra processing) also has
enough flexibility to keep control over the record for yourself (add
TLSA) or to delegate it to your hosting provider (add CNAME).  For more
examples see one of my previous emails where I list all possible
combinations.

If it still feels insufficient then maybe a suggested text would help?

> name, and use the first TLSA record you find."

Is there anything so specific in TLSA record that you think it needs to
change current DNS algorithms?  I fail to see why.

To be even more precise - the mail standard developers did the mistake
and specified that MTA should process the CNAMEs and now we have different
implementation and each processes the CNAME differently.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 2 Aug 2011 17:54:28 +0200

> fundamentally different from TLSA?

To turn this around the jabber records.  The equivalent in XMPP would be:

Alice has a jabber account [email-masked].

jabber.alice.com IN CNAME jabber.oscar.com

_jabber._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com.
_xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com.
_xmpp-server._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com.

jabber.oscar.com IN A 1.2.3.4

1.2.3.4 runs only a webserver.

What happens today:
- The current compliant clients will talk to jabber.bob.com, because they use IN SRV _xmpp-server._tcp.jabber.alice.com (and other SRVs).

What would happen if PHB's proposal was in effect:
- The proposal to resolve the CNAME would cause connections to [email-masked] to connect to jabber.oscar.com and fail.

So to continue this discussion please answer:

1. Do you think that TLSA needs to be handled differently?

2. Why do you think that TLSA needs special approach?

3. What is the *problem* you are trying to solve?
   [I honestly don't see the problem which you are addressing with this solution.]

 3a. Are you afraid that people will not be educated enough to create TLSA at _443._tcp.www.alice.com?  They have learnt how to cope with jabber.

 3b. ???

O.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 09:12:37 -0700

> - The proposal to resolve the CNAME would cause connections to [email-masked] to connect to jabber.oscar.com and fail.

As much as I hate to put words in Phill's mouth, I don't think that is correct about his proposal. He said that his proposal is RRtype-specific, and that it was currently only for TLSA records. Thus, his proposal would not change any of the above.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Aug 2011 13:10:28 -0400

On Tue, Aug 2, 2011 at 12:12 PM, Paul Hoffman <[email-masked]> wrote:

> > - The current compliant clients will talk to jabber.bob.com, because
> they use IN SRV _xmpp-server._tcp.jabber.alice.com (and other SRVs).
> >
> > - The proposal to resolve the CNAME would cause connections to
> [email-masked] to connect to jabber.oscar.com and fail.
>
> As much as I hate to put words in Phill's mouth, I don't think that is
> correct about his proposal. He said that his proposal is RRtype-specific,
> and that it was currently only for TLSA records. Thus, his proposal would
> not change any of the above.

Exactly.

I have two separate concerns

1) Do not create a new hole
2) Try to fill in some of the hole that has already been created.

Avoiding creating a new problem with DANE is relatively easy. Fixing the
existing issues with SRV, URI, NAPTR, DKIM is much more complex and might
not have a sufficiently compelling value proposition.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 02 Aug 2011 22:09:03 +0200

> As much as I hate to put words in Phill's mouth, I don't think that is correct about his proposal. He said that his proposal is RRtype-specific, and that it was currently only for TLSA records. Thu…

I missed that point. However it makes me no less confused.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 02 Aug 2011 22:14:54 +0200

> not have a sufficiently compelling value proposition.

Arguably your proposed fix then introduces an inconsistency in DNS. In
my book that makes the cure worse than the ailment.

	Cheers Leif

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Aug 2011 16:24:01 -0400

> different name. That is certainly not the semantics that use of prefixes is

Tough beans.  Prefixing a name in the DNS creates a different name.
That's part of its definition of "hierarchical name space".  Just
because a bunch of people think that DNS names have semantics doesn't
make it so.  You can impute semantics, and the underscore is a useful
hint.  But it doesn't change the nature of the DNS name space.  You
want a CNAME at a node?  Put one there.  It's your zone to manage.

Surely the DANE operator's toolkit is going to have some sort of
knowledge that, if there's a CNAME at the DANE-enabled zone, you need
a CNAME somewhere else too?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Aug 2011 16:38:25 -0400

> 3b) The query result returns an alias mapping D to A.

If I'm reading you correctly, your suggestion in a nutshell is that
instead of telling D's administrator to put P.D CNAME
[some-target-here] in the D zone, you want every application that
might ever rely on TLSA to know about "alias mappings" -- even if such
aliases are added to the DNS in the future -- and automatically follow
them in cases where they are detected?  Also, you want every
DANE-implementing application that does a DNS lookup and doesn't get a
TLSA response to issue an extra query for the superordinate name --
i.e. you want to make sure that everyone who doesn't implement TLSA
gets to see a lot of ANY queries to their authority servers.  Do I
have that right?

> The overhead of doing this is irrelevant.

I'm not sure the DNS operators of the world would agree with you.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 3 Aug 2011 19:07:18 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ondrej Surý
> Sent: Tuesday, August 02, 2011 8:54 AM
> To: Leif Johansson
> Cc: [email-masked]
> Subject: Re: [dane] CNAMES and Wildcards
> 
> 
> >>>> The issue is that DANE has to use prefixed DNS records and these do
> >>>> not
> >>> work
> >> www.example.com  CNAME alias.example.com www.example.com  SRV
> 1 1 80
> >> alias.example.com
> >

For my edification - I would see as the TLSA record as

_port._tcp._jabber._tcp.jabber.alice.com IN TLSA <blob>

For the first one - and so forth.  I .e. I would not lookup the records as

_5269._tcp.jabber.bob.com

I believe we from what I have read that the client should only try the first one.

Jim

> - The current compliant clients will talk to jabber.bob.com, because they use
> IN SRV _xmpp-server._tcp.jabber.alice.com (and other SRVs).
> 
>  3a. Are you afraid that people will not be educated enough to create TLSA at
> _443._tcp.www.alice.com?  They have learnt how to cope with jabber.
> 
>  3b. ???
> 
> O.
> --
>  Ondrej Sur
>  vedouc  v zkumu/Head of R&D department
>  CZ.NIC, z.s.p.o.    --    Laboratore CZ.NIC
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 4 Aug 2011 08:36:43 +0200

> I believe we from what I have read that the client should only try the first one.

That's an interesting topic.  We should probably discuss this more.
I am going to open an issue in the tracker covering the interaction
between SRV and TLSA records.

My opinion is that I would lookup:

_5269._tcp.jabber.bob.com. IN TLSA

My reasoning is that because I the SRV is a client side redirection,
and the client knows that he is connecting to the different server.
It is the (jabber) client who has to parse and interpret the SRV record(s).

What others in the WG think?

O.

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 4 Aug 2011 09:32:48 +0200

> I believe we from what I have read that the client should only try the first one.

IMHO, the SRV (or MX) record provides mapping from service name to hostname, whereas TLSA provides an association between hostname and a (set of) certificate(s). Let me illustrate with three examples for traditional mail, jabber and web:

1) Mail

Primary and secondary mail server provided by the domain itself, and a tertiary mail server by some mail provider. Service to server mapping is provided using MX. Each server has its own certificate association.

example.com.  IN MX 0 mail-one.example.com.
              IN MX 1 mail-two.example.com.
              IN MX 5 relay.provider.com.

_25._tcp.mail-one.example.com. IN TLSA ...
_25._tcp.mail-two.example.com. IN TLSA ...

and in the provider's zone:

_25._tcp.relay.provider.com.   IN TLSA ...

2) Jabber (XMPP)

All jabber services provided by the domain itself, service to server mapping provided using SRV. The jabber server has one certificate association per port (although this might be the same cert).

_jabber._tcp.example.com.       IN SRV 0 0 5269 xmpp.example.com.
_xmpp-server._tcp.example.com.  IN SRV 0 0 5269 xmpp.example.com.
_xmpp-client._tcp.example.com.  IN SRV 0 0 5222 xmpp.example.com.

_5269._tcp.xmpp.example.com. IN TLSA ...
_5222._tcp.xmpp.example.com. IN TLSA ...

3) Web

For web servers, there exists no (widely deployed) service to server mapping. CNAMEs are sometimes used (as in the example below), but transparent ("invisible") for the client application.

www.example.com.            IN CNAME server1.example.com.
server1.example.com.        IN A 192.0.2.1
_443._tcp.www.example.com.  IN TLSA ...

	jakob

---

From: Matt Larson <[email-masked]>
Date: Thu, 4 Aug 2011 08:58:41 -0400

> _443._tcp.www.example.com.  IN TLSA ...

+1000 to this.  A TLSA-aware application should be a user of DNS just
as any other application, which means it should not be aware of
underlying DNS structure (e.g., aliases): that way lies madness,
exceptions to existing practice elsewhere, layer violations,
application complexity, pain and suffering.

Seriously, changing the semantics of DNS aliasing on a per-application
basis to route around fundamental DNS behavior because it is
inconvenient is the wrong way to go.

Matt

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Aug 2011 16:15:39 +0200 (MEST)

> _25._tcp.relay.provider.com.   IN TLSA ...

Whoooops!  Security-wise, this is nonsensical, because this precludes
authentication of the server.

Unfortunately, this is exactly how SMTP-AUTH appears to be specified,
... and documented in rfc6125.

  http://tools.ietf.org/html/rfc6125#appendix-B.4

resulting in a self-contradictory statement:

      The client MUST use the server hostname it used to open the
      connection as the value to compare against the server name as
      expressed in the server certificate.  The client MUST NOT use any
      form of the server hostname derived from an insecure remote source
      (e.g., insecure DNS lookup).  CNAME canonicalization is not done.

First, it says that the client MUST use the server hostname that is
resulting from the (insecure) MX DNS lookup.  Then it goes on to say that
the client MUST NOT use a form of the server hostname derived from an
insecure remote source such as insecure DNS lookup.

> _5222._tcp.xmpp.example.com. IN TLSA ...

That seems to be similar to the example here:

   http://tools.ietf.org/html/rfc6120#section-13.7.1.2.2

and means that rfc6125 would match to dnsName "example.com"
and therefore I believe DANE should look for

   _5222._tcp.example.com.  IN TLSA      for the client
   _5269._tcp.example.com.  IN TLSA      for the server

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Aug 2011 07:28:44 -0700

> authentication of the server.

I don't believe that it does. The server in this case is relay.provider.com. The client knows that because the client got the server name back from the MX lookup. MX gives a new server name, not a hidden canonicalization like CNAME.

> insecure remote source such as insecure DNS lookup.

Why do you assume that the MX lookup is insecure?

>   _5269._tcp.example.com.  IN TLSA      for the server

Hrm. You seem to be mixing up DANE semantics and PKIX semantics, but in a way that is quite reasonable. It feels like the operations documentation for DANE needs to pick one of the two targets when using SRV and state which should be looked up.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 4 Aug 2011 15:13:33 -0000

>relay.provider.com. The client knows that because the client got the
>server name back from the MX lookup. MX gives a new server name, not a
>hidden canonicalization like CNAME.

I don't get it.  Why is the indirection in MX semantically different
from the indirection in CNAME?  Assuming both are DNSSEC signed, they
both show an identical intention of one domain to delegate its service
to another.

R's,
John

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 4 Aug 2011 17:37:03 +0200

> both show an identical intention of one domain to delegate its service

The difference is that the CNAME (and DNAME) is interpreted by DNS resolver
and MX (and others) is interpreted by the application.

The application (MTA) in this case doesn't do DNS query for 'CNAME', but
for MX and AAAA/A records and it should not matter if there is a CNAME
somewhere in between or not.

So if your MTA wants to deliver an email to remote address [email-masked]
it issues following queries to the DNS:
  bob.com. IN MX
and gets
  bob.com. IN MX 10 mail.bob.com.
then it sends another query:
  mail.bob.com. IN AAAA
and gets:
  mail.bob.com. IN AAAA 2001:DB8::1

But it could also get:
[again I ignore the fact that you cannot get CNAME at bob.com]
  bob.com. IN CNAME alice.com.
  alice.com. IN MX 10 mail.alice.com.
and for IN AAAA
  mail.alice.com. IN CNAME mail.oscar.com.
  mail.oscar.com. IN AAAA 2001:DB8::2

But it doesn't do any processing of CNAMEs, it all happens on the DNS resolver side.

The first sentence in a paragraph from section 3.6 of RFC1034 is important:

    CNAME RRs cause special action in DNS software.  When a name server
    fails to find a desired RR in the resource set associated with the
    domain name, it checks to see if the resource set consists of a CNAME
    record with a matching class.  If so, the name server includes the CNAME
    record in the response and restarts the query at the domain name
    specified in the data field of the CNAME record.  The one exception to
    this rule is that queries which match the CNAME type are not restarted.

_CNAME RRs cause special action in DNS software_, the MX, PTR, SRV and others
don't - there could be extra records put into additional section, but it
doesn't cause the query to be restarted.

For references cross check with MX, PTR and/or SRV:

RFC 1035 Section 3.3.9.:

    MX records cause type A additional section processing for the host
    specified by EXCHANGE.

RFC1035 Section 3.3.12.:

    PTR records cause no additional section processing.  These RRs are used
    in special domains to point to some other location in the domain space.
    These records are simple data, and don't imply any special processing
    similar to that performed by CNAME, which identifies aliases.  See the
    description of the IN-ADDR.ARPA domain for an example.

For SRV see RFC 2782 section Usage rules:

    A SRV-cognizant client SHOULD use this procedure to locate a list of
    servers and connect to the preferred one:

        Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
        QTYPE=SRV.
    […snip…]
    Notes:
    […snip…]
     - If the Additional Data section doesn't contain address records
       for all the SRV RR's and the client may want to connect to the
       target host(s) involved, the client MUST look up the address
       record(s).  (This happens quite often when the address record
       has shorter TTL than the SRV or NS RR's.)

There is no DNS server side processing in the RFC2782.

O.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Aug 2011 08:38:56 -0700

> both show an identical intention of one domain to delegate its service

If the two were specified in 1034 the same way, I would agree with you. They don't appear to be. 1034 says:

The text for MX sounds nothing like that. All it says is "identifies a mail exchange for the domain.  See [RFC-974 for details."

Why did you think that they were semantically the same?

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 4 Aug 2011 08:43:14 -0700

>From an operational perspective, it seems to me that the right
question to ask here is "what names do existing certificates for these
services assert?"

zw

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 4 Aug 2011 17:47:06 +0200

> Hrm. You seem to be mixing up DANE semantics and PKIX semantics, but in a way that is quite reasonable. It feels like the operations documentation for DANE needs to pick one of the two targets when…

Basically it looks like we might end up saying that the interaction
of SRV and TLSA will be processed by the rules implied by the particular
protocol using SRV records.  For jabber it makes sense to use RFC 6120
approach as pointed out by Martin.

And it looks like the SIP took same approach:

http://tools.ietf.org/html/rfc5922#section-4

   As an example, consider a request that is to be routed to the SIP
   address "sips:[email-masked]".  This address requires a secure
   connection to the SIP domain "example.com" (the 'sips' scheme
   mandates a secure connection).  Through a series of DNS
   manipulations, the domain name is mapped to a set of host addresses
   and transports.  The entity attempting to create the connection
   selects an address appropriate for use with TLS from this set.  When
   the connection is established to that server, the server presents a
   certificate asserting the identity "sip:example.com".  Since the
   domain part of the SIP AUS matches the subject of the certificate,
   the server is authenticated […]

O.

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Aug 2011 17:59:05 +0200 (MEST)

> both show an identical intention of one domain to delegate its service

I fully agree with John.  With respect to the transformation of
the reference name that gets compared, the type of the RR is
relevant, the semantics of transforming the reference name
is exactly the same.

In the original use case "HTTP over TLS", there is _no_ depency on
DNS being secure in order for the server endpoint identification
to not be susceptible to simple DNS spoofing.

DNS MX RRs for Email never were a security feature, they are an
operational convenience feature.  SMTP over TLS, if it matches
the hostname resulting from an MX lookup, creates a vital
dependency on DNSSEC protecting that MX lookup in order for
the server endpoint identification not being susceptible to
simple DNS spoofing.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Aug 2011 18:00:53 +0200 (MEST)

Sorry for the typo  (IRrelevant)

> the reference name that gets compared, the type of the RR is
- relevant, the semantics of transforming the reference name
+ IRrelevant, the semantics of transforming the reference name

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 4 Aug 2011 18:05:44 +0200

> question to ask here is "what names do existing certificates for these

For MX see RFC 3207 Section 4.1:
   […]

   The decision of whether or not to believe the authenticity of the
   other party in a TLS negotiation is a local matter.  However, some
   general rules for the decisions are:

   -  A SMTP client would probably only want to authenticate an SMTP
      server whose server certificate has a domain name that is the
      domain name that the client thought it was connecting to.
   […]

It's a bit vague, but I would assume that the SMTP clients connects to
the domain name of the SMTP server and not to the domain part of the
email address.

And operational practice seems to be just weird:

gmail.com servers has CN=mx.google.com (and nothing else, or openssl trying
to hide it from me).

fastmail.fm servers has CN=*.messagingengine.com, which is OK, because the
MXs are:
fastmail.fm.		427	IN	MX	10 in1.smtp.messagingengine.com.
fastmail.fm.		427	IN	MX	20 in2.smtp.messagingengine.com.

I haven't found any other big email provider using STARTTLS.

O.

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Aug 2011 18:14:39 +0200 (MEST)

Paul Hoffman wrote:
> 
> Martin Rex wrote:
> 
> > 2) Jabber (XMPP)
> >> 
> >> All jabber services provided by the domain itself, service to server
> >> mapping provided using SRV. The jabber server has one certificate
> >> association per port (although this might be the same cert).
> >> 
> Hrm. You seem to be mixing up DANE semantics and PKIX semantics,
> but in a way that is quite reasonable. It feels like the operations
> documentation for DANE needs to pick one of the two targets when
> using SRV and state which should be looked up.

I'm trying to align them, yes, and on purpose.
I was under the impression that among the DANE TLSA desired options was
providing an independent confirmation for a server certificate issued
by a traditional SSL Server CA from the TLS X.509 PKI.

And simultaneously we will often have a heterogenous installed base 
with DANE-aware and pre-DANE TLS clients.

If we want to make it possible to represent an existing claim from
a traditional SSL server CA assertion ("this server is authorized to
provide a service for hostname X.Y.Z") with one single TLSA record,
we will have to slice things in exactly the same fashion.

We could do it differently, but that would make things complex,
non-intuitive quickly and require multiple TLSA records to confirm
a single assertion from traditional SSL server CAs.

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 4 Aug 2011 18:28:14 +0200

On 4. 8. 2011, at 17:59, Martin Rex wrote:

> irrelevant, the semantics of transforming the reference name
> is exactly the same.

I still think that the difference between DNS server-side processing
and client-side processing is important.  However...

> In the original use case "HTTP over TLS", there is _no_ dependency on

I think I understand you and you are probably right.  But is this
insecurity related to TLSA?  I think it's the generic vulnerability
of SMTP over TLS.  See my other mail on MX with references to RFC 3207.

O.

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Aug 2011 18:32:57 +0200 (MEST)

O. wrote:
> Zack Weinberg wrote:

Thanks for quoting.  I missed this text in rfc6125 Appendix B.4 just
before the part I quoted.  IMHO this is a very important security
consideration, but the way it is worded, appears slightly marginalized.

Basically, it suggests to consider every server certificate a wildcard
certificate (do a tail match on the domain rather than a hostname match).

> gmail.com servers has CN=mx.google.com (and nothing else, or openssl trying

Google neither assigned indepent IPv4 addresses nor configured a
multi-SubjectAltName Server cert, so it needs the client to
use TLS extension SNI in order to present the correct server cert
in the TLS handshake.  That is an additional command line option
to the openssl client.

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 4 Aug 2011 18:52:34 +0200

> certificate (do a tail match on the domain rather than a hostname match).

Thanks for pointing RFC 6125, I didn't know this document exists.

It seems to be a good idea to align with RFC 6125 where applicable
and other XXX over TLS documents.  F.e the FTP over TLS, where
the rules are same as for HTTP over TLS.

RFC 6125 also probably answers the question about CNAMES, since there
are many places where it says "CNAME canonicalization is not done."
or the same is evident from the text.

It also seems to be a good idea (if WG will want it) to create similar
section in the DANE operational document which will include a list of
the protocols in similar fashion and instruction where to put TLSA
record.

O.

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Aug 2011 19:54:33 +0200 (MEST)

> the domain name of the SMTP server and not to the domain part of the

Looking at the info in DNS for "@gmail.com", it appears that google
expects SMTP clients to _not_ perform any kind of matching
... which does not feel right.

gmail.com has the following MX records:

  gmail.com.  3600  IN  MX   5  gmail-smtp-in.l.google.com.
  gmail.com.  3600  IN  MX  10  alt1.gmail-smtp-in.l.google.com.
  gmail.com.  3600  IN  MX  20  alt2.gmail-smtp-in.l.google.com.
  gmail.com.  3600  IN  MX  30  alt3.gmail-smtp-in.l.google.com.
  gmail.com.  3600  IN  MX  40  alt4.gmail-smtp-in.l.google.com.

Talking SMTP & STARTTLS to alt4.gmail-smtp-in.l.google.com. (with TLS SNI)
yields the following TLS Server cert (no subjectAltNames) below:

Subject:  CN=mx.google.com,O=Google Inc,L=Mountain View,S=California,C=US

There would be some security value in tail-matching the target domain
"gmail.com" to the Server certificate, but that is a clear mismatch here.

Tail-matching an MX result with the server certificate looks bogus
to me (without that MX-record being protected by DNSSEC and the result
verified by the SMTP client) and is susceptible to simple DNS spoofing
of MX records for gmail.com.

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

-Martin

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 4 Aug 2011 20:53:55 +0200

>   _5269._tcp.example.com.  IN TLSA      for the server

Let's assume the Google Apps XMPP servers serves about 10'000 different XMPP domains (although it is probably more). Given this line of reasoning, the certificate for those servers would have 10'000 dnsNames and would have to be reissued every time Google added (or removed) a new XMPP domain. This does not make sense to me at all as it would result in operational an nightmare.

	jakob

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Aug 2011 21:11:12 +0200 (MEST)

Jakob Schlyter wrote:
> Let's assume the Google Apps XMPP servers serves about 10'000 different
> XMPP domains (although it is probably more). Given this line of reasoning,
> the certificate for those servers would have 10'000 dnsNames and would
> have to be reissued every time Google added (or removed) a new XMPP
> domain. This does not make sense to me at all as it would result in
> operational an nightmare.

I'm sorry, I'm having difficulties following (and admittedly, my
experience with XMPP is *tiny*).

While the IETF has a number of working groups, a single "jabber.ietf.org"
server sees to be sufficient.  What is goggle doing, and how many
DNS records do they need for doing this *today* (i.e. pre-DANE) and
how many server certs do they need today (from TLS X.509 PKI)?

Then what it is solution that you would want from DANE?

And would that goal be achievable with DANE-only clients using
TLSA types unrelated to TLS X.509 PKI being specified to _not_
perform any host name comparisons on the certificate itself
(since the host/domain -> certificate matching can be done with TLSA).

-Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 4 Aug 2011 15:22:27 -0400

> experience with XMPP is *tiny*).

I have slightly more experience with this, mainly as a result of volunteering for draft-ietf-xmpp-dna.

> how many server certs do they need today (from TLS X.509 PKI)?

The IETF has a single jabber.ietf.org because "ietf.org" is the only domain they manage.  Google and others, through programs like Google Apps for your Domain, host thousands of domains, and thus have thousands of SRVs pointing at them.

The upshot with regard to certs is that they don't do it, for precisely the reasong Jakob mentions.  See:
<http://tools.ietf.org/agenda/76/slides/xmpp-5.pdf>

The XMPP WG is working on patching XMPP to avoid this problem.  The current draft basically uses DNSSEC on the SRV to secure the delegation, then has the actual server present its own cert (e.g., via DANE).  See:
<http://tools.ietf.org/html/draft-ietf-xmpp-dna-01>

> Then what it is solution that you would want from DANE?

As I suggested above, DANE is not a solution for secured delegation in this case.  SRV actually does an application-layer redirection (as opposed to CNAME's DNS-layer redirect).  So DNSSEC on the SRV would secure the delegation, while a DNSSEC-protected DANE record under the server's name would secure the actual TLS channel.

--Richard

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Aug 2011 15:48:50 -0400

On Thu, Aug 04, 2011 at 03:22:27PM -0400, Richard L. Barnes wrote:

> in this case.  SRV actually does an application-layer redirection
> (as opposed to CNAME's DNS-layer redirect).

I think this key distinction is getting lost in the analogy between
these two cases, and I thank Richard for stating it so clearly.

-- 
Andrew Sullivan
[email-masked]

---

From: [email-masked]
Date: Sat, 6 Aug 2011 14:19:24 +0000

> inconvenient is the wrong way to go.

	Have to agree with Matt (and others) on this aspect.
	As I remember, DANE is supposed to work in -all- parts of the
	DNS heirarchy - so I have to ask myself if these proposed 
	changes would work in the  address/reverse map of the DNS?

/bill

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 6 Aug 2011 11:17:29 -0400

Nobody is proposing changing the semantics of DNS.

That is a gross distortion of what was proposed.

I don't think there is much point in engaging in debate on such terms.

The reason I made my proposal was to preserve the semantics of the DNS as
understood operationally by webmasters and hosting providers.

It is really not relevant to these people that _prefix.example.com and
example.com are utterly different names in DNS architecture. They want and
expect them to behave the same. If they don't they are likely to conclude
that DANE is a pointless waste of time because 'it does not work'.

What is at issue is what a relying party should do if it is unable to find a
TLSA record in the place it first looks for it.

My view is that if the initial lookup fails, the client should attempt to
follow CNAME references and other aliases to discover a TLSA record that
might match. That applies to PTR and SRV as well

On Sat, Aug 6, 2011 at 10:19 AM, <[email-masked]> wrote:

> > > For web servers, there exists no (widely deployed) service to server
> mapping. CNAMEs are sometimes used (as in the example below), but
> transparent ("invisible") for the client application.
> > >

---

From: Paul Wouters <[email-masked]>
Date: Sat, 6 Aug 2011 15:21:57 -0400 (EDT)

On Sat, 6 Aug 2011, Phillip Hallam-Baker wrote:

> It is really not relevant to these people that _prefix.example.com and example.com are utterly different names in DNS
> architecture. They want and expect them to behave the same. If they don't they are likely to conclude that DANE is a
> pointless waste of time because 'it does not work'.

I'll add a check to the "dane" command generator to check for cnames and create proper
records.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 6 Aug 2011 16:13:22 -0400

That won't help.

The problem is that unless CNAMES work the way people expect (i.e. one CNAME
redirects both the site and associated TLSA record(s)) then the tool has to
be run in two places and not just one.

Worse, it means that I have to switch from my DNS hosting provider or wait
till they support TLSA records in order to use TLSA.

Now from a business point of view, that is not a bad outcome for my employer
as a provider of full service DNS resolution services (DNS.com) and I
suspect for many others in this thread. My concern here is that if the bar
to making this work is set too high then people won't deploy at all.

On Sat, Aug 6, 2011 at 3:21 PM, Paul Wouters <[email-masked]> wrote:

>> example.com are utterly different names in DNS
>> architecture. They want and expect them to behave the same. If they don't
>> they are likely to conclude that DANE is a
> ______________________________**_________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dane<https://www.ietf.org/mailman/listinfo/dane>
>

---

From: John Gilmore <[email-masked]>
Date: Sat, 06 Aug 2011 18:40:48 -0700

> be run in two places and not just one.

Phillip, there is no "way people expect" TLSA records to work.  There
are no TLSA records in the wild.  We are inventing them out of whole
cloth.  And we should define them to work in the straightforward way,
like any other DNS record, without requiring resolvers to do
hop-by-hop checks for intervening CNAMEs.

To put it another way, CNAME is a wierd DNS record that has specific
semantics that resolvers need to know about if they encounter one.
Let's not add ANOTHER wierd DNS record that resolvers need to know
about.  If we could make TLSA as simple for DNS implementations as
TXT, that would be lovely, Occam's Razor would smile at us, and 
we'd get early and wide deployment with few bugs.

We could revisit whether to require SRV-like domain name prefixes on
TLSA records; they are the reason why your knickers are in a knot over
CNAMEs.  But I suspect that the WG thinks that's a settled issue.  And
weren't you on the "make it like SRV" side of that issue?

	John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 6 Aug 2011 23:47:07 -0400

On Sat, Aug 6, 2011 at 9:40 PM, John Gilmore <[email-masked]> wrote:

> are no TLSA records in the wild.

Wrong, they have 20 years of experience of how the Web works and that is
their starting point.

If DANE wants to propose a new record that behaves in a way that they
consider to be illogical they can but it is going to be ignored.

> We are inventing them out of whole

Implementations, implemenshmations.

Its the million plus web masters who you want to use this scheme and the
billion plus users of the Web that the scheme has to be designed for if it
is going to be used.

The problem for implementors in the browser space is not writing code, its
selling the features to their management. And to do that they have to
demonstrate that the scheme is going to work without causing huge customer
support costs or pushing complexity into some other area.

The status quo has huge inertia.

At the moment the point seems to be moot as the browser world seems more
interested in the original Kaminsky scheme of pickling the DNSSEC chain into
the cert than using DNS records in any flavor. And the Web Services world
has other security policy interests that Dane completely ignores.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 7 Aug 2011 14:24:18 -0400

> be run in two places and not just one.

I don't care whether anybody expects CNAMEs to work that way; they
don't, and never have.  People might expect http to come into their
house in the morning and make the coffee, too, but it doesn't do that.

I fail completely to see any sense in an argument that starts from, "A
bunch of peopl -- trust me -- have this completely wrong idea of how
the DNS work," and concludes with, "Therefore I want to do this thing
that is really outstandingly different from everything else in the
DNS."  Even if I grant the premise that people expect the CNAME to
work that way -- and, frankly, I'm sceptical, because I don't think
most people have any intuition one way or another about how this is
supposed to work -- I will not grant further that therefore that
expectation has to be met.

If you move from Britain to America, you might still exect to drive on
the left hand side of the road.  But if you try to behave like that,
you'll regret it.  You have to follow the rules.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 08 Aug 2011 08:45:43 +1000

> you'll regret it.  You have to follow the rules.

Additionally there is a proposal on the table, BNAME, which will
do what you want, redirection of the namespace at and below a name.
You just need to get it through dnsext.

I've argued for a long time that BNAME is a tool that should be in
the DNS tool chest.

example.com A ...
example.com AAAA ...
_443._tcp.example.com TLSA ....
www.example.com	BNAME example.com

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 8 Aug 2011 07:56:36 -0400

> The problem is that unless CNAMES work the way people expect (i.e. one CNAME redirects both the site and associated TLSA record(s)) then the tool has to be run in two places and not just one.

This is true, but a consequence of the CNAME semantics.  You have to redirect each name individually.  If you want to redirect a whole subtree, use DNAME.  We don't have to cut slots in the tops of our nails because you want to use a screwdriver.

> Worse, it means that I have to switch from my DNS hosting provider or wait till they support TLSA records in order to use TLSA.

This is not true, precisely because you don't have to redirect both names.  If your hosting provider does support TLSA, then you can redirect both:

alice.com CNAME bob.com
_port._tcp.alice.com CNAME _port._tcp.bob.com

... but if they don't, then you can host the TLSA record yourself:

alice.com CNAME bob.com
_port._tcp.alice.com TLSA _port._tcp.bob.com

You'll notice that it's precisely the independent redirection of the two names that allows you to deploy TLSA without your provider supporting it.  

--Richard

> Now from a business point of view, that is not a bad outcome for my employer as a provider of full service DNS resolution services (DNS.com) and I suspect for many others in this thread. My concern here is that if the bar to making this work is set too high then people won't deploy at all.
> 
> 
> 
>

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 8 Aug 2011 14:27:44 +0200

> You'll notice that it's precisely the independent redirection of the two names that allows you to deploy TLSA without your provider supporting it.  

This is also, IMHO, a very important security feature. FWIW, the provider you are delegating to does not even have to support DNSSEC. On the other hand, if you want to delegate TLSA (and they support it), your free to do so.

	jakob

---

From: Tony Finch <[email-masked]>
Date: Wed, 10 Aug 2011 17:14:40 +0100

> insecure remote source such as insecure DNS lookup.

Note that SMTP AUTH is used pretty much exclusively with the message
submission protocol, not with server-to-server SMTP. Message submission
does not use MX lookups, so the service name is the same as the hostname
(like HTTP) or (if you are very advanced) indirected using SRV - see RFC
6186.

That quote from RFC 6125 is in an informative appendix which is in turn
quoting from RFC 4954 which uses the same wording as RFC 2595. All three
documents are consistently (if not always clearly) requiring that the
certificate is checked against the name entered by the user, NOT by some
name derived from an indirection in the DNS (whether it be CNAME or MX or
SRV).

I think we should stick with service name authentication, and not switch
to host name authentication.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire, Northeast Forties: Northwesterly veering
northeasterly 4 or 5, decreasing 3 at times later. Moderate becoming slight at
times. Mainly fair. Moderate or good.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Aug 2011 09:49:00 +1000

In message <[email-masked]>, Tony Fi
> (like HTTP) or (if you are very advanced) indirected using SRV - see RFC

There is no contradition above.  SMTP AUTH is useless unless the entire 
path to identify the server is secure.  The above is saying don't do
SMTP AUTH unless you have *secure* referrals.  DNSSEC gives you secure
referrals.  It isn't saying ignore the referrals.

And if you are using SRV you use the target of the SRV record to
authenticate and it should match the name presented in the greeting
when you connect.  Same with MX.

This goes all the way back RFC 821.

   3.5.  OPENING AND CLOSING

      At the time the transmission channel is opened there is an
      exchange to ensure that the hosts are communicating with the hosts
      they think they are.

We have DNSSEC.  We can authenticate SRV and MX records.  They can,
*securely*, tell you who you are supposed to be talking to.

> name derived from an indirection in the DNS (whether it be CNAME or MX or

No, it isn't saying that.

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Aug 2011 04:51:36 +0200 (MEST)

> (like HTTP) or (if you are very advanced) indirected using SRV - see RFC

I somehow fail to see conformance to rfc6186 with respect to the
TLS server cert for both, MUAs and Server-to-Server, for @gmail.com SMTP.

The TLS server certificate presented seems to be from a private CA
(not from one of the CAs of the TLS X.509 PKI), so it doesn't really
matter that it also fails to match the "gmail.com" reference identifier.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Aug 2011 13:01:42 +1000

In message <[email-masked]>, Martin Rex writes
> matter that it also fails to match the "gmail.com" reference identifier.

Just because operators are doing the wrong thing today it doesn't mean
they can't do the right thing tomorrow.

---

From: Tony Finch <[email-masked]>
Date: Thu, 11 Aug 2011 10:02:07 +0100

> TLS server cert for both, MUAs and Server-to-Server, for @gmail.com SMTP.

Do you have evidence of non-conformance for MUAs? Following Google's
instructions gets me to servers that present valid certificates with the
expected common name.
http://mail.google.com/support/bin/answer.py?answer=78799

On the other hand, the situation with inter-domain SMTP+TLS is indeed a
complete disaster. See http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber: Southwest 5 to 7, becoming cyclonic, then northeast 4 or 5 later.
Moderate or rough. Occasional rain, fog patches. Moderate or good,
occasionally very poor.

---

From: Tony Finch <[email-masked]>
Date: Thu, 11 Aug 2011 10:16:36 +0100

> referrals.  It isn't saying ignore the referrals.

But see the text in RFC 6125 about "derived" domains (i.e. targets of SRV
and MX etc.), for instance:

   Each reference identifier in the list SHOULD be based on the source
   domain and SHOULD NOT be based on a derived domain (e.g., a host name
   or domain name discovered through DNS resolution of the source
   domain).  This rule is important because only a match between the
   user inputs and a presented identifier enables the client to be sure
   that the certificate can legitimately be used to secure the client's
   communication with the server.  There is only one scenario in which
   it is acceptable for an interactive client to override the
   recommendation in this rule and therefore communicate with a domain
   name other than the source domain: because a human user has "pinned"
   the application service's certificate to the alternative domain name
   as further discussed under Section 6.6.4 and Section 7.1.

You are suggesting that in the presence of DNSSEC the app should check the
certificate against the derived domain instead of the source domain. This
would be a big change to standard practice, and it would add a lot of
complexity to certificate verification code. What benefits would it
actually provide?

The stuff in SMTP about servers exchanging their hostnames is for
debugging. It has nothing to do with automated server name authentication.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Biscay: Variable 3 or 4. Slight or moderate. Fair. Good.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Aug 2011 12:06:46 +0100

> they can't do the right thing tomorrow.

And you think that we get to decide what is the right way?

There are several million of them and twenty of us. You don't listen to them
so why on earth would they bother to listen to you?

The Internet is defined by actual bits on actual wires.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Aug 2011 12:10:40 +0100

On Thu, Aug 11, 2011 at 10:02 AM, Tony Finch <[email-masked]> wrote:

> > TLS server cert for both, MUAs and Server-to-Server, for @gmail.comSMTP.
>
> complete disaster. See
> http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

No question this is a disaster, but how to fix it.

The only way that I can see to fix it is to automate the process of
installing the cert and the DNS advertisement that there is a cert in use
and having the mail server check that its actions are consistent with
externally advertised policy.

In other words, I don't think that we have any chance of modifying user
behavior or educating administrators. What we might have a chance with is to
deploy code that causes the right thing to be done.

---

From: Tony Finch <[email-masked]>
Date: Thu, 11 Aug 2011 13:08:55 +0100

> No question this is a disaster, but how to fix it.

Restrict the existing STARTTLS extension to message submission only (it
works fine in that context). Create a new TLS service extension for
inter-domain SMTP which has clear requirements for which identities the
certificates authenticate and how they must be verified.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey: East or northeast, 5 to 7, decreasing 4 for a time. Moderate
or rough. Rain. Moderate or good.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Aug 2011 14:30:16 +0200

> certificates authenticate and how they must be verified.
The same issues exist in SIP where it's still unclear to most developers what the SIp server certificate needs to have in CN and subj alt names. Current proposals include IP-adresses.

/O

---

From: SM <[email-masked]>
Date: Thu, 11 Aug 2011 08:21:11 -0700

Hi Olle,
At 05:30 11-08-2011, Olle E. Johansson wrote:
>The same issues exist in SIP where it's still unclear to most 
>developers what the SIp server certificate needs to have in CN and 
>subj alt names. Current proposals include IP-adresses.

RFC 6125 discusses about application service identity verification.

Regards,
-sm

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Aug 2011 17:48:43 +0200

> RFC 6125 discusses about application service identity verification.

yes, and in addition to that, there's an RFC for SIP certificates and the big confusion about SIPS: as an URI. Believe me, developers are very confused and it's a big mess involving usage of IP adresses in headers that we need to match to certificates.

But thanks for the feedback :-)

/O

---

From: SM <[email-masked]>
Date: Thu, 11 Aug 2011 12:01:16 -0700

Hi Olle,
At 08:48 11-08-2011, Olle E. Johansson wrote:
>yes, and in addition to that, there's an RFC for SIP certificates 
>and the big confusion about SIPS: as an URI. Believe me, developers 
>are very confused and it's a big mess involving usage of IP adresses 
>in headers that we need to match to certificates.

Section 1.7.2 of RFC 6125 mentions that IP addresses are out of 
scope.  Although RFC 6125 does not update RFC 5922, the intent is for 
application services to use the advice in RFC 6125 for future 
specifications and for updates to existing specifications.

There are several people with an interest in URI on the 
[email-masked] mailing list.  You could ask about SIPS: as a 
URI on that list.

Regards,
-sm

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Aug 2011 13:01:32 +1000

In message <[email-masked]>, Tony Fin
>    as further discussed under Section 6.6.4 and Section 7.1.

I would argue that SMTP is the exception that SHOULD was designed
for.  SMTP is store and forward.  SUBMISSION is direct.  HTTP is
direct.  SIP is direct.

A large proportion of Australia's email was delivered via a wildcard
MX record at one stage.  Are you saying that the relay should have
a signature for every address covered by the MX?  Note: no sane CA
would have issued a wildcard cert for that level of the heirarchy.
Are you saying that communication to the relay shouldn't be protected
by TLS.

---

From: Tony Finch <[email-masked]>
Date: Fri, 12 Aug 2011 09:25:40 +0100

Mark Andrews <[email-masked]> wrote:
>
> Are you saying that the relay should have a signature for every address
> covered by the MX?

In the absence of DNSSEC that is the only thing that makes sense.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Utsire, South Utsire: Variable, becoming southeasterly, 3 or 4,
increasing 5 or 6. Slight, occasionally moderate. Fair. Good.

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 12 Aug 2011 11:49:40 +0200

> In the absence of DNSSEC that is the only thing that makes sense.

In some theoretical world perhaps, but for people doing real operations. Google or any other large scale mail hosting provider would simply ignore such a requirement.

We can do better now that we have DNSSEC. We can do service to server mapping (e.g., MX or SRV) in a secure way and we can do secure server to certificate mapping (i.e., DANE) as well. Such an architecture would be both secure and deployable.

	jakob