Subject: Re: [dns-privacy] DPRIVe Agenda requests for Berlin

From: Tim Wicinski <[email-masked]>
Date: Thu, 2 Jun 2016 12:00:43 -0400

All

Since we never heard anything back from folks about needed face time in 
Berlin, Warren and I have decided to cancel our time slot and give it to 
a more needy working group.

We will both be around in Berlin if anyone feels the need to bend our 
collective ears.

tim

On 5/25/16 7:54 PM, Tim Wicinski wrote:
> All
>
> Since the last meeting, the DNS over TLS draft has been published as
> RFC7858.  The drafts on DNS over DTLS and the Profiles drafts received
> feedback during the last meeting and we are awaiting updates.
>
> The chairs have requested a slot for the upcoming Berlin meeting, though
> we feel that currently in a waiting position.  We're asking authors if
> they wish for any time for the meeting, and if so to please contact the
> chairs, as well as have document updates before 1 June 2016.
>
> The chairs currently are considering returning the meeting slot for
> Berlin if there is not enough work to consider.
>
> thanks

---

From: Shane Kerr <[email-masked]>
Date: Mon, 6 Jun 2016 17:53:56 +0800

Tim,

The standards work of securing the stub to resolver is done enough that
the focus on that has shifted to experimental implementations and
operational issues. Is it time to think about a re-charter to
explicitly list other work?

(Alternately this group could be shut down and one or more new WG
opened for other DNS privacy-related topics. I tend to think a
re-charter makes more sense, but others may disagree.)

I'm basically thinking that the next step is encrypting the
resolver-to-authority session, right? Steps beyond that to increase
privacy are much tricker, since they involve defeating traffic
analysis, but it seems like encrypting resolver-to-authority is
more-or-less well understood.

Cheers,

--
Shane

At 2016-06-02 12:00:43 -0400
Tim Wicinski <[email-masked]> wrote:

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

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 6 Jun 2016 07:19:31 -0400

Shane

We still have some work in flight - the DTLS draft is out there, waiting 
for someone to produce some running code. Additionally, the Profiles 
draft is actually more immediate., just moving slowly

We started the discussion a few meetings back that we are planning on 
recharting to address the resolver-to-authority session.  We (warren and 
myself) wanted to wait until we've started seeing deployment and have 
gotten some operational data sets that would give every the warm fuzzy 
feelings needed to move along.

tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jun 2016 12:24:00 +0200

On Mon, Jun 06, 2016 at 07:19:31AM -0400,
 Tim Wicinski <[email-masked]> wrote 
 a message of 79 lines which said:

> We started the discussion a few meetings back that we are planning
> on recharting to address the resolver-to-authority session.  We
> (warren and myself) wanted to wait until we've started seeing
> deployment and have gotten some operational data sets that would
> give every the warm fuzzy feelings needed to move along.

In the mean time, if someone is brave enough to write an individual
I-D describing the resolver-to-authority usage of TLS. Distribution of
the keys is of course the biggest difference with RFC 7858. The
security/authentication model has to be completely different. I see
several solutions:

* encoding the key in the auth. server name (as in DNScurve)
* publishing keys in the DNS, secured with DNSSEC (as in DANE), which
  raises an interesting bootstrap problem,
* not checking the keys at all, accepting anything,
* add here your own favorite solution.

Documenting these possible choices would certainly help and we don't
need rechartering to write/read an individual draft :-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jun 2016 13:43:45 +0200

On Fri, Jun 10, 2016 at 12:24:00PM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 29 lines which said:

> I see several solutions:

Kim-Minh Kaplan reminded me I forgot the most obvious one: using the
X.509 security model. Certs for authoritative name servers, signed by
regular CAs, with the IP address of the server in the Subject
Alternative Name.

Also, these solutions can be improved by solutions like automatic key
pinning (see RFC 6797).

---

From: Paul Wouters <[email-masked]>
Date: Fri, 10 Jun 2016 09:55:20 -0400 (EDT)

> regular CAs, with the IP address of the server in the Subject

It seems foolish to me to merge the X509 and DNSSEC PKI's into one.

Publishing a TLSA record pinning just the public key seems more in line
for authoritative servers, for which you will always have a name, eg:

_53._tcp.ns0.nohats.ca. IN TLSA 3 0 1 323e3584ba6f986cf09f27cf260cac42f5e5bd5e81df705fd33ac59717110389

For recursive's that is a little harder because the reverse tree is
not so useful. While validating dns.google.com is easy, there can
easilly be a evil.com certificate that also references 8.8.8.8.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 10 Jun 2016 10:03:16 -0400 (EDT)

