Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review

[Sara Dickinson]

>>> The pros: simpler than TLS and may be less traffic (any actual sizing,
>>> either in theory or by measurements? TLS has some overhead but DNSENC
>>> requires sending a key with each request. You give the numbers for
>>> DNSENC but not for TLS).
>> 
>> For a single message DNSoDTLS has a theoretical 13 byte overhead for
>> header + cipher/authentication overhead.
> 
> I count 16 bytes overhead for DTLS:  12 bytes for header, and typically 4 
> bytes for authentication tag.  But Stephane was asking about TLS (not DTLS), 
> and TLS doesn't have the 48-bit sequence number or 16-bit epoch (they are 
> maintained internally with TLS, and not transmitted on the wire), so TLS 
> should have 8 bytes overhead (if my math is right) and of course the TCP 
> header is bigger than the UDP header.  (Sorry, in a plane at the moment.)  
> All those numbers are steady-state, after (D)TLS handshake.


Hi All, 

Sorry - I missed this discussion initially. Talking about post handshake then… 
(I verified by capturing DNS-over-TLS off the wire (getdns <-> Unbound) - pcap 
file attached)
- the TCP header is at least 12 bytes bigger than UDP (more depending on 
options)
- the TLS record layer header is 5 bytes ( ContentType type; ProtocolVersion 
version; uint16 length;). 

So not a huge difference overall between DTLS and TLS here, I think.

-  Also using TLS 1.2 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for a small 
selection of ‘normal’ size queries (40-100 bytes) the encrypted payload is at 
most ~26 bytes larger than the unencrypted UDP payload (the difference includes 
the 2 byte Message Length field required for TLS/TCP). 

Sara. 



TLS_vs_UDP_size.pcap
Description: Binary data



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

Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review

[Stephane Bortzmeyer]

On Thu, Oct 22, 2015 at 02:18:42PM +0200,
 Witold Kręcicki  wrote 
 a message of 67 lines which said:

> Because that would require an unencrypted query to the zone NS to get
> the zone key

...

> This approach is mostly for recursive servers - and those as mostly
> managed by owners of the net block. An alternative for recursive servers
> is a hardcoded key in eg. /etc/resolv.conf.

I think that this rationale should go into the draft, in a separate
section, to limit repeated discussions (I already reported privately
the problem with {in-addr,ip6}.arpa...)

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

Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review

[Wiley, Glen]

This is an interesting idea, a few comments:

1. In section 2 it sounds as though you are suggesting that the new RR
containing the encryption key needs to be published in the parent zone.
Why not publish this as a RR at the apex of the zone with whose name
servers you want to encrypt?  The advantage to putting encryption keys in
the zone rather than the parent is that you create less work for
registrars who already seem to really struggle with providing a way to
publish DS/DNSKEY records.

2. The fallback to reverse DNS takes an optimistic view of reverse DNS.
Most hosting providers will not grant permission to customers to publish
in the reverse DNS for net blocks that they manage.

3. I like the idea of leaving the DNS packets mostly in tact - I think
this is more likely to survive transit through middle boxes that might
want to do some simple packet inspection to see whether the DNS is being
used for something other than DNS.  This is in fact the same idea that
Wouter Wijngaards and I proposed in the confidential DNS draft.

4. Section 3.1.1 specifies an applicable NS name.  It is not clear to me
why I would want this field.  Wouldn't it be more consistent with the
current mode of operation of the DNS to determine this using the DNS
hierarchy?  A zone operator would publish an NSK at the owner name for the
NS to which it applies.

5. I would recommend choosing a different name for the new RR as Name
Server Key could create confusion to folks learning about the various key
records in the DNS.  What about something like NSENCK - Name Server
Encryption Key?

6. Failure modes could use some attention.  It would be useful to
distinguish cases where a decrypt fails due to a wrong key versus a format
error, unsupported encryption scheme , etc.




-- 
Glen Wiley

Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A




On 10/19/15, 3:58 PM, "Witold Kręcicki"  wrote:

