[dns-privacy] Issues with encoding keys in nameserver DNS names

[Mukund Sivaraman]

There was some discussion in last night's meeting about encoding keys in
the DNS name of a nameserver, similar to DNSCurve. There are at least
some issues with it:

1. The RDATA of an NS record has to be a hostname, so it would limit the
amount of data that can be encoded within the NSDNAME. As an example,
base32 encoding is not possible.

2. It would have to work for nameservers that are within a domain with a
very long name already.

3. Let's assume it takes about 10 years for resolver->auth privacy
transport to trickle into widespread operational availability. It is
expected that quantum computers capable of obsoleting traditional crypto
will be available in as few as 15-20 years from now. It is unclear if
the limited length of keys that can be encoded into a subset of a DNS
name would be sufficient for post-quantum crypto algorithms.

4. NS records returned as part of delegations are unsigned, so for a
resolver to trust key information in the RDATA of such NS records in a
delegation, it would require the delegation to be returned using secure
transport to the parent-side nameserver of the zone cut. During last
night's conversation, there was some talk about fallback to plain
transports - it will not be useful unless the entire delegation from
root is followed with secure transports.

Mukund

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Sample experiments for resolver->auth privacy transport

[Mukund Sivaraman]

Hi all

Some ideas on how to practically test resolver->auth secure transport
was asked during yesterday's dprive meeting. Here are some examples to
test.

Simulate the case of queries for names in the DNS that are hosted
topologically farthest away from the tester. Assume the test is
conducted in the USA, and simulate the case where the names are hosted
in India (other side of the planet) which would theoretically have among
the highest physical latency. An example with some names follow - it is
not possible to explain this with RFC 2606 names only, so please assume
that the following names don't correspond to currently used real-world
names, if any.

Compare overall time to find the answer for the query vs. DNS over UDP
that is used for the majority of DNS queries today.

In each case, check both with and without using QNAME minimization. The
following examples don't use QNAME minimization but have an extra label
so that there is a difference in lookup when the zone cuts aren't known.

(1) In-bailiwick nameservers


Assume the name queried is within the .xn--j2bd4cyah0f TLD (punycode of
devanagari for "hindi"). Let's say a query is
results.2018.nationalexam.xn--j2bd4cyah0f /A.

Assume nationalexam.xn--j2bd4cyah0f is a zone that is hosted by a
university in India.

i. The lookup in the case of cold cache would have to start at a root
nameserver (that would have short RTT in USA) for xn--j2bd4cyah0f.
Assume the answer is an in-bailiwick delegation, so glue address records
are returned as part of the delegation response for
ns1.nationalexam.xn--j2bd4cyah0f and ns2.nationalexam.xn--j2bd4cyah0f,
both of which are located in India.

ii. The resolver then looks up
results.2018.nationalexam.xn--j2bd4cyah0f/A from
ns1.nationalexam.xn--j2bd4cyah0f.

(2) Out of bailiwick nameservers #1
---

Assume the name queried is within the .xn--j2bd4cyah0f TLD (punycode of
devanagari for "hindi"). Let's say a query is
results.2018.nationalexam.xn--j2bd4cyah0f /A.

Assume nationalexam.xn--j2bd4cyah0f is a zone that is hosted by a
university in India.

i. The lookup in the case of cold cache would have to start at a root
nameserver (that would have short RTT in USA) for xn--j2bd4cyah0f. The
delegation is to ns1.someuniversity.ac.in and ns2.someuniversity.ac.in.

ii. Let's assume that .ac.in zone is also hosted in India. The resolver
then looks up ns1.someuniversity.ac.in (and ns2.someuniversity.ac.in
simultaneously usually). This involves following the delegation from
root again for .in, and then for .ac.in, and then someuniversity.ac.in,
and then the NS answer for ns1.someuniversity.ac.in.

iii. The resolver then looks up
results.2018.nationalexam.xn--j2bd4cyah0f/A from
ns1.someuniversity.ac.in.

(3) Out of bailiwick nameservers #2 (with more indirection)
---

Assume the name queried is within the .xn--j2bd4cyah0f TLD (punycode of
devanagari for "hindi"). Let's say a query is
results.2018.nationalexam.xn--j2bd4cyah0f /A.

Assume nationalexam.xn--j2bd4cyah0f is a zone that is hosted by a
university in India.

i. The lookup in the case of cold cache would have to start at a root
nameserver (that would have short RTT in USA) for xn--j2bd4cyah0f. The
delegation is to ns1.cs.someuniversity.ac.in and
ns2.cs.someuniversity.ac.in.

ii. Let's assume that someuniversity.ac.in zone is also hosted in India,
by dnsoperator.co.in. The resolver then looks up
ns1.cs.someuniversity.ac.in (and ns2.cs.someuniversity.ac.in
simultaneously usually). This involves following the delegation for
ac.in, and then someuniversity.ac.in from ac.in's nameservers.

iii. A delegation is returned by .ac.in's nameservers for
ns1.cs.someuniversity.ac.in to ns1.dnsoperator.co.in and
ns2.dnsoperator.co.in.

