Subject: [keyassure] Asserting DANE exclusivity for an entire domain

From: Matt McCutchen <[email-masked]>
Date: Tue, 01 Feb 2011 10:49:00 -0500

I would like to assert DANE exclusivity for the entire domain
mattmccutchen.net so that, with respect to clients that check DANE first
and fall back to a mainstream public CA list, a shady CA cannot
impersonate my existing TLS services /or/ fabricate TLS services I do
not offer.  I know I can achieve that by adding enough wildcard dummy
TLSA records to cover the entire namespace as an automated
postprocessing step, but that is a little ugly.

One solution would be to have the client, when no TLSA exists at the
desired host/transport/port after following CNAMEs, search from the host
name up for a "DANE options" record with an exclusivity flag (which
could be on or off).  If no such record is found all the way up to the
root zone, the default is "off".  Do people think this would be worth
the implementation effort and the extra queries?

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Feb 2011 11:10:59 -0500

Let us assume that you are signing your domain with DNSSEC.

It follows that clients will be able to determine with certainty that a
specific subdomain does not exist.

Thus it will be impossible for a client to obtain a valid A record or SRV
record or any other record that would enable a connection to be made.

It follows that this is not an issue for subdomains that do not exist.

For domains that do exist, the administrator can add a CAA or DANE record to
express the desired semantics.

This is certainly an issue for CAA which deals with issue since it is
entirely valid for a domain name holder to request a certificate for a
subdomain before the subdomain is created. And so the rules for issuer
processing of CAA records require a check at the public delegation point
should the check at the domain fail.

The cost of implementation in a client is rather higher since it has to
maintain a list of public delegation points and has to perform verification
in at least two places.

Maintaining a list of public delegation points in a client is non trivial.
In addition to the non trivial problem of adding/deleting points from the
list it is necessary to have a means of distribution.

On Tue, Feb 1, 2011 at 10:49 AM, Matt McCutchen <[email-masked]>wrote:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 1 Feb 2011 08:21:36 -0800

> express the desired semantics.

It occurs to me that there is currently no such thing as a DANE record
that expresses "there are no TLS-secured services provided by this
domain name" (or "...by this port").  Maybe there should be one?  I
suggest that the record with hash type 0, cert type 0, and zero bytes
of certificate data could have this meaning.  Under the _nnn._tcp.host
proposal being discussed in the other thread, you could then have

$ORIGIN example.com.

www                 A  w.x.y.z
_443._tcp.www  TLSA ( 1 2 ...hash... )
*.www               TLSA ( 0 0 )

to indicate that 'www.example.com' provides HTTPS service with a
particular key, but does not provide any other secured service.

zw

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 1 Feb 2011 08:25:02 -0800

> particular key, but does not provide any other secured service.

Stupid question:  Couldn't this be done with NSEC/NSEC3 records?

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 1 Feb 2011 09:19:40 -0800

On Tue, Feb 1, 2011 at 8:25 AM, Nicholas Weaver
<[email-masked]> wrote:
>> domain name" (or "...by this port").  Maybe there should be one?
[...]
> Stupid question:  Couldn't this be done with NSEC/NSEC3 records?

I don't think so, because the "secured" (RFC4033-sense) absence of a
TLSA record has to mean "fall back to pre-DANE behavior" for
compatibility's sake.  We don't want to force people to adopt DANE
just so they can adopt DNSSEC.

zw

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Feb 2011 14:03:23 -0500 (EST)

On Tue, 1 Feb 2011, Zack Weinberg wrote:

> domain name"

Not having them in a signed zone? And the same for CA based certs.

If there is a DANE record, then any wise client should interpret that
as an exclusive list of allowed TLS certificates, and any certs presented
to the browser by SomeCA which is not in DNSSEC should be rejected as false.

If you don't do this, DANE becomes as weak as the weakest CA. And that's
not very strong.

Paul

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 1 Feb 2011 13:32:14 -0800

> Not having them in a signed zone? And the same for CA based certs.

The *absence* of a DANE record in a signed zone has to mean fall back
to legacy behavior, otherwise we force people to adopt DANE just so
they can sign their zones.  So that won't work.

> as an exclusive list of allowed TLS certificates

I agree with this, but the question is how do you present an empty list.

zw

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Feb 2011 23:42:27 +0100 (MET)

> I agree with this, but the question is how do you present an empty list.

What exactly would you want to convey with an empty list?

 "I won't respond to TLS, so don't even bother trying"