>Hi all,
>
>I've just posted an updated version of Stateless DNS Encryption draft,
>it still has holes and unaswered questions but it's now almost
>implementable.
>
>I'd really appreciate if the group could read and comment on it.
>
>Witold Kręcicki
>
>
>A new version of I-D, draft-krecicki-dprive-dnsenc-01.txt
>has been successfully submitted by Witold Krecicki and posted to the
>IETF repository.
>
>Name:  draft-krecicki-dprive-dnsenc
>Revision:  01
>Title: Stateless DNS Encryption
>Document date: 2015-10-19
>Group: Individual Submission
>Pages: 15
>URL:
>https://www.ietf.org/internet-drafts/draft-krecicki-dprive-dnsenc-01.txt
>Status:
>https://datatracker.ietf.org/doc/draft-krecicki-dprive-dnsenc/
>Htmlized:   
>https://tools.ietf.org/html/draft-krecicki-dprive-dnsenc-01
>Diff:
>https://www.ietf.org/rfcdiff?url2=draft-krecicki-dprive-dnsenc-01
>
>Abstract:
>   The DNS is the last common Internet protocol that has no encryption
>   scheme and therefore provides no privacy to the users.  This document
>   proposes an extensible mechanism providing encryption of DNS queries
>   and responses with method for secure retrieval and verification of
>   validity of encryption keys.  It is independent of the underlying
>   transport protocol.
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>
>
>
>___
>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] draft-krecicki-dprive-dnsenc-01 - call for review

[Wiley, Glen]

On 10/22/15, 9:15 AM, "Witold Kręcicki"  wrote:


>W dniu 22.10.2015 o 15:04, Wiley, Glen pisze:
>> On 10/22/15, 8:18 AM, "Witold Kręcicki"  wrote:
>> 
>> 
>>> W dniu 22.10.2015 o 13:44, Wiley, Glen pisze:
 This is an interesting idea, a few comments:

 1. In section 2 it sounds as though you are suggesting that the new RR
 containing the encryption key needs to be published in the parent
zone.
 Why not publish this as a RR at the apex of the zone with whose name
 servers you want to encrypt?  The advantage to putting encryption keys
 in
 the zone rather than the parent is that you create less work for
 registrars who already seem to really struggle with providing a way to
 publish DS/DNSKEY records.
>>> Because that would require an unencrypted query to the zone NS to get
>>> the zone key - and that would be a huge leak of information (as an
>>> attacker would know that a victim is looking for something in
>>> wikileaks.org, probably www.wikileaks.org). I know that putting the
>>>keys
>>> at the delegation point is going to be much harder to implement in real
>>> world but as an alternative is compromising privacy - it's the only
>>> proper way.
>> 
>> This is a great opportunity to not let the best become the enemy of
>>better.
>> The parent could be a preferred location rather than the only location.
>That is an option, but I'm afraid that if this becomes an option then no
>operator will allow putting NSK at delegation point...

It is often the case that when a technology attempts to impose the best
option rather than provide a bridge or progressive path to adoption
that it may simply not be adopted.

I would like to see your idea refined and tuned up so that it can move
forward and I think it would be a shame to create this obstacle to
adoption.

>
>> Passive monitoring would see a query go to the NS IP of the zone in
>> question
>> anyway so you don't really loose much privacy by publishing the key at
>>the
>> NS owner label.  You are still able to encrypt queries that include a
>> delegation.
>In most cases NSes are shared (I always wanted to use wikileaks.org, but
>it's a bad example here ;) ) so information that a specific IP is
>queried is only revealing that a victim might be querying one of the
>domains that are hosted on a specific NS (and attacker usually doesn't
>have the full list).
>
>
>Witold Krecicki

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

Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review

[Witold Kręcicki]

W dniu 22.10.2015 o 13:44, Wiley, Glen pisze:
> This is an interesting idea, a few comments:
> 
> 1. In section 2 it sounds as though you are suggesting that the new RR
> containing the encryption key needs to be published in the parent zone.
> Why not publish this as a RR at the apex of the zone with whose name
> servers you want to encrypt?  The advantage to putting encryption keys in
> the zone rather than the parent is that you create less work for
> registrars who already seem to really struggle with providing a way to
> publish DS/DNSKEY records.
Because that would require an unencrypted query to the zone NS to get
the zone key - and that would be a huge leak of information (as an
attacker would know that a victim is looking for something in
wikileaks.org, probably www.wikileaks.org). I know that putting the keys
at the delegation point is going to be much harder to implement in real
world but as an alternative is compromising privacy - it's the only
proper way.

> 2. The fallback to reverse DNS takes an optimistic view of reverse DNS.
> Most hosting providers will not grant permission to customers to publish
> in the reverse DNS for net blocks that they manage.
This approach is mostly for recursive servers - and those as mostly
managed by owners of the net block. An alternative for recursive servers
is a hardcoded key in eg. /etc/resolv.conf.
The question if this should be a fallback for auth servers is open for
discussion, I've already heard voices that it's not a good idea and I'm
not insisting on it.

> 4. Section 3.1.1 specifies an applicable NS name.  It is not clear to me
> why I would want this field.  Wouldn't it be more consistent with the
> current mode of operation of the DNS to determine this using the DNS
> hierarchy?  A zone operator would publish an NSK at the owner name for the
> NS to which it applies.
My goal was to allow two different keysets for a domain in case its
nameservers are operated by different entities, so that domain owner
doesn't have to share his keys with SNS (and so that a SNS can use small
amount of keys, and not different key for every domain it hosts), eg:

