Subject: [keyassure] CNAME, wildcards, SRV and Key binding

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Nov 2010 11:51:35 -0400

Two of the biggest challenges to work around for KIDNS is the existence of
CNAMES and wildcards.

Both suffer from having somewhat soft semantics implementation wise. The
official semantics are strict enough to get in the way but the diversity of
implementations means that it is not necessarily possible to benefit from
that strictness.

DNSSEC affects wildcards in particular since DNS wildcards were originally
an issue for the DNS server alone. Before DNSSEC, a server could synthesize
any record it liked and so a wildcard of the form x.*.y was completely
feasible. DNSSEC only allows wildcards of the form *.y and that makes use of
prefixes difficult.

CNAMES pose a separate problem. According to the rules the only things that
can exist at a DNS node with a CNAME are the CNAME record and the signature
records.

CNAMES do not work well with prefixes. The intention of a CNAME is to say
'this name is equivalent to that name'. That does not work because the CNAME
only applies to the node and not any prefixes. So one solution is to use a
DNAME which maps the entire tree. But that also does not work in cases where
there are names and prefixes involved.

the reason we have to think about them is that naming affects trust. If we
have one name aliased to another, where should we be looking for the keys?
If we have a service provided from multiple hosts should we look for keys at
the service level or for the individual host?

There are plenty of corner cases and I wrote a very long private message
setting these out last week, but I think it is possible to address all of
them if we apply the following rules:

1) The first lookup in a discovery chain is for an unprefixed record.

2) Subsequent lookups are for prefixed records and the records returned MUST
be canonical (no CNAME, DNAME, ZNAME...)

Here the term 'discovery' may be as narrow as security attribute discovery
or may combine service and security attribute discovery.

The idea behind ESRV was that the discovery would be a process of gradual
refinement, starting with security policy for the site and gradually
refining down to very specific policies for specific protocols, hosts and
services.

I think that is still the way to do it, but we need to complete the process
in fewer steps than are involved in ESRV.

So imagine we have two new RRs, START and DETAIL. These are just for the
sake of example of course. It may even be possible to combine both RRs into
one.

The discovery process always begins with a request for an unprefixed START
rr, but may lead to requests for more detail.

A very simple site might be able to pack its entire policy into one record

simple.example.com  START "always use TLS, always use the cert
fingerprint=Y"

Such a site may have an alias, or even a wildcard record:

alias.example.com CNAME simple.example.com
*.wildcard.example.com CNAME "always use TLS, always use the cert
fingerprint=Y"

A more complex site might have different policies for different services:

complex.example.com START "look for detail by protocol"
_http._tcp.example.com DETAIL "always use TLS"
_finger._tcp.example.com DETAIL "never use TLS use SRV discovery"
_finger._tcp.example.com SRV 1 1 9000 finger1.example.com
_finger._tcp.example.com SRV 1 1 9000 finger1.example.com

So now if we alias alias.complex.example.com to the above, the discovery
works exactly as we would like.

alias.complex.example.com  CNAME complex.example.com

We can also do wildcards or anything else that we might want to do.

If we are doing outsourcing, I would think that the way we would want to
achieve that is by inserting one record that says 'do SRV discovery at the
outsource provider' So if we have Big URL Resolution Protocol (BURP) I would
think that we would want to have something like

complex.example.com START "look for detail by protocol"
_http._tcp.example.com DETAIL "always use TLS"
_finger._tcp.example.com DETAIL "never use TLS"
_burp._tcp.example.com DETAIL "look at trusted.outsource.ly"

At the outsource:
_burp._tcp.trusted.outsource.ly DETAIL "never use TLS"

But I can well see that there would be cases where you would want to have
detail that applied to specific SRV hosts.

Granted, this appears to require a lot of round trips. But I think that this
would not be the case in practice and certainly not if we also extend the
DNS protocol itself to support this scheme.

DNS allows for additional records to be packed into each response. So as I
see it, we should only need two round trips for the general case where the
resolution does not cross administrative zone boundaries.