iv. The resolver has to lookup ns1.dnsoperator.co.in following its
delegation from the nameservers for the closest zonecut it knows, .in.,
and then .co.in.

v. The resolver then looks up ns1.cs.someuniversity.ac.in from
ns1.dnsoperator.co.in and learns its address records.

vi. The resolver then looks up
results.2018.nationalexam.xn--j2bd4cyah0f/A from
ns1.cs.someuniversity.ac.in.



These are the best scenarios where everything works. Simulate problems
where there is trouble contacting nameservers and the resolver has to
try others. Simulate a mix of nameservers under different domains.

Note that a stub (client of the resolver) will timeout a query attempt
in about 5 seconds. It will retry another time or two, but note that
waiting that long for a normal resolution would be terrible for the user
experience.

Assume a cold cache when testing.

I point out once again that resolver->auth is not like stub->resolver
communications where (in the latter case) typically there is 1 resolver
peer which is typically near the stub, and the stub can start an
on-going TLS session and keep it going for the uptime of the stub.

A resolver contacts many 

Re: [dns-privacy] [Ext] DPRIVE Phase 2 Milestones and Requirements for WG Virtual Meeting 2018-12-10

[Benno Overeinder]

Thanks all for your input.

As a reminder, the virtual call is via webex:

https://ietf.webex.com/meet/dprive


-- Benno

On 10/12/2018 16:50, Paul Hoffman wrote:
> On Dec 10, 2018, at 6:37 AM, Erik Nygren  wrote:
>> After some discussing with some colleagues, a few topics that came up which 
>> I added to the wiki for discussion:
> 
> The changes you added all assumed that TLS was going to be the protocol 
> chosen. I have edited (hopefully politely) to indicate that the WG might 
> still choose a connectionless protocol such as sending COSE-based messages.
> 
> --Paul Hoffman
> 
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
> 


-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] DPRIVE Phase 2 Milestones and Requirements for WG Virtual Meeting 2018-12-10

[Paul Hoffman]

On Dec 10, 2018, at 6:37 AM, Erik Nygren  wrote:
> After some discussing with some colleagues, a few topics that came up which I 
> added to the wiki for discussion:

The changes you added all assumed that TLS was going to be the protocol chosen. 
I have edited (hopefully politely) to indicate that the WG might still choose a 
connectionless protocol such as sending COSE-based messages.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

[Brian Haberman]

On 12/10/18 10:46 AM, Barry Greene wrote:
> Will the meeting be recorded?
> 

Yes. I will record the session via Webex and work with the secretariat
to get the recording posted.

Regards,
Brian



signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

[Barry Greene]

Will the meeting be recorded?

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

[Brian Haberman]

Hi dkg,

On 12/10/18 9:55 AM, Daniel Kahn Gillmor wrote:
> On Wed 2018-12-05 10:35:20 -0500, Brian Haberman wrote:
>> I think it would be quite useful if someone were to explore the use of
>> message layer security in the context of DNS. That could be one of the
>> ones you listed above or it could be the work in MLS. Or even Double
>> Ratchet.
>>
>> If any of these helped reduce the potential state management problem for
>> DNS authoritative servers, that would be a major benefit IMO.
> 
> It's not clear to me that MLS has significantly less state to manage
> than TLS 1.3.  Indeed, it might require *more* state management.  Can
> you point to information that suggests there is less of a burden of
> state for MLS implementations? Is statefulness the main concern you're
> trying to address?

State management has been a common theme for some people's concerns. At
this time, I don't think we have a solid view on whether state is the
highest priority, but it certainly gets a lot of attention.

As for MLS, I think the quick exchange with Paul W. has led to MLS not
looking like a good fit. I mentioned it for completeness when message
layer security was raised.

Regards,
Brian




signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Question regarding RFC 7858

[Hans Carlos Hofmann]

Hello,

i have try to implement DoT ... but the part of authenticate the
Certificate is not consistence.
What to hell of Certificate i have to use whit the port 853 tls server? 
The Problem is:
TLS need a Nameserver name to work correct while you need a Ip-Number so
Start DNS translation.

On the Other Hand, DNSSEC prevent DNS forgery.
So why you don't suggest 2 step Boot to a Secure DNS.

(1) Obtain the Domain you want to join, your IP and the IP of DNS
Servers. By Hand for Paranoiac ones, by DHCP, DHCP6 or RA.
(2) Feth dig -t txt _dns_over_tls_.domainname.tld. In case of Third
Level or Deeper Domains use first _dns_over_tls_.xth_level. ...
.2nd_level.tld then shorten step by step until you reach
_dns_over_tls_.2nd_level.tld or you found some text.
(3) Use the Text a List of the Names of the secure dns server, obtain
there IP's of the TLS DNS from the initial DNS configuration. All of
them must be DNS-SEC validated - including existence - nonexistence of
the records - by the client (not server this may forged)!!
(4) Write the IP -> Name pairs to the hostfile i.e. implement a off dns
name translation.
(5) Change the resolve configure to named DNS server with TLS Protocol
... witch also means forget to primary DNS configuration.
(6) Now you can make a secure regularity strait forward connect to the
TLS DNS with regular Certificate Validation.