example.com IN NS ns1.provider1.com
example.com IN NS ns2.provider1.com
example.com IN NS ns.provider2.com
example.com IN NSK ... *.provider1.com ...
example.com IN NSK ... *.provider2.com ...


> 5. I would recommend choosing a different name for the new RR as Name
> Server Key could create confusion to folks learning about the various key
> records in the DNS.  What about something like NSENCK - Name Server
> Encryption Key?
I'm open to propositions, I had an opinion that DNSENC is to similiar to
DNSSEC so I've changed the name to DNSCRYPT just to get a message that
it is already commonly used so I'm back to DNSENC.

> 6. Failure modes could use some attention.  It would be useful to
> distinguish cases where a decrypt fails due to a wrong key versus a format
> error, unsupported encryption scheme , etc.
Agree, that's an early version of draft and I was focused mostly on
describing the general idea, not getting into details.


Witold Kręcicki

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

Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review

[Wiley, Glen]

On 10/22/15, 8:18 AM, "Witold Kręcicki"  wrote:


>W dniu 22.10.2015 o 13:44, Wiley, Glen pisze:
>> This is an interesting idea, a few comments:
>> 
>> 1. In section 2 it sounds as though you are suggesting that the new RR
>> containing the encryption key needs to be published in the parent zone.
>> Why not publish this as a RR at the apex of the zone with whose name
>> servers you want to encrypt?  The advantage to putting encryption keys
>>in
>> the zone rather than the parent is that you create less work for
>> registrars who already seem to really struggle with providing a way to
>> publish DS/DNSKEY records.
>Because that would require an unencrypted query to the zone NS to get
>the zone key - and that would be a huge leak of information (as an
>attacker would know that a victim is looking for something in
>wikileaks.org, probably www.wikileaks.org). I know that putting the keys
>at the delegation point is going to be much harder to implement in real
>world but as an alternative is compromising privacy - it's the only
>proper way.

This is a great opportunity to not let the best become the enemy of better.
The parent could be a preferred location rather than the only location.
Passive monitoring would see a query go to the NS IP of the zone in
question
anyway so you don't really loose much privacy by publishing the key at the
NS owner label.  You are still able to encrypt queries that include a
delegation.

I disagree that it would offer a "huge" leak of information, in fact I
would
argue that you really don't disclose anything that would not already be
disclosed since you have to talk to the NS IP.

>
>> 2. The fallback to reverse DNS takes an optimistic view of reverse DNS.
>> Most hosting providers will not grant permission to customers to publish
>> in the reverse DNS for net blocks that they manage.
>This approach is mostly for recursive servers - and those as mostly
>managed by owners of the net block. An alternative for recursive servers
>is a hardcoded key in eg. /etc/resolv.conf.
>The question if this should be a fallback for auth servers is open for
>discussion, I've already heard voices that it's not a good idea and I'm
>not insisting on it.
>
>> 4. Section 3.1.1 specifies an applicable NS name.  It is not clear to me
>> why I would want this field.  Wouldn't it be more consistent with the
>> current mode of operation of the DNS to determine this using the DNS
>> hierarchy?  A zone operator would publish an NSK at the owner name for
>>the
>> NS to which it applies.
>My goal was to allow two different keysets for a domain in case its
>nameservers are operated by different entities, so that domain owner
>doesn't have to share his keys with SNS (and so that a SNS can use small
>amount of keys, and not different key for every domain it hosts), eg:
>
>example.com IN NS ns1.provider1.com
>example.com IN NS ns2.provider1.com
>example.com IN NS ns.provider2.com
>example.com IN NSK ... *.provider1.com ...
>example.com IN NSK ... *.provider2.com ...
>
>
>> 5. I would recommend choosing a different name for the new RR as Name
>> Server Key could create confusion to folks learning about the various
>>key
>> records in the DNS.  What about something like NSENCK - Name Server
>> Encryption Key?
>I'm open to propositions, I had an opinion that DNSENC is to similiar to
>DNSSEC so I've changed the name to DNSCRYPT just to get a message that
>it is already commonly used so I'm back to DNSENC.
>
>> 6. Failure modes could use some attention.  It would be useful to
>> distinguish cases where a decrypt fails due to a wrong key versus a
>>format
>> error, unsupported encryption scheme , etc.
>Agree, that's an early version of draft and I was focused mostly on
>describing the general idea, not getting into details.
>
>
>Witold Kręcicki

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

Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review