First phase:  Lookup A, AAAA and START RRs for unprefixed record
Second phase (if needed): Lookup  DETAIL, SRV records

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 1 Nov 2010 19:58:21 +0200

> the service level or for the individual host?

In my view, all DNS redirect mechanisms (SRV, CNAME, DNAME, etc...) are
pretty much equivalent when it comes to keys.

For managed services, one pretty much has to have keys on individual host
level. 

> refining down to very specific policies for specific protocols, hosts and

Security policy is meaningless if client has no clue how to get secure
connection. And furthermore, I'm no fan of secuirity policy in DNS.

> simple.example.com  START "always use TLS, always use the cert

"Always use TLS" is ill-defined. It may be almost well-defined with HTTP,
but there are protocols where "use TLS" is just plain ill-defined.

In fact, it contains unstated assumptions (that could turn out to be
false!) even for HTTP.

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Nov 2010 17:27:03 -0400

On Mon, Nov 1, 2010 at 1:58 PM, Ilari Liusvaara <[email-masked]
> wrote:

> For managed services, one pretty much has to have keys on individual host

Keys at the host level yes.

But other security attributes are likely common to all hosts in the service.

> connection. And furthermore, I'm no fan of secuirity policy in DNS.

You certainly don't want to put your policy rules in the DNS. In fact you
probably don't want to have them in any format that is appropriate for a
network protocol.

But security attributes that provide relying parties with additional
information to help them process the security policy may be viable.

> but there are protocols where "use TLS" is just plain ill-defined.

The point of the example was to show the DNS discovery process rather than
the details of the security attributes.

Hence the only sites that could use 'always use TLS' at a site level would
be sites that only supported services that can be secured with TLS. such
sites certainly do exist. None of my Web sites has FTP enabled. The only
services provided are Web and Mail.