>  raises an interesting bootstrap problem,

Ohhh I forgot about that. I should have coffee before making up crypto
schemes (and before I suggest adding a new DS key type :)

Paul

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 10 Jun 2016 12:57:33 -0400

> _53._tcp.ns0.nohats.ca. IN TLSA 3 0 1 323e3584ba6f986cf09f27cf260cac42f5e5bd5e81df705fd33ac59717110389

_53 or _853 ?

-- 
Robert Edmonds

---

From: Shumon Huque <[email-masked]>
Date: Fri, 10 Jun 2016 22:20:15 -0400

> schemes (and before I suggest adding a new DS key type :)

One possible way of addressing the chicken-and-egg problem is for
the DNS/TLS authoritative server to employ the proposed TLS DNSSEC
chain extension to deliver its DANE record chain during the TLS
handshake.

This has already been proposed for the stub-recursive case. See
section 9.2.2 of
https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles

> easilly be a evil.com certificate that also references 8.8.8.8.

For the stub to recursive case, the current authentication profiles
draft assumes that the stub is preconfigured with the hostname (or
service name) of the recursive server. So no reverse DNS entries
are involved.

-- 
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Fri, 10 Jun 2016 22:21:19 -0400

On Fri, Jun 10, 2016 at 12:57 PM, Robert Edmonds <[email-masked]> wrote:

> > _53._tcp.ns0.nohats.ca. IN TLSA 3 0 1
> 323e3584ba6f986cf09f27cf260cac42f5e5bd5e81df705fd33ac59717110389
>
> _53 or _853 ?
>

Yup, _853

-- 
Shumon Huque

---

From: Robert Edmonds <[email-masked]>
Date: Sat, 11 Jun 2016 01:29:09 -0400

> more-or-less well understood.

It seems like you would want to encrypt traffic between AXFR client and
AXFR server as well. Even if the data in a zone is public, being able to
collect the history of a zone (e.g. to be able to tell the exact instant
a particular record of interest was added to it) may be useful to an
attacker. And key distribution between AXFR clients and servers is
probably even more well understood than key distribution between
resolver and authority.

-- 
Robert Edmonds

---

From: Shumon Huque <[email-masked]>
Date: Sat, 11 Jun 2016 12:35:34 -0400

On Fri, Jun 10, 2016 at 11:46 PM, Paul Wouters <[email-masked]> wrote:

> That assumes DNS lookups are for TLS......
>

I'm not sure I follow you Paul. This should work for any recursive
to authority communication where TLS and DANE is available. To
quickly sketch out what I was thinking (this is off the cuff and likely
needs refinements/corrections; feel free to poke holes if you find
any) ...

Resolver signals dnssec_chain support in TLS handshake with a
TLS equipped authoritative server. If server response provides the
dnssec_chain, then perform DANE authentication of the server. Otherwise,
authenticate the server in some other way (public CA system, static
pre-configuration, or if allowed, just resort to unauthenticated TLS).

Note: in this scheme, the TLSA record is associated with the zone name,
not the NS record name, because a DNSSEC secured referral authenticates
the zone name (not NS names provided in referral data). This means
sharing a TLSA record set across all nameservers for a zone, but not
necessarily TLS server credentials. The TLSA RRset could identify
multiple distinct certificates or keys, if zone operators wanted
compartmentalization of TLS credentials across servers (which might
be important if multiple organizations are involved in running the
servers).

(It may be possible to securely authenticate DANE records at the NS
names instead - but I haven't thought through that case yet. The zone
name method seems simpler.)

res-> .
                connect with TLS
                verify DANE auth chain for _853._tcp. TLSA
                authenticate server cert, pubkey, or raw pubkey
                query: www.example.org. A
                response: signed referral to org.

res->com.
                connect with TLS
                verify DANE auth chain for _853._tcp.org. TLSA
                authenticate server cert, pubkey, or raw pubkey
                query: www.example.org. A
                response: signed referral to example.org.

res->example.com.
                connect with TLS
                verify DANE auth chain for _853._tcp.example.org. TLSA
                authenticate server cert, pubkey, or raw pubkey
                query: www.example.org. A
                response: answer: www.example.org. A 1.2.3.4

DANE can be used selectively where available in this scheme. e.g. If
the root servers don't do DANE (or TLS), the resolver obtaining a
secure delegation could follow referrals and then attempt DANE
authentication with the delegated zones, etc.

A possible objection to using the TLS extension is that authoritative
servers now have to do additional work querying for and maintaining
the chain for their own DANE record. But that's small potatoes compared
to the aggregate work of doing TLS.