[Witold Kręcicki]

W dniu 22.10.2015 o 15:04, Wiley, Glen pisze:
> On 10/22/15, 8:18 AM, "Witold Kręcicki"  wrote:
> 
> 
>> W dniu 22.10.2015 o 13:44, Wiley, Glen pisze:
>>> This is an interesting idea, a few comments:
>>>
>>> 1. In section 2 it sounds as though you are suggesting that the new RR
>>> containing the encryption key needs to be published in the parent zone.
>>> Why not publish this as a RR at the apex of the zone with whose name
>>> servers you want to encrypt?  The advantage to putting encryption keys
>>> in
>>> the zone rather than the parent is that you create less work for
>>> registrars who already seem to really struggle with providing a way to
>>> publish DS/DNSKEY records.
>> Because that would require an unencrypted query to the zone NS to get
>> the zone key - and that would be a huge leak of information (as an
>> attacker would know that a victim is looking for something in
>> wikileaks.org, probably www.wikileaks.org). I know that putting the keys
>> at the delegation point is going to be much harder to implement in real
>> world but as an alternative is compromising privacy - it's the only
>> proper way.
> 
> This is a great opportunity to not let the best become the enemy of better.
> The parent could be a preferred location rather than the only location.
That is an option, but I'm afraid that if this becomes an option then no
operator will allow putting NSK at delegation point...