The only time when such an information becomes interesting is when
you have a client with a strong desire to communicate with a target
and intent/preference for using TLS-protection on that communication.

DANE-unaware clients will continue trying to use TLS.
What is your rationale for making DANE-aware clients exhibit
a different behaviour and entirely stop trying to use TLS?  

-Martin

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 1 Feb 2011 14:46:14 -0800

>  "I won't respond to TLS, so don't even bother trying"

Well, this was originally Matt's requirement, not mine.  I just
suggested how it might be represented in the DNS.  Matt, can you
expand on why this would be useful to you?

zw

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 2 Feb 2011 08:31:45 +0100

On 1 feb 2011, at 16.49, Matt McCutchen wrote:

> not offer.

This sounds like the opposite of STS (Strict Transport Security), i.e. policy and not key association distribution.

	jakob

---

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

> the implementation effort and the extra queries?

The crawling up to the root is a call for serious problems.  You don't 
want the _parent_ zone (at the zone cuts) to decide what's the _child_ 
zone security policy.

Moreover that are lot of security problems with this type of crawling 
(f.e. WPAD vulnerability).

O.
-- 
  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: Matt McCutchen <[email-masked]>
Date: Wed, 02 Feb 2011 09:31:19 -0500

> want the _parent_ zone (at the zone cuts) to decide what's the _child_ 

If there is an easy way to stop at a zone cut (e.g., by detecting the
SOA record), that would be fine.  I thought it might be more trouble
than it is worth.  The case in which this makes a difference is when one
zone asserts DANE exclusivity, but its subzones make no statement.
Should we assume they use DANE exclusively too or give them the default
of no exclusivity?  The latter approach has the potential to fail open
if an organization splits off some of its DNS space into another zone
and forgets to put another exclusive-DANE flag in that zone.

> (f.e. WPAD vulnerability).

The problem with WPAD is that it uses a name that can be registered by
untrusted parties.  That is not the case with this proposal, which would
put the record at the ancestor name.

-- 
Matt

---

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

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

MM> If there is an easy way to stop at a zone cut (e.g., by detecting
MM> the SOA record), that would be fine.

Since we rely on DNSSEC anyway, DS records are the ideal way to
determine zone cut points.  They are grabbed anyway as a matter
of course and provide all the clue required.

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

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 02 Feb 2011 18:18:36 -0500

> of course and provide all the clue required.

Right... but do DNSSEC client libraries make it easy to access this
information without doing a separate query for the DS record?

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 02 Feb 2011 18:28:09 -0500

On Tue, 2011-02-01 at 11:10 -0500, Phillip Hallam-Baker wrote:
> It follows that clients will be able to determine with certainty that
> a specific subdomain does not exist. 
> 
> Thus it will be impossible for a client to obtain a valid A record or
> SRV record or any other record that would enable a connection to be
> made.

Excellent point, but I can think of two cases in which this assumption
fails:

- Using an HTTP proxy
- In XMPP server-to-server communication, authenticating the client of
the connection

More broadly, people have developed the mindset and expectation that no
matter how they make a connection, authenticated TLS will cover their
backs.  So I think the assumption you propose is fragile; I don't wish
to make it.  It doesn't buy much in terms of reducing the number of
wildcard records needed, either.

-- 
Matt

---

From: James Cloos <[email-masked]>
Date: Thu, 03 Feb 2011 11:45:05 -0500

>> of course and provide all the clue required.

MM> Right... but do DNSSEC client libraries make it easy to access this
MM> information without doing a separate query for the DS record?

Even if they do not, the resolver had to grab the DS as part of the
validation, so the round trip for an extra DS lookup by the end client
is by definition local, often even same-process.

-JimC

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Feb 2011 12:02:45 -0500

On Wed, Feb 02, 2011 at 09:36:31AM +0100, Ondřej Surý wrote:

> The crawling up to the root is a call for serious problems.

Apart from all the good reasons Ondřej mentions, there's also the fact
that it imposes load on a parent who ought not to need to participate
in most of this.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Feb 2011 12:04:37 -0500

> information without doing a separate query for the DS record?

Client libraries are going to have to learn this if they're going to
do meaningful DNSSEC work.  I understand and sympathize with the
desire to make the DNS a perfect black box, but if applications want
to do interesting things with DNS data, they're going to have to
become something less than agnostic about what that data is.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Feb 2011 12:11:55 -0500

> that it imposes load on a parent who ought not to need to participate

One of the discoveries we made in DKIM was that ephemera such as zone cuts
that are visible at the resolver level cannot be relied on to be visible at
the client level.

As a general architectural principle, there has to be orthogonality in the
design of a key distribution mechanism. In particular

* Deployment in a sub zone must not affect the parent

* Deployment in a parent must not affect a sub zone unless this is
explicitly desired.

* Deployment for protocol X must not cause applications to reject valid keys
for protocol Y unless this is explicitly desired.

* Deployment for protocol X must not create a key that applications will
accept for protocol Y unless this is explicitly desired.

These are exactly the type of architectural principles that people look
towards the IESG and IAB to enforce.

WG consensus that the group would rather prefer performance or certain forms
of administrative convenience than meeting these requirements is unlikely to
reflect IETF consensus.

Crawling the root has been long established as a bad idea.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 Feb 2011 12:34:42 -0500 (EST)

On Thu, 3 Feb 2011, Andrew Sullivan wrote:

> do meaningful DNSSEC work.

I browser should just be able to lookup a TLSA record from the validating
localhost dns server, without any further knowledge of dnssec or DS records.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 Feb 2011 09:39:20 -0800

> localhost dns server, without any further knowledge of dnssec or DS records.

I disagree, strongly.

a)  What APIs currently exist that would allow a TLSA record to be looked up rather than an A record.  So new APIs are probably required anyway.

b)  It is the APPLICATION, not the resolver, that needs to know what to do if the DNSSEC portion of the TLSA record fails.

Doing meaningful DNSSEC-using applications without getting the reason FOR a DNSSEC failure is asking for trouble.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Feb 2011 12:56:55 -0500

> that are visible at the resolver level cannot be relied on to be visible at

My memory of that discussion was rather that the DNS geeks kept saying
that zone cuts were a lousy thing to rely on, and you shouldn't do it.
But let's not fight that battle over again.

> of administrative convenience than meeting these requirements is unlikely to

Agreed.  But we actually _do_ have a reliable mechanism to detect zone
cuts here, because we _have to_ have one, because without DNSSEC this
entire scheme is a waste of time.  The DS record establishes it.  I am
not arguing that the zone cut is going to be visible to general
purpose clients, but surely a client that is doing the kind of work
we're talking about can be expected to be more sophisticated than
getaddrinfo().

> Crawling the root has been long established as a bad idea.

Fully agree.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Feb 2011 13:00:56 -0500

On Thu, Feb 3, 2011 at 12:39 PM, Nicholas Weaver
<[email-masked]>wrote:

> a)  What APIs currently exist that would allow a TLSA record to be looked
> up rather than an A record.  So new APIs are probably required anyway.
>
> b)  It is the APPLICATION, not the resolver, that needs to know what to do
> if the DNSSEC portion of the TLSA record fails.
>

I think it is necessary to phrase the question in a different way. Instead
of assuming that the existing API support is automatically going to improve
to support DANE and like proposals, consider instead what applications are
going to have to do to circumvent local DNS mechanisms and in what
circumstances they should be able to do so.

There are two cases of interest to me:

1) An enterprise user using a home machine

2) A home user attempting to gain unrestricted access to the world media
regardless of government imposed censorship.

In the first case the machine is owned by the enterprise and the enterprise
has the right to decide that it does not want it to be connecting to random
Internet sites that may be attempting to install malware or negatively
impact productivity. Many enterprises do just that by deploying operating
systems that allow them to impose configuration restrictions on
applications.

While certain regimes have attempted this approach to enforce political
censorship, it is rather harder to impose. For example, the Iranian
government operates what is essentially a warez site from which citizens can
download software of their choice - together with government installed
backdoors.

In practice, it is rather hard to impose that degree of control on a machine
that the consumer has acquired independently. Certainly the user is going to
be very aware that the controls are being imposed.

My view is that if we want to get clean access to the Internet DNS,
applications are going to have to be prepared to use libraries that are
designed to route around port 53 restrictions if that is what it takes.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Feb 2011 13:04:43 -0500

> localhost dns server, without any further knowledge of dnssec or DS records.

The "zone cut" is not the criterion you want, and I assert that it is
not possible to do anything interesting with the notion of zones for
security.  We've seen this over and over again.  Either the zone cut
is important, and you are willing to do the work to detect it
reliably, or else inheritance in the DNS itself is not allowed for
these security policies.

I have repeatedly in the past suggested a sort of meta-info service
about the DNS, where zones have the (signed) ability to return a
location for policy informaiton.  For instance, in this case, one
would have SRV-or-whatever pointers off to the policy for a zone that
says, "I assert policy for the following zones".  The policy document
is actually delivered via https or something like that.  If and only
if the asserted-for zone contains a (validatable) pointer to the same
policy, then a client can accept that policy.  This gets us out of the
mess resulting from trying to infer anything from zone cuts.  (The
reason this is so general purpose is because it can have other uses
too.  Think of solving the cookies-in-a-domain problem and the
IDNA2008 language-tables policy problems using the same mechanism, for
starters.)

Unfortunately, every time I have floated this idea, I have been told
by application people that they won't use it because they don't have
an interface, or because it's too many lookups and will take too long.
This out of hand rejection has caused me never to bother to write the
needed I-D.  On the other hand, it has the conspicuous advantage that
it would work where detecting zone cuts won't, which is why I continue
to nurture it.  If anyone thinks this is not-obviously-stupid now, I
will write it up properly.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Feb 2011 13:05:33 -0500

> The "zone cut" is not the criterion you want, and I assert that it is

s/The/Then/.  Sorry.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Feb 2011 13:08:00 -0500

There is a very strong probability that where there is a separation of
control, there will be a zone cut and a DS record.

The problem comes the other way, the fact that a DS record is encountered is
a much less reliable indicator of a separation of control.

If something is going to be an administrative convenience rather than an
inconvenience, it has to work almost very close to 100% of the time and in
particular it must not introduce side effects to existing administration
procedures.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 Feb 2011 13:08:28 -0500 (EST)

> Doing meaningful DNSSEC-using applications without getting the reason FOR a DNSSEC failure is asking for trouble.

That should only be needed for error handling, not for regular succeeding lookups that
return either the TLSA record or an NSEC*.

Yes, the application will have to deal with various kind of ServFails, but in its regular
operation it should just do a lookup, either get a TLSA record or not, and move on. This
case surely should not depend on the application knowing about zone cuts or DS records.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Feb 2011 13:20:59 -0500

> control, there will be a zone cut and a DS record.

Well, yes and no.  University environments are a good example here:
some just do not delegate zones, period; but they do not assert tight
administrative control over departments.  The effect is that you have
separation of control of hosts within department boundaries without
zone cuts.  That seems to me to be an important use case.

The same can be true in some corporate environments, where zone cuts
do not correspond very well with administrative control differences.

I know some will regard these as artificial examples, but having
worked under each I contend that they're real and ought to be
considered.

> a much less reliable indicator of a separation of control.

Also yes and no.  In some ways, it's _necessarily_ a separation of
control: the two sides of a zone cut are as a matter of protocol just
independent.  The protocol relies on the operators to make them agree.
And anyway, a system that uses zone cuts as an indicator of control
boundaries need not be a problem: the single operator of both sides
already knows how to co-ordinate changes across the cut, so I don't
see what the problem there could be.  I think this is a red herring.

> particular it must not introduce side effects to existing administration

I fully disagree with the latter claim.  _By definition_ a new feature
might introduce side effects to existing administration procedures.
This is a matter of trade-off, and not one of necessity universally
quantified.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

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

On Thu, 2011-02-03 at 12:02 -0500, Andrew Sullivan wrote:
> there's also the fact

Not any more than the DNSKEY RRset does.  Either RRset will be cached by
the ISP as soon as one client cares about it.

-- 
Matt

---

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

On Wed, 2011-02-02 at 08:31 +0100, Jakob Schlyter wrote: 
> This sounds like the opposite of STS (Strict Transport Security),

I don't follow.

> i.e. policy and not key association distribution.

Gah...

Asserting TLSA exclusivity for an entire domain is not fundamentally
different from asserting it for a single _port._transport.host, just
grander in scale.  It's equivalent to a thicket of wildcard exclusive
TLSA records with empty certificate sets.

Ultimately, any of these directives can be viewed as an assertion or a
suggested policy.  Of course clients can do as they wish; the idea is
that the admin disclaims responsibility for anything bad that might
happen to the client as a result of it not following the policy.

-- 
Matt

---

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

> particular key, but does not provide any other secured service.

So a single TLSA RR with this sentinel value represents an exclusive
empty set?  Sounds good to me.