> In fact, it contains unstated assumptions (that could turn out to be

You would of course want to ensure that the version of TLS was sufficiently
advanced for the in-band TLS negotiation to prevent downgrade attack within
the TLS protocol itself. But I am pretty sure that holds from TLS 1.0 on and
may well apply to SSL 3.0 as well (but not 2.0!)

For most protocols, 'always offers' is the interesting one. That enables
promiscuous encryption whereby the client will always use crypto if it is
offered. At the moment only a few percent of Internet traffic is encrypted
and that means that a lot of the traffic that is encrypted is compromised by
the en-clair traffic.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Nov 2010 11:20:44 +1100

In message <[email-masked]>, Phil
> can exist at a DNS node with a CNAME are the CNAME record and the signature

Which is not a show stopping issue.  You just replace the CNAME
with the address or other records that are being referenced by the
CNAME records (for legacy clients) and also introduce SRV (or
similar) support so that the indirection has the right sematics.
HTTP has been mis-using CNAME records for a long time now.

> 'this name is equivalent to that name'. 

No.  CNAME is "the real name of this object is TARGET".

> That does not work because the CNAME

See BNAME proposals.
 
> the service level or for the individual host?

The target of the CNAME.  If you want the owner of the CNAME record
to be the name found in the cert then you shouldn't be using CNAME
in the first place.  You should be using something SRV/MX like to
find the addresses of the hosting servers.

Once you are using something SRV/MX like you can make the decision
on a per-protocol basis.  Remember the SRV/MX records are signed.

For HTTP you use the original name.  For SMTP you use the targets
of the MX records.  Both could have well known prefixes attached
to allow for service specific certs.

> --20cf3043523476ac4c0493ffc8f5
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> Two of the biggest challenges to work around for KIDNS is the existence of =
> CNAMES and wildcards.<div><br></div><div>Both suffer from having somewhat s=
> oft semantics implementation wise. The official semantics are strict enough=
>  to get in the way but the diversity of implementations means that it is no=
> t necessarily possible to benefit from that strictness.</div>
> <div><br></div><div>DNSSEC affects wildcards in particular since DNS wildca=
> rds were originally an issue for the DNS server alone. Before DNSSEC, a ser=
> ver could synthesize any record it liked and so a wildcard of the form x.*.=
> y was completely feasible. DNSSEC only allows wildcards of the form *.y and=
>  that makes use of prefixes difficult.</div>
> <div><br></div><div>CNAMES pose a separate problem. According to the rules =
> the only things that can exist at a DNS node with a CNAME are the CNAME rec=
> ord and the signature records.</div><div><br></div><div>CNAMES do not work =
> well with prefixes. The intention of a CNAME is to say &#39;this name is eq=
> uivalent to that name&#39;. That does not work because the CNAME only appli=
> es to the node and not any prefixes. So one solution is to use a DNAME whic=
> h maps the entire tree. But that also does not work in cases where there ar=
> e names and prefixes involved.</div>
> <div><br></div><div><br></div><div>the reason we have to think about them i=
> s that naming affects trust. If we have one name aliased to another, where =
> should we be looking for the keys? If we have a service provided from multi=
> ple hosts should we look for keys at the service level or for the individua=
> l host?</div>
> <div><br></div><div><br></div><div>There are plenty of corner cases and I w=
> rote a very long private message setting these out last week, but I think i=
> t is possible to address all of them if we apply the following rules:</div>
> <div><br></div><div>1) The first lookup in a discovery chain is for an unpr=
> efixed record.</div><div><br></div><div>2) Subsequent lookups are for prefi=
> xed records and the records returned MUST be canonical (no CNAME, DNAME, ZN=
> AME...)</div>
> <div><br></div><div>Here the term &#39;discovery&#39; may be as narrow as s=
> ecurity attribute discovery or may combine service and security attribute d=
> iscovery.</div><div><br></div><div><br></div><div>The idea behind ESRV was =
> that the discovery would be a process of gradual refinement, starting with =
> security policy for the site and gradually refining down to very specific p=
> olicies for specific protocols, hosts and services.</div>
> <div><br></div><div>I think that is still the way to do it, but we need to =
> complete the process in fewer steps than are involved in ESRV.</div><div><b=
> r></div><div><br></div><div>So imagine we have two new RRs, START and DETAI=
> L. These are just for the sake of example of course. It may even be possibl=
> e to combine both RRs into one.</div>
> <div><br></div><div>The discovery process always begins with a request for =
> an unprefixed START rr, but may lead to requests for more detail.</div><div=
> ><br></div><div><br></div><div>A very simple site might be able to pack its=
>  entire policy into one record</div>
> <div><br></div><div><a href=3D"http://simple.example.com">simple.example.co=
> m</a> =A0START &quot;always use TLS, always use the cert fingerprint=3DY&qu=
> ot;</div><div><br></div><div>Such a site may have an alias, or even a wildc=
> ard record:</div>
> <div><br></div><div><a href=3D"http://alias.example.com">alias.example.com<=
> /a> CNAME <a href=3D"http://simple.example.com">simple.example.com</a></div=
> ><div>*.<a href=3D"http://wildcard.example.com">wildcard.example.com</a> CN=
> AME=A0&quot;always use TLS, always use the cert fingerprint=3DY&quot;</div>
> <meta charset=3D"utf-8"><div><br></div><div><br></div><div>A more complex s=
> ite might have different policies for different services:</div><div><br></d=
> iv><div><br></div><div><a href=3D"http://complex.example.com">complex.examp=
> le.com</a> START &quot;look for detail by protocol&quot;</div>
> <div>_http._<a href=3D"http://tcp.example.com">tcp.example.com</a> DETAIL &=
> quot;always use TLS&quot;</div><div><meta charset=3D"utf-8">_finger._<a hre=
> f=3D"http://tcp.example.com">tcp.example.com</a> DETAIL &quot;never use TLS=
>  use SRV discovery&quot;</div>
> <div><meta charset=3D"utf-8">_finger._<a href=3D"http://tcp.example.com">tc=
> p.example.com</a>=A0SRV 1 1 9000 <a href=3D"http://finger1.example.com">fin=
> ger1.example.com</a>=A0</div><div><meta charset=3D"utf-8">_finger._<a href=
> =3D"http://tcp.example.com">tcp.example.com</a>=A0SRV 1 1 9000 <a href=3D"h=
> ttp://finger1.example.com">finger1.example.com</a>=A0</div>
> <meta charset=3D"utf-8"><div><br></div><div><br></div><div>So now if we ali=
> as <a href=3D"http://alias.complex.example.com">alias.complex.example.com</=
> a> to the above, the discovery works exactly as we would like.</div><div><b=
> r>
> </div><div><meta charset=3D"utf-8"><a href=3D"http://alias.complex.example.=
> com">alias.complex.example.com</a> =A0CNAME=A0<meta charset=3D"utf-8"><a hr=
> ef=3D"http://complex.example.com">complex.example.com</a><br><br></div><div=
> >We can also do wildcards or anything else that we might want to do.</div>
> <div><br></div><div><br></div><div>If we are doing outsourcing, I would thi=
> nk that the way we would want to achieve that is by inserting one record th=
> at says &#39;do SRV discovery at the outsource provider&#39; So if we have =
> Big URL Resolution Protocol (BURP) I would think that we would want to have=
>  something like</div>
> <div><br></div><div><br></div><div><a href=3D"http://complex.example.com">c=
> omplex.example.com</a> START &quot;look for detail by protocol&quot;</div><=
> div><div>_http._<a href=3D"http://tcp.example.com">tcp.example.com</a> DETA=
> IL &quot;always use TLS&quot;</div>
> <div>_finger._<a href=3D"http://tcp.example.com">tcp.example.com</a> DETAIL=
>  &quot;never use TLS&quot;</div></div><div>_burp._<a href=3D"http://tcp.exa=
> mple.com">tcp.example.com</a> DETAIL &quot;look at <a href=3D"http://truste=
> d.outsource.ly">trusted.outsource.ly</a>&quot;</div>
> <div><br></div><div>At the outsource:</div><div><meta charset=3D"utf-8">_bu=
> rp._<a href=3D"http://tcp.trusted.outsource.ly">tcp.trusted.outsource.ly</a=
> >=A0DETAIL &quot;never use TLS&quot;</div><meta charset=3D"utf-8"><meta cha=
> rset=3D"utf-8"><div>
> <br></div><div><br></div><div>But I can well see that there would be cases =
> where you would want to have detail that applied to specific SRV hosts.=A0<=
> /div><div><br></div><div><br></div><div>Granted, this appears to require a =
> lot of round trips. But I think that this would not be the case in practice=
>  and certainly not if we also extend the DNS protocol itself to support thi=
> s scheme.</div>
> <div><br></div><div>DNS allows for additional records to be packed into eac=
> h response. So as I see it, we should only need two round trips for the gen=
> eral case where the resolution does not cross administrative zone boundarie=
> s.</div>
> <div><br></div><div>First phase: =A0Lookup A, AAAA and START RRs for unpref=
> ixed record</div><div>Second phase (if needed): Lookup =A0DETAIL, SRV recor=
> ds</div><div><br></div><div><br></div><div><br></div><div>-- <br>Website: <=
> a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
> <br>
> </div>
> 
> --20cf3043523476ac4c0493ffc8f5--
> 
> --===============1223621894==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
> 
> --===============1223621894==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Nov 2010 17:20:53 +0000

> refining down to very specific policies for specific protocols, hosts and

I think this is over-complicated. Each service should be terated
independently by the protocol. If a site wants to specify policy at a
coarser level then they will need to repeat the policy for each service
that the policy applies to.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Nov 2010 17:36:43 -0400

If prefixes worked like I would like them to, I would just have
prefixed records.

But the constraints on prefixes means that you either have to accept
some limitations on the use of DNS or start your discovery process
with an unprefixed record.

So its more a case of making a virtue out of an (almost) necessity.