> Passive monitoring would see a query go to the NS IP of the zone in
> question
> anyway so you don't really loose much privacy by publishing the key at the
> NS owner label.  You are still able to encrypt queries that include a
> delegation.
In most cases NSes are shared (I always wanted to use wikileaks.org, but
it's a bad example here ;) ) so information that a specific IP is
queried is only revealing that a victim might be querying one of the
domains that are hosted on a specific NS (and attacker usually doesn't
have the full list).


Witold Krecicki

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

Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review

[Witold Kręcicki]

W dniu 20.10.2015 o 10:19, Stephane Bortzmeyer pisze:
> On Mon, Oct 19, 2015 at 09:58:41PM +0200,
>  Witold Kręcicki  wrote 
>  a message of 28 lines which said:
> 
>> I've just posted an updated version of Stateless DNS Encryption
>> draft, it still has holes and unaswered questions but it's now
>> almost implementable.
> 
> Interesting, I think.
> 
> The pros: simpler than TLS and may be less traffic (any actual sizing,
> either in theory or by measurements? TLS has some overhead but DNSENC
> requires sending a key with each request. You give the numbers for
> DNSENC but not for TLS).

For a single message DNSoDTLS has a theoretical 13 byte overhead for
header + cipher/authentication overhead. Unfortunately I haven't seen a
complete analysis of a real-world DNSoDTLS overhead, and I'm not that
familiar with TLS to make any assumptions.

DNSENC elimitates the need for first handshake, as the key for the
server is given with the NS/DS records from the parent zone - this
causes overhead on message size: for one key and ECC encryption - ~30
bytes for NSK RR + 300 bytes for RRSIG RR, but no additional round-trips.

Someone with deeper knowledge of DNSoDTLS would have to give us actual
numbers here.

> The cons: DNS-over-TLS can be implemented as a simple transport,
> irrelevant for the upper layers of the DNS server and client. DNSENC
> requires the server to memorize the key while the request is pending
> so you need to change the purely-DNS part of the server.
True, but if you really don't want to touch the inner DNS part of your
server then you may implement the encapsulation/decapsulation of packets
in DNS as a 'transport' - if this 'transport' detects that a packet is a
DNSENC packet (and there is a clear way to do it) it decapsulates it,
decrypts it, and sends it to the lower layer.

> The neutrals: it is not TLS. I let you decided if it's a pro or a
> con. It requires DNSSEC.
Any system that is supposed to provide privacy of communication requires
a method for peer identification/validation. TLS uses PKI/CA system, I
believe that since we have a system for it built into DNS it's obvious
that we should use it to validate our peer and not use an external
mechanism.

> Technical issues:
> 
> "NSK RRsets MUST NOT appear at a zone's apex." And then an example
> with NSK at the apex...
I wasn't clear enough on that - that example shows records at the
delegation point, NSK records are served the same way as DS records in
DNSSEC.


Witold Krecicki

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

Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review

[Stephane Bortzmeyer]

On Tue, Oct 20, 2015 at 11:13:37AM +0200,
 Witold Kręcicki  wrote 
 a message of 57 lines which said:

> I wasn't clear enough on that - that example shows records at the
> delegation point, NSK records are served the same way as DS records in
> DNSSEC.

This is indeed very ambiguous in the draft. "At the delegation point"
means nothing. Above or below?

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

Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review

[Dan Wing]

On 20-Oct-2015 02:13 am, Witold Kręcicki  wrote:
> 
> W dniu 20.10.2015 o 10:19, Stephane Bortzmeyer pisze:
>> On Mon, Oct 19, 2015 at 09:58:41PM +0200,
>> Witold Kręcicki  wrote 
>> a message of 28 lines which said:
>> 
>>> I've just posted an updated version of Stateless DNS Encryption
>>> draft, it still has holes and unaswered questions but it's now
>>> almost implementable.
>> 
>> Interesting, I think.
>> 
>> The pros: simpler than TLS and may be less traffic (any actual sizing,
>> either in theory or by measurements? TLS has some overhead but DNSENC
>> requires sending a key with each request. You give the numbers for
>> DNSENC but not for TLS).
> 
> For a single message DNSoDTLS has a theoretical 13 byte overhead for
> header + cipher/authentication overhead.

I count 16 bytes overhead for DTLS:  12 bytes for header, and typically 4 bytes 
for authentication tag.  But Stephane was asking about TLS (not DTLS), and TLS 
doesn't have the 48-bit sequence number or 16-bit epoch (they are maintained 
internally with TLS, and not transmitted on the wire), so TLS should have 8 
bytes overhead (if my math is right) and of course the TCP header is bigger 
than the UDP header.  (Sorry, in a plane at the moment.)  All those numbers are 
steady-state, after (D)TLS handshake.

-d


> Unfortunately I haven't seen a
> complete analysis of a real-world DNSoDTLS overhead, and I'm not that
> familiar with TLS to make any assumptions.
> 
> DNSENC elimitates the need for first handshake, as the key for the
> server is given with the NS/DS records from the parent zone - this
> causes overhead on message size: for one key and ECC encryption - ~30
> bytes for NSK RR + 300 bytes for RRSIG RR, but no additional round-trips.
> 
> Someone with deeper knowledge of DNSoDTLS would have to give us actual
> numbers here.
> 
>> The cons: DNS-over-TLS can be implemented as a simple transport,
>> irrelevant for the upper layers of the DNS server and client. DNSENC
>> requires the server to memorize the key while the request is pending
>> so you need to change the purely-DNS part of the server.
> True, but if you really don't want to touch the inner DNS part of your
> server then you may implement the encapsulation/decapsulation of packets
> in DNS as a 'transport' - if this 'transport' detects that a packet is a
> DNSENC packet (and there is a clear way to do it) it decapsulates it,
> decrypts it, and sends it to the lower layer.
> 
>> The neutrals: it is not TLS. I let you decided if it's a pro or a
>> con. It requires DNSSEC.
> Any system that is supposed to provide privacy of communication requires
> a method for peer identification/validation. TLS uses PKI/CA system, I
> believe that since we have a system for it built into DNS it's obvious
> that we should use it to validate our peer and not use an external
> mechanism.
> 
>> Technical issues:
>> 
>> "NSK RRsets MUST NOT appear at a zone's apex." And then an example
>> with NSK at the apex...
> I wasn't clear enough on that - that example shows records at the
> delegation point, NSK records are served the same way as DS records in
> DNSSEC.
> 
> 
> Witold Krecicki
> 
> ___
> 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