If we support nonexclusive TLSA for individual services, we'll probably
want to refactor this to have RRs that just make positive endorsements
of certificates and a special RR that indicates exclusivity.  Then, no
TLSA RRs at all would mean no endorsements and no exclusivity.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 04 Feb 2011 00:09:18 -0500

>  "I won't respond to TLS, so don't even bother trying"

More precisely, "there is no TLS service associated with this DNS
name/transport/port".  Therefore, general-purpose clients that refer to
TLS services by DNS name/transport/port will not be able to make a
connection.  This does not preclude the admin to run a TLS server for
some special purpose, to accept connections only from specially
configured clients, but in most cases it will make sense to use DANE.

> a different behaviour and entirely stop trying to use TLS?

I assert that I do not offer the TLS service, so there is no point in
DANE clients trying to connect to it.  In particular, I do not want them
to connect to some fake service with a certificate from a public CA.
There is nothing I can do about the DANE-unaware clients.

-- 
Matt

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 3 Feb 2011 21:21:51 -0800

> empty set?  Sounds good to me.

Yah.

> TLSA RRs at all would mean no endorsements and no exclusivity.

I'd rather keep that argument out of this thread, but at present I
don't see a use case for nonexclusive.

zw

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Feb 2011 08:12:59 -0500

> the ISP as soon as one client cares about it.

I think you mean the DS, since the DNSKEY isn't at the parent.  But
that's not the only case anyway.  As I understand it, the idea here is
that you're going to crawl up and look to see whether the parent
includes a record "covering" the policy in the child.  TLDs won't have
such a record, which will mean that they'll get a lot of queries for
things they don't have.  Negative caches don't last long.

This is why I claim that the only sensible way to look for the zone
cut, if that's what we're going to do, is to use the DS record itself,
because you're guaranteed to need it or a configured trust anchor for
this scheme to work.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 05 Feb 2011 07:53:30 +1100

> because you're guaranteed to need it or a configured trust anchor for

Give the amount of broken DNS implementations out there you can't do
this reliably with any query.  SOA and NS should be in every zone but
they are not.

	DS don't exist with islands of trust.
	DNSKEY doesn't exist with non-signed zones.
	SOA/NS not answered by GLB's.
 
Mark

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Feb 2011 16:15:40 -0500

> 	DS don't exist with islands of trust.

Right, but in that case you have a DNSKEY with no DS at the parent.

> 	DNSKEY doesn't exist with non-signed zones.

Non-signed zones aren't a consideration here, because they're never
going to be candidates for any of the DANE output.  Normally, it's a
problem, but not in this case.

> 	SOA/NS not answered by GLB's.

Yes.  But we don't care, because the DS/DNSKEY point is the one we
need.  Either you have a DS through which you can build a chain, or
you have a TA matching the DNSKEY, or you don't use the data from this
zone (for these purposes).

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 Feb 2011 18:52:56 -0500 (EST)

> 	SOA/NS not answered by GLB's.

Cisco should fix that :)

Paul

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 Feb 2011 17:39:32 +0100 (MET)

> > and intent/preference for using TLS-protection on that communication.

I should have been more explicit on this:

There is a client with a desire to communicate, and a preference/intend
for TLS-protection.  But with most protocols, there is a fallback
strategy to communicate without TLS.  It could be that the initial
reference does not even imply TLS, and its only the client who is
looking for clues in DNS whether TLS is available.

So I'm still wondering: what message should an empty list convey?

A pre-DANE client might fallback to non-TLS if TLS doesn't work,
or it might not try TLS at all.

What should a DANE-aware client, that is wildly determined to communicate
do when finding an empty TLSA record?  Go straight for the unprotected
communication (which is what such a record would imply), or bother
the user with an annoying popup before doing the fallback on unprotected
communication.

I doubt that "not communicating at all" is a workable solution for such
clients, because it is likely to be perceived as a usability problem
by a non-marginal fraction of the user base.

Most "Web users" think that "the Web" == "the Internet" and are so completely
accustomed to trust everyone with everything over completely insecure
communication channels (commonly described with "http://")
that it is going to be hard to turn back time on this.

I'm currently quite annoyed of my EMail provider, because their Web-Mail
interface completely refuses to serve a login page via HTTPS:
They do "POST" to a HTTPS url on their Login-Page, but that page itself
is accessible only through HTTP (on a host that does not listen on 443).

> There is nothing I can do about the DANE-unaware clients.