If you are connected to the right domain, you are connected to the right
DNS-Server with no interception option in relation to the domain you
have joined.
The Client Software (Browser/Desktop Operating System) must give a
feedback to what domain the system is connected to clarify that point,
because this may be redirected to somewhere else by interception of the
DHCP and its derivates.
Browsers must offer some option to change the Domain Of Trust ... to
avoid ISP based government monitoring in obscure country's ;)

Hans Carlos Hofmann



-- 
*BCC:* datenkr...@nsa.gov, datenkr...@gchq.gov.uk, 
Als kostenfreie wirksame Verschlüsselungssoftware empfehe ich OpenPGP
 + Enigmail 


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DPRIVE Phase 2 Milestones and Requirements for WG Virtual Meeting 2018-12-10

[Loganaden Velvindron]

On Sat, Dec 8, 2018 at 9:47 PM Benno Overeinder  wrote:
>
> [Same email, different header to assure email did not disappear in
> original thread.  Sorry for spamming.]
>
> Hi all,
>
> On 28/11/2018 15:19, Brian Haberman wrote:
> >  The main focus of this interim will be item #3. Benno & Alex have
> > volunteered to collect all the issues and requirements that have been
> > raised during our mailing list discussions into a draft that will be the
> > basis of that discussion.
>
> As Brian mentioned in previous emails, Alex, Willem and I have collected
> issues that have been discussed on the mailing list and added some
> issues ourselves (during a session last week).
>
> We decided to use the DPRIVE wiki instead of writing a draft though.
> The main goal of the first draft is to collect and organise the various
> perspectives and requirements on DPRIVE phase 2.  We are happy to write
> a draft after the DPRIVE WG Virtual Meeting.
>
> For now, you are invited to review and add content to the wiki page:
> https://trac.ietf.org/trac/dprive/wiki/DPriveStage2
>
> Best regards,
>
> Alex, Willem and Benno
>

May I suggest adding this one:

draft-ietf-dprive-bcp-op




>
> --
> Benno J. Overeinder
> NLnet Labs
> https://www.nlnetlabs.nl/
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DPRIVE Phase 2 Milestones and Requirements for WG Virtual Meeting 2018-12-10

[Erik Nygren]

On Sat, Dec 8, 2018 at 12:46 PM Benno Overeinder  wrote:

>
> For now, you are invited to review and add content to the wiki page:
> https://trac.ietf.org/trac/dprive/wiki/DPriveStage2
>


I unfortunately won't be able to attend today due to a prior conflict.
After some discussing with some colleagues, a few topics that came up which
I added to the wiki for discussion:




*On signaling provisioning information: in operator considerations:   * New
record type for NSoverTLS?  Use SRV?  (Being able to use different servers
for serving up DNS-over-{TCP,UDP} vs DNS-over-TLS responses may be
valuable.* Signal secure transport details (DNS-over-TLS,
DNS-over-QUIC, EncryptedSNI, etc), perhaps in an extensible manner?
Minimize RTTs and reduce need for trials.*

In particular, it would be highly desirable to not be required to couple
the authoritative servers used for Secure-Transport responses to those used
for conventional responses, plus there would ideally be a way to signal the
transport (and transport parameters such as any future encrypted SNI) to be
used to reduce the need for RTTs and opportunistic trials with fallback.
Using SRV (or a more extensible SRV-like-format that could also include
transport parameters) might be natural here and would also allow a way to
signal when multiple authorities share a secure DNS authoritative service
(to better allow for connection reuse).


*On implementation details:*


*  * Reuse connection state  * Minimize server-side state  (eg, with
session tickets)  * Cache reuse vs. downgrade?  Does the cache need to be
partitioned?  When can an in-cache answer retrieved via cleartext be served
to a recursor via TLS?*

On the first two, efficiently minimizing state (both client and server, but
especially on the server) as well as reusing connections to minimize RTTs
is likely to be critical to achieve performance, scale, and attack
resilience.  I suspect all of the protocol options come down to
bootstrapping from set of asymmetric cryptographic primitives for clients
and servers that share no history and constructing a shared symmetric key
with which to encrypt-and-integrity-protect requests and responses.  With
additional variations on this to minimize asymmetric crypto operations, to
minimize RTTs, and to securely memoize authenticated state (eg, with TLS
session tickets).

On the last of these, there's a trade-off on to what degree the cache can
be shared between cleartext and encrypted requests and responses.  In the
HTTPS world, the general best-practice is to either not share cache or to
only upgrade (eg, allow cleartext to use requests fetched over TLS, but not
vice-versa).  Even this is not always operationally viable.  Given the
presence of DNSSEC, some relaxation of this to allow more cache sharing may
be possible.  (There may be side-channel attacks exposed, but these may be
possible regardless as long as any caching is performed.)

 Erik
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

[Tim Wicinski]

I see dialing info of

1-650-479-3208 Call-in toll number (US/Canada)
Access code:  640 873 331

I am digging up alternative numbers.

On Mon, Dec 10, 2018 at 9:18 AM Henderson, Karl  wrote:

> Is there a dial-in number for the dprive webex meeting today?
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy