Re: [dns-privacy] a comment on draft-krecicki-dprive-dnsenc-01
W dniu 02.11.2015 o 00:40, 神明達哉 pisze:
> I have one quick comment/question on draft-krecicki-dprive-dnsenc-01.
>
> In Section 3.1 it states:
>
>APPLICABLE NS NAME a of NSes that use this
>key. This allows for different NSes for
>a zone to use different keysets (eg. when
>the secondary is operated by different
>entity than primary). This field might
>contain wildcard symbol '*' at any place
>(including as a part of a single label -
>eg. 'ns*.foo*bar.example.com'), which
>matches zero or more characters and can
>cross label boundaries ('ns*.example.com'
>matches 'ns.example.com',
>'ns1.example.com' and
>'ns1.foobar.example.com'), single '*'
>means any.
>
> So the semantics of '*' is different from that of RFC1035/4592. Is
> this deviation really necessary? It's not immediately clear to me
> from the draft about the definite need for it, and I suspect this can
> be easily a nightmare for implementers. Also, calling this a
> might also not be very appropriate as it handles '*' in
> a different way.
The goals to achieve are:
1. have the ability to specify different keys for different nameservers
for one domain (as one might be provided by domain owner, other by SNS,
and both can use different keys)
2. having 1. in mind, limit the amount of NSK records needed for domain
to absolute minimum.
For example:
example.com IN NS ns1.example.com
example.com IN NS ns2.example.com
example.com IN NS alt-ns1.example.com
example.com IN NS ns1.snsprovider.com
example.com IN NS ns2.snsprovider.com
example.com IN NSK ns*.example com ...
example.com IN NSK ns*.snsprovider.com ...
Two different keys for two providers, and no key for alt-ns1.example.com
(because it does not provide DNSENC).
It is a topic for discussion (you're not the first one to mention it),
and I'm open to other solutions - I just want to make sure that the
chosen solution achieves the goals I've mentioned before.
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
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
W dniu 22.10.2015 o 15:04, Wiley, Glen pisze: > On 10/22/15, 8:18 AM, "Witold Kręcicki" <w...@isc.org> 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
W dniu 20.10.2015 o 10:19, Stephane Bortzmeyer pisze: > On Mon, Oct 19, 2015 at 09:58:41PM +0200, > Witold Kręcicki <w...@isc.org> 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
[dns-privacy] An alternative for DNS privacy
Hi all, After the discussions that took place on dprive meeting in Prague I felt that we're losing the point of DNS - it being the very lightweight protocol. I know that DTLS and TLS are great and proven protocols but those were meant to protect streams and communications a few orders larger where few additional ping-pongs and few hundred bytes of overhead are negligible. In DNS the few hundred bytes is an order of magnitude, and a few additional ping-pongs are a nightmare for someone with RT times of 300ms (not everyone lives in the US you know :>). I also felt that there is a pressure to migrate to TCP completely - which I believe is throwing a baby with the bathwater. That's why I've came up with something completely different. I've started writing this draft in Prague in July, but from completely wrong side - describing wire formats etc. instead of general ideas. So for now I've erased everything that's on the technical side and left only the very outline of the protocol. So, without further ado, here https://www.ietf.org/id/draft-krecicki-dnsenc-00.txt is the early, buggy, almost non-technical, and full of typos version of Stateless DNS Encryption (DNSENC) draft, for your consideration. Witold Krecicki ISC ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