While there are a few clients of the type "TLS or refuse to connect",
the vast majority of clients will happily connect without TLS instead,
and end users have been conditioned over more than a decade that
fallbacks are OK.

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Feb 2011 12:34:51 -0500 (EST)

On Wed, 9 Feb 2011, Martin Rex wrote:

>> connection.

What's wrong with an NSEC record for the TLSA/HASTLS record saying that?

> looking for clues in DNS whether TLS is available.

This is why in HASTLS, you can state whether or not there is a fallback you
may use.

> the user with an annoying popup before doing the fallback on unprotected

An empty TLSA record offers nothing more over an NSEC record.

> by a non-marginal fraction of the user base.

Yet, that is what security will require. If a TLSA record states there is
TLS, or a DNSSEC error occurs trying to get a TLS related record, you
SHOULD NOT fallback to plaintext.

The usability issue is in running legacy port 80..... Fix that and your problem
will go away. Then at most the user will see a bad/hacked cert with a popup,
hopefully preventing the user from connecting.

> that it is going to be hard to turn back time on this.

HASTLS and STS are bascially the start of the end of port 80.

> is accessible only through HTTP (on a host that does not listen on 443).

Tell them that is unacceptable.

Paul

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 9 Feb 2011 11:39:33 -0800

> What's wrong with an NSEC record for the TLSA/HASTLS record saying that?

NSEC for any new DNS record MUST mean "behave as you would have prior
to the invention of the new DNS record".  To do otherwise would
require a flag day for the entire Internet and therefore jeopardize
not only the transition to whatever new DNS record is suggested, but
the transition to DNSSEC itself.

(However, a "bogus" DNSSEC validation state for any lookup at all can
and should be treated as a MUST-refuse-to-proceed condition.)

zw

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Feb 2011 15:03:06 -0500

> the transition to DNSSEC itself.

I don't understand what that means.

An NSEC record with a negative response to a query is a cryptographic
proof that the record doesn't exist.  So in this sense, an NSEC record
for the new DNS RRTYPE works exactly the same way as any other RRTYPE.

But obviously, the _semantics_ of such provable non-existence is
altogether a different matter, for the very same reason that the
semantics of a new RRTYPE could be different for each such type.  No?

> and should be treated as a MUST-refuse-to-proceed condition.)

That is in fact what it's supposed to mean in the DNS, yes.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 9 Feb 2011 12:27:27 -0800

> for the new DNS RRTYPE works exactly the same way as any other RRTYPE.

Right.

> semantics of a new RRTYPE could be different for each such type.  No?

No. Individual zone administrators should be able to sign their zone
_without making any other changes_ and have everything continue to
work as before.  That means the semantics of provable non-existence
needs to be identical to the semantics of "insecure/indeterminate" (in
the RFC 4033 sense) non-existence in all cases, and that in turn has
to be legacy compatibility behavior.

Basically what I am saying is we cannot treat a zone as having
affirmatively opted in to any new application/transport layer
semantics just because their zone is signed.  We have to have a
successful secure lookup of at least one new record.

zw

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Feb 2011 16:44:40 -0500

> successful secure lookup of at least one new record.

Ah, I get what you're arguing.  Hrm.  

So what you want, I think, is a three-value state:

    - zone positively has record
        This amounts to an affirmation by the zone admin that it
        supports the feature.

    - zone asserts it does not have record
        This is an indeterminate state with respect to the new
        feature, because the the signed absence of a record is not a
        meaningful assertion.

    - zone has record asserting no support
        This is the zone admin asserting that it does _not_ support
        the feature.

Is that right?  If it's what you're arguing for, it's a little odd,
because we don't normally require this for other protocols.  That is,
if I'm adding (say) an SMTP extension, your rejection of the extension
says nothing about your awareness of the extension.  Now, you seem to
be arguing in this case that provable non-existence of the record is
not the same as saying you positively don't support the feature, but
I'm not sure I see the additional value in the distinction.  (As a fan
of intuitionistic logic, however, I confess that the three-value
approach has appeal to me personally.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 9 Feb 2011 14:09:27 -0800

>        This is the zone admin asserting that it does _not_ support

Yeah.

> approach has appeal to me personally.)

I am personally only arguing for a weaker position: _if_ "saying that
you positively don't support a feature" is considered to be a use case
worth including in the specification, _then_ that statement must not
be expressed via "zone asserts it does not have record".