I'm not advocating this approach at this stage. Just sketching out a way
that DANE might be used to provide authenticated TLS between resolver
and authority servers. And obviously, other modes of authentication will
need to be supported as well in the  general case, because DNSSEC is
not universally deployed.

-- 
Shumon Huque

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Sun, 12 Jun 2016 07:32:50 +0000

Hi,

Please excuse my potentially uniformed comment, but
I think that DANE and DNSSEC try to solve the autheniticity
problem (i.e I am talking to a valid auth NS).

The privacy discussion is about not allowing trivial mass surveillance.
Thus, I would have thought that any reasonable encryption is 
good.  E.g opportunitistic, CA, OpenPG, ... to the widest 
possible extent.

The two need to be combined for AFXR / IFXR as the secondary
server needs to be sure about the identity of the master (data source).

It would also be important for caching resolvers who wish to pass
on this degree of assurance to their clients.  This should be a 
choice.  People may wish to prioritise privacy over authenticity.
(Personally, I would like both, but I am not everyone).

End point clients who are directly querying auth NS's (which we
hope is a relatively rare thing) may not care so much about 
the authenticity of the authoritative NS but do care about privacy
and so hope for opportunistic encryption.

To summarise: there are two issues, authenticity and privacy,
and we should where possible allow for the greatest flexibility
in the selection of mechanisms for either and their combination.

Different client types (secondary servers, caching resolvers, 
end points) may have different priorities in what they care
about and some combinations of authenticity and privacy
may be easier than others for various parties and what is 
easier may vary.

Regards,
Hugo Connery
--
Head of IT, DTU Environment, http://www.env.dtu.dk
For data, integrity is critical, availability is convenience.  Get both with git.
________________________________________
From: dns-privacy [[email-masked]] on behalf of Shumon Huque [[email-masked]]
Sent: Saturday, 11 June 2016 18:35
To: [email-masked]
Subject: Re: [dns-privacy] Recharter discussion? (was DPRIVe Agenda requests for Berlin)

On Fri, Jun 10, 2016 at 11:46 PM, Paul Wouters <[email-masked]<mailto:[email-masked]>> wrote:
That assumes DNS lookups are for TLS......

res-> .
                connect with TLS
                verify DANE auth chain for _853._tcp. TLSA
                authenticate server cert, pubkey, or raw pubkey
                query: www.example.org<http://www.example.org>. A
                response: signed referral to org.

res->com.
                connect with TLS
                verify DANE auth chain for _853._tcp.org<http://tcp.org>. TLSA
                authenticate server cert, pubkey, or raw pubkey
                query: www.example.org<http://www.example.org>. A
                response: signed referral to example.org<http://example.org>.

res->example.com<http://example.com>.
                connect with TLS
                verify DANE auth chain for _853._tcp.example.org<http://tcp.example.org>. TLSA
                authenticate server cert, pubkey, or raw pubkey
                query: www.example.org<http://www.example.org>. A
                response: answer: www.example.org<http://www.example.org>. A 1.2.3.4

--
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Sun, 12 Jun 2016 14:04:31 -0500

> good.  E.g opportunitistic, CA, OpenPG, ... to the widest

This depends on what threats you are concerned about. I think many
folks will argue that defeating non-trivial forms of mass surveillance,
including active attacks is important, in which case you need strong
authenticated encryption mechanisms.

> server needs to be sure about the identity of the master (data source).

It's already fairly common practice today to authenticate zone
transfers, mostly using shared secret based transaction signatures.
To address the privacy issue, it might be simplest to consider using
pre-shared key TLS, re-using the shared secrets already in place
for TSIG. Although to get forward secrecy we'd have to use the DHE
form of TLS-PSK, which means more work in the form of generating
fresh DH params on each session.

[...]

> may be easier than others for various parties and what is

Sure - the current DNS privacy mechanisms being developed offer
solutions for both opportunistic and strict security. See RFC 7858
and the TLS authentication profiles draft for examples. So I think
this is being addressed.

-- 
Shumon Huque

---

From: Shane Kerr <[email-masked]>
Date: Mon, 13 Jun 2016 17:38:26 +0200

Robert,

At 2016-06-11 01:29:09 -0400

> probably even more well understood than key distribution between

Hm... interesting point.

Is there any reason not to use DNS over TLS for this purpose?

Are there other considerations? (I guess maybe disabling both NOTIFY
and IXFR for sensitive zones, as NOTIFY will leak information about the
specific timings of zone changes and IXFR will leak information about
the size of said changes.)

Cheers,

--
Shane