Concretely, I'd be okay with TLSA not having a way to say "this domain
positively does not provide any TLS-secured services".  That was Matt
McCutchen's feature request; I can see the use but if it's not
considered valuable enough to include I'd be fine with that.  What I'm
not fine with is being forced to add TLSA records for all secured
services in a zone just so I can start signing it.

zw

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Feb 2011 17:23:29 -0500

> What's wrong with an NSEC record for the TLSA/HASTLS record saying that?

What is wrong is that we are designing two separate mechanisms here when we
should really have one.

This would not matter so much if not for the fact that the design of key
assure is being constrained by attempts to support performance requirements.

So what we are going to end up with here by splitting TLSA and HASTLS is a
scheme that requires two separate records and discovery patterns and is
considerably less efficient than a scheme that was designed to support both
from the start.

In my view the requirement for 'must use TLS' has far deeper support amongst
the client vendors than the requirements DANE is apparently trying to meet.

Thus if DANE does not think about how to work well with HASTLS it is likely
to be irrelevant. It is very easy to glom a key publication scheme onto a
policy record. Working the other way is rather harder.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Feb 2011 22:05:31 -0500 (EST)

On Wed, 9 Feb 2011, Phillip Hallam-Baker wrote:

> So what we are going to end up with here by splitting TLSA and HASTLS is a scheme that requires two separate records and discovery
> patterns and is considerably less efficient than a scheme that was designed to support both from the start.

So can you suggest a format for a new "unified" TLSA/HASTLS record?

> In my view the requirement for 'must use TLS' has far deeper support amongst the client vendors than the requirements DANE is apparently
> trying to meet.

Unfortunately, whenever I suggest a "must use TLS" bit, I'm told  you can't dictate policy in DNS.

> Thus if DANE does not think about how to work well with HASTLS it is likely to be irrelevant.

I'd be interested in seeing your suggestion for a unified record.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Feb 2011 22:11:02 -0500 (EST)

>        This amounts to an affirmation by the zone admin that it

Yes.

>        feature, because the the signed absence of a record is not a

Well, the absense tells you no DANE based TLS is there. There could still be
TLS backed by PKIX.

>        This is the zone admin asserting that it does _not_ support

This would be the "null TLSA" record? I find that record unneccessary. We
also don't have a "null PKIX" record. Is there a desire to create one
for those as well?

Frankly, adding infrastructure to better support insecure protocols makes
no sense to me. Especailly because we are hard on our way on killing
port 80, and the last group of clients on port 80 will be those not
supporting any new RRTYPE anyway.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Feb 2011 22:12:31 -0500 (EST)

> So can you suggest a format for a new "unified" TLSA/HASTLS record?

Just to make it clear. I would be happy with such a unified record. However,
I'd rather not spend another 9 months on that discussion again, because I
fear it would dig up the whole PKIX vs DANE again.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Feb 2011 10:46:49 -0500

Yes, I am working on the draft right now. As you might expect it is an
extension of the concepts in CAA and ESRV using the extension mechanism
anticipated in CAA.

I believe I can support the following criteria with no compromise to any of
them.

1) Correct and predictable interaction with CNAME and wildcards

2) Support for publication of attributes that are specific to a particular
protocol or apply to a whole domain.

3) Ability to prevent downgrade attack by specifying that protocols are
always offered or must be used.

4) Ability to prevent trust substitution attacks such as unauthorized issue
of certificates by CA or use of unauthorized certificates in an application.

5) Ability to advertise end entity keys specific to a domain name or domain
name and protocol

6) Ability to advertise local trust anchors specific to a domain name

7) Support but not require use of service discovery schemes such as SRV,
NAPTR, URI and future schemes as they are developed.

8) Allow for compact implementation. Service discovery must be performed by
every device on the network, including devices whose performance does not
even support a full IP stack. Code complexity must be kept to a minimum.

9) Enable simplified administration by allowing administrative tasks to be
automated.

The above can all be supported in a manner that is completely protocol
neutral with no special cases called out in the mechanism. (i.e. not
specific to PKIX, TLS, application protocol).

However in order to use the mechanism with a particular protocol it is
likely going to be necessary to write up a separate draft for that
particular binding (like we did in SAML). so while I would design the
mechanism to be completely neutral wrt the PKI and security protocol, I
would only consider writing security bindings for PKIX and TLS and
application bindings for HTTP, SMTP, IMAP, POP3 and Jabber.

There is one specific protocol that I think we are going to need to special
case and that is HTTP for Web browsing where the latency issues have a
critical impact on the user experience.

The design constraint here being that use of prefix records will inevitably
degrade latency performance even if an attempt is made to pre-fetch records
before the canonical name of the service is known.

10) Support discovery for attributes relating to interactive HTTP in a
single round trip.

If people like the above set of requirements, I can provide a design that
meets them all with a minimum of mechanism.

If there are other requirements, I may be able to support those in addition.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 10 Feb 2011 19:45:07 +0200

> I believe I can support the following criteria with no compromise to any of

<snip long list>

Based on this list, it looks like scheme that satisifes all of these would
be godawfully complicated (interoperability problems) and require loads
of code to implement (bugs, or in worst case, security bugs)

Remember, this isn't enterprise-only stuff. This needs to be usable
by small scale software and services.

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Feb 2011 14:54:42 -0500

> of code to implement (bugs, or in worst case, security bugs)

Let us judge the complexity of the actual proposals rather than the presumed
complexity of the requirements.

SAML is based on a design that supports the whole of PKIX in less than 20
pages.

I have pretty good metrics for the relative complexity of my scheme vs
others based on the number of states and transitions.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 10 Feb 2011 16:53:52 -0500

> So I'm still wondering: what message should an empty list convey?

Just what I said: there is no TLS service associated with the
host/transport/port.

> that it is going to be hard to turn back time on this.

Any fallback that clients may perform is a separate issue, and we will
need separate mechanisms to control it.  Even considering my proposal in
isolation, I don't see how asserting the absence of a TLS service leaves
clients with fallback worse off.  The only difference it makes is that
they fall back in cases in which they would otherwise make a TLS
connection to an impostor.  At least they know they are not getting a
secure connection if anyone cares to check.

> and end users have been conditioned over more than a decade that

That may be true at a high level, considering how users react to various
situations.  At the level of individual transactions, all of the major
HTTP clients follow "TLS or refuse to connect" for https URLs, and all
of the major mail clients have a checkbox to enable this behavior.  This
is the level I am focused on securing now.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 10 Feb 2011 17:20:55 -0500

> Well, the absense tells you no DANE based TLS is there. There could still be

Correct.

> This would be the "null TLSA" record? I find that record unneccessary.

The record asserts that there is no TLS service at the name, in
particular not a PKIX-authenticated service.

> We

Not sure what you mean.  PKIX-based TLS authentication by its nature
does not support exclusion.

> supporting any new RRTYPE anyway.

I don't know where you got that.  My goal with "null TLSA" is to prevent
public CAs from fabricating a TLS service that I do not offer.  E.g., I
do not operate a site at https://secure.mattmccutchen.net, but if a
public CA spoofed it into existence and invited users to visit it, they
would be inclined to assume that I endorse the content.  (And browsers
would be inclined to let it set cookies for .mattmccutchen.net and
confuse my web apps.  This issue deserves a proper solution, but for now
I am avoiding it by not handing out subdomains.)  Null TLSA might help
some clients find a plaintext service more quickly, but that is not the
point.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 10 Feb 2011 17:37:20 -0500

On Thu, 2011-02-10 at 14:54 -0500, Phillip Hallam-Baker wrote:
> 
> 
> On Thu, Feb 10, 2011 at 12:45 PM, Ilari Liusvaara
> <[email-masked]> wrote:
> Let us judge the complexity of the actual proposals rather than the
> presumed complexity of the requirements.
> 
> 
> SAML is based on a design that supports the whole of PKIX in less than
> 20 pages.
> 
> 

I will believe it when I see it.  And if it means being exposed to
Etisalat for an extra six months while we haggle over the design, I'm
not interested.  (Of course, the WG chairs make the decision, not me.)

-- 
Matt

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 11 Feb 2011 01:31:24 +0200

On Thu, Feb 10, 2011 at 05:20:55PM -0500, Matt McCutchen wrote:
> would be inclined to assume that I endorse the content. 

That attack doesn't work too well: Clients will try to resolve A/AAAA
records for secure.mattmccutchen.net, ending up with authenticated
NXDOMAIN and then complain about unknown host.

Now, this attack could actually work between ports (but would require
MITMing on mass scale).

-Ilari

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 10 Feb 2011 19:20:25 -0500

> NXDOMAIN and then complain about unknown host.

I forgot about that, but see my previous message on the subject:

http://www.ietf.org/mail-archive/web/keyassure/current/msg01679.html

> Now, this attack could actually work between ports (but would require

MITMing is what all of this is about...

-- 
Matt