[DNSOP] NSEC3PARAM iteration count update

[Viktor Dukhovni]

[ I'm also posting a separate copy to dns-operati...@dns-oarc.net ]

In light of the observations in:

  
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-05#section-2.3.1

I thought it would be useful to take another look at current practice.
To that end, I gathered responses to NSEC3PARAM queries from the 5.147
million DNSSEC-signed domains I'm tracking as part of the ongoing DANE
SMTP survey.  This covers all the DNSSEC-signed domains from zones where
I have a full field (.com, .net, .org, .se, .nu and a bunch of the more
recent gTLDs for which CZDS provides access).  So the coverage is primarily
incomplete just for various ccTLDs (.de, .nl, .ru, .uk, ...) where I've
managed to collect around around 60% of the domains from other sources.

The overall sample characteristics are:

  5126588successful NSEC3PARAM lookups
20820failed lookups (ServFail or timeout)
  3598119NSEC3PARAM RRsets with 1 record
6NSEC3PARAM RRsets with 2 records (two salts)
  1523390NODATA (presumably domain uses NSEC rather than NSEC3)

The below distribution of iteration counts (rounded up to the nearest
multiple of 10 for values between 20 and 2500) is largely concentrated
at 1, 5, 8, 10, 20, 40 and 100.  Values <= 150 should work for all key
sizes with a correctly configured resolver, so the vast majority of
domains don't have any trouble with secure denial of existence:

#domains iterations
 --
115  0
1501953  1
   3513  2
 92  3
 10  4
  58907  5
 21  6
322  7
 941391  8
 17  9
 194324 10
  5 11
229 12
 49 13
  2 14
599 15
   8778 16
  4 17
  1 19
 317662 20
167 30
  37138 40
   3834 50
  3 60
 13 70
 28 80
  4 90
 528157100
 32130
  1140
307150
  3200
  1240
 49250
  1260
261300
 70330
  3400
  1430
 24500
 24   1600
 12   2500
  1   4096
  1  16384
  2  65535

Of the 453 domains with iteration counts above 150 only 4 have counts
in excess of 2500, which are unsupported by many resolvers with the
default RFC5155 iteration count limits.  The remaining "interesting"
domains are the 449 with iterations in the interval [151,2500].

Of these:

 * 258 have 512-bit P256 (algorithm 13) keys and 300 iterations.  This
   exceeds the RFC5155 iteration limits and breaks secure DoE for many
   resolvers.  All these domains are hosted at "ns1.desec.io".

 * 1 has both a 512-bit P256 key and a 1024-bit RSA key and 250 iterations
   in excess of the limits for either size.

 * 1 has a 1024-bit RSA key and 300 iterations.

 * 7 have 768-bit P384 (algorithm 14) keys and 500 iterations.

 * 2 have P384 keys and 200 iterations.

So, in all, 273 domains are misconfigured with counter-productively high
iteration counts.  So the problem described in the draft exists in the wild,
but is, for the moment at least, quite infrequent.  The vast majority of
domains use sensibly low counts (with 1 being the most popular value, though
frankly 0 would have done just as well, but is perhaps not as well understood).

With a bit of luck, better documentation and tools that warn users to
not exceed 150 (regardless of key size) will keep the problem largely
in check.

I still think there's a lesson here for protocol design, quoting the draft:

  A simple design would have constrained the iteration count only by
  the bit width of the iteration count field (perhaps 12 bits for up
  4096 iterations), with all representable values supported by both
  signers and resolvers.

At this time, I would say that just 7bits for the iteration count
would have been plenty.  Few users want to hide their content against
off-line dictionary attacks so badly, that they are willing to pay the
cost of more than 100 iterations, and most are happy with 1, 10 or 20.

So an update to RFC5155 that sets a flat iteration limit of 127 and
reserves the leading 9 bits of the iteration count would IMHO be a
good idea.

In any case, protocols with integral fields where only a subset of the
values is supported, and the supported set depends on other parameters
is a design feature that should be avoided.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain

[Niall O'Reilly]

On 19 Dec 2017, at 10:08, Martin Hoffmann wrote:

> Except that "child zone" should probably be "subordinate zones" or
> something similar to also include (great)*grandchildren.

If "ancestor" were acceptable, then the natural counterpart would be
"descendant".

0,02

Niall O'Reilly


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

[Niall O'Reilly]

On 19 Dec 2017, at 7:09, Richard Gibson wrote:

> 1\. "Domain name" is defined as «an ordered list of one or more labels… 
> identifying a portion along one edge of a directed acyclic graph» (presumably 
> starting at the root).

I'm not sure why one would presume to start there.  As I read the following 
fragment
of RFC 1034, the list of labels explicitly starts at the node of interest and 
is read
towards the root.

The domain name of a node is the list of the labels on the path from the
node to the root of the tree.  By convention, the labels that compose a
domain name are printed or read left to right, from the most specific
(lowest, farthest from the root) to the least specific (highest, closest
to the root).

Best regards,
Niall O'Reilly

signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] kskroll-sentinel responses

[Ray Bellis]

On 21/12/2017 15:36, Robert Story wrote:
> I reread the draft today, and noticed that two things aren't specified.
> The first is the contents of the A/ RRSET returned, and the second
> is the TTL for the records.
> 
> Maybe the A/ record values could be used to return additional
> details? For example, whether or not the key is part of static
> configuration, or learned via 5011.

I had also wondered about this.

A browser-based system for triggering these queries can't do so without
also then attempting a download of some resource via whatever IP address
is returned.

(in other words, you can't make a browser "just" do a DNS lookup, the
DNS lookup is a side effect of attempting to access a URL)

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

[Paul Vixie]

you guys are killing me with this thread.

>


http://queue.acm.org/detail.cfm?id=1242499

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

[Richard Gibson]

On 12/21/2017 07:31 AM, Niall O'Reilly wrote:


On 19 Dec 2017, at 7:09, Richard Gibson wrote:

1. "Domain name" is defined as «an ordered list of one or more
labels… identifying a portion along one edge of a directed acyclic
graph» (presumably starting at the root).

I'm not sure why one would presume to start there. As I read the 
following fragment
of RFC 1034, the list of labels explicitly starts at the node of 
interest and is read

towards the root.

|The domain name of a node is the list of the labels on the path from 
the node to the root of the tree. By convention, the labels that 
compose a domain name are printed or read left to right, from the most 
specific (lowest, farthest from the root) to the least specific 
(highest, closest to the root). |
Two reasons why I presume edge direction to be away from the root: 
first, because it's consistent with the rest of the document in its 
current form (for example, the very next sentence after my quoted text 
describes how a fully qualified domain name "begins at the common root 
of the graph"), and second, because parent-to-child directionality is 
inherent to the DNS for delegations.


RFC 1034 seems to contemplate an undirected graph, so can happily use 
towards-the-root for domain names and away-from-the-root for 
delegations. But I don't think 7719bis has that luxury, because "domain 
name" should remain valid even in a "naming system" without a single 
common root.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Digest, Vol 132, Issue 53

[Stephane Bortzmeyer]

On Tue, Dec 19, 2017 at 02:58:57PM +0500,
 Tariq Saraj  wrote 
 a message of 1158 lines which said:

> using a firewall based on domain names can be simply bypassed by
> accessing websites through IP address.

No, no, this is absolutely not what I was talking about. Instead, I
referred to:

> Second, there are some firewalls such as Cisco and Kaspersky that handle
> this situation when someone configure a firewall rule based on domain name,
> it automatically resolves the IPv4 and IPv6 addresses for that domain and
> update the firewall rules so that it cannot be bypassed through accessing a
> server through IP based.

Exactly.

> But, these are highly expensive firewalls and normally not
> affordable for every organization.

Any 50 US $ OpenWRT router can do it (iptables accepts domain names).

% sudo iptables -A OUTPUT -d www.example.com -j DROP

% sudo iptables -n -v -L OUTPUT
Chain OUTPUT (policy ACCEPT 184 packets, 22306 bytes)
 pkts bytes target prot opt in out source   destination 

0 0 DROP   all  --  *  *   0.0.0.0/0
93.184.216.34   

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] kskroll-sentinel responses

[Robert Story]

I reread the draft today, and noticed that two things aren't specified.
The first is the contents of the A/ RRSET returned, and the second
is the TTL for the records.

Maybe the A/ record values could be used to return additional
details? For example, whether or not the key is part of static
configuration, or learned via 5011.

-- 
Robert Story 
USC Information Sciences Institute 


pgpwVyffI5pQ4.pgp
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Please review in terminology-bis: Global DNS and Private DNS

[Stephane Bortzmeyer]

On Mon, Dec 18, 2017 at 09:29:58AM -0500,
 Ted Lemon  wrote 
 a message of 176 lines which said:

> Now that I've attempted to compose this reply, it seems to me, and
> perhaps was obvious to other readers more quickly because they're at
> 20kft and not 1ft on this, that your real point is that the document
> should not privilege ICANN over OpenNIC.   If so, you should say
> that directly

Please do not tell me what is my real point. I know my real point
(even if it is not always expressed clearly).

When it comes to non-technical issue, the draft says, when defining
TLD, that "the division [between ccTLD and gTLD] is a matter of
policy, and beyond the scope of this document." This is the right
approach. The fact that the root is managed by ICANN or OpenNIC or
whatever is beyond the scope of this document.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

[Niall O'Reilly]

On 18 Dec 2017, at 14:11, Stephane Bortzmeyer wrote:

>> IN-BAILIWICK
>
> ...
>
>> Also, on behalf on non-native speakers, a short explanation of the
>> origin of the term would perhaps be nice.
>
> I like the Wiktionary (and it can be copied freely into a RFC):

I like this suggestion.

As a native speaker of English (admittedly conditioned by the period
in which I acquired the language, by those who gave me instruction,
and by the literature to which I've been exposed), I'm wondering
whether it wouldn't be better to have "Bailiwick" as the head-word
in this repertoire of terminology, rather than having separate
entries for "In-Bailiwick" and "Out-of-Bailiwick".

In the English I learned, a hyphenated adjective such as "in-bailiwick"
can be used only as an attributive adjective (before the noun), and not
as a predicate or complement (after the verb).

Just as a five-year-old child is five years old (and neither five-years
old nor five years-old), so an in-bailiwick name is within the relevant
bailiwick, or is inside this bailiwick, or belongs to the bailiwick.
For me, all of these alternative expressions, none of which uses a
hyphen, are implicitly valid elements of the terminology in consequence
of including "In-Bailiwick".

I feel that having entries for "In-Bailiwick" and "Out-of-Bailiwick"
is unnecessarily prescriptive, and that a single entry for "Bailiwick"
would give sufficient clarity without unduly constraining the style of
future authors.

I hope this helps.

Best wishes for Christmas and the New Year, and apologies for being
late for Hannukah.

Niall O'Reilly


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

[Richard Gibson]

On 12/21/2017 02:17 PM, Niall O'Reilly wrote:

On 21 Dec 2017, at 16:06, Richard Gibson wrote:

first, because it's consistent with the rest of the document in its current form (for 
example, the very next sentence after my quoted text describes how a fully qualified 
domain name "begins at the common root of the graph"),

But, as you pointed out in an earlier message, this depends on which portions 
of the rest
of the document you pick.  Under "Domain name" and "Composition of names" the 
order described
is away from the root, while under "presentation format", "wire format", and 
"display format",
the opposite is the case.
The text is consistent in identifying "domain name" with "a list of 
labels ordered from parent to child", it's just confusing that wire 
format and presentation format are each /also/ "a list of [the same] 
labels" but ordered in reverse.

RFC 1034 seems to contemplate an undirected graph, so can happily use towards-the-root for domain 
names and away-from-the-root for delegations. But I don't think 7719bis has that luxury, because 
"domain name" should remain valid even in a "naming system" without a single 
common root.

I'ld be surprised, because of what I understood of how the development of 7719
was approached, to learn that 7719bis can be permitted to revise a foundational
document such as 1034.  I may be mistaken in this.
RFC 1034 defines domain name as "the list of the labels on the path… to 
the root of the tree" and references a /convention/ that labels "are 
printed or read… from the most specific (lowest, farthest from the root) 
to the least specific". I still think the original text applies to an 
undirected graph, so describing it in terms of a directed graph 
(specifically with edges from parents to children, as it is in the 
protocol) constitutes a clarification rather than a revision. That said, 
though, nailing down the ordering of domain name labels to /oppose/ the 
direction of such edges is most in accord with 1034 and seems like it 
would eliminate the most confusion in 7719bis.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

[Niall O'Reilly]

On 21 Dec 2017, at 16:06, Richard Gibson wrote:

> Two reasons why I presume edge direction to be away from the root:

> first, because it's consistent with the rest of the document in its current 
> form (for example, the very next sentence after my quoted text describes how 
> a fully qualified domain name "begins at the common root of the graph"),

But, as you pointed out in an earlier message, this depends on which portions 
of the rest
of the document you pick.  Under "Domain name" and "Composition of names" the 
order described
is away from the root, while under "presentation format", "wire format", and 
"display format",
the opposite is the case.

> and second, because parent-to-child directionality is inherent to the DNS for 
> delegations.

That's an enticing analogy.  I'm not sure whether it's compelling.

> RFC 1034 seems to contemplate an undirected graph, so can happily use 
> towards-the-root for domain names and away-from-the-root for delegations. But 
> I don't think 7719bis has that luxury, because "domain name" should remain 
> valid even in a "naming system" without a single common root.

I'ld be surprised, because of what I understood of how the development of 7719
was approached, to learn that 7719bis can be permitted to revise a foundational
document such as 1034.  I may be mistaken in this.


Best regards,

Niall O'Reilly


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Digest, Vol 132, Issue 53

[Tariq Saraj]

hi Bortzmeyer,
there are still some issues with

>Any 50 US $ OpenWRT router can do it (iptables accepts domain names).

>% sudo iptables -A OUTPUT -d www.example.com -j DROP

>% sudo iptables -n -v -L OUTPUT
>Chain OUTPUT (policy ACCEPT 184 packets, 22306 bytes)
> pkts bytes target prot opt in out source
 destination
 >   0 0 DROP   all  --  *  *   0.0.0.0/0
93.184.216.34

First these rules are still bypassed by the client. Below I have two
commands ping and the dig. with the ping command the IP address is
different, while when the dig command is passed for the domain facebook.com
the answer is a different IP address.
.
@ubuntu:~$ ping facebook.com
PING facebook.com (157.240.1.35) 56(84) bytes of data.
64 bytes from edge-star-mini-shv-01-lht6.facebook.com (157.240.1.35):
icmp_seq=1 ttl=50 time=148 ms
64 bytes from edge-star-mini-shv-01-lht6.facebook.com (157.240.1.35):
icmp_seq=2 ttl=50 time=149 ms
64 bytes from edge-star-mini-shv-01-lht6.facebook.com (157.240.1.35):
icmp_seq=3 ttl=50 time=148 ms
^C
--- facebook.com ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 10010ms
rtt min/avg/max/mdev = 148.903/148.997/149.096/0.372 ms

[The dig command]
@ubuntu:~$ dig facebook.com A
; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> facebook.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62852
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;facebook.com.INA
;; ANSWER SECTION:
facebook.com.212INA185.60.216.35
;; Query time: 41 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Dec 21 11:28:46 PST 2017
;; MSG SIZE  rcvd: 57

Also, even if all this is keep aside for the time being, what about all
those IP addresses or IPv6 addresses that are configured on any of the
network security component such as firewall in my usecase? One still need
to resolve the corresponding IP address if rules are based on IPv6 address
or IPv6 address if rules are based on IP address.



On Thu, Dec 21, 2017 at 9:29 PM, Stephane Bortzmeyer 
wrote:

> On Tue, Dec 19, 2017 at 02:58:57PM +0500,
>  Tariq Saraj  wrote
>  a message of 1158 lines which said:
>
> > using a firewall based on domain names can be simply bypassed by
> > accessing websites through IP address.
>
> No, no, this is absolutely not what I was talking about. Instead, I
> referred to:
>
> > Second, there are some firewalls such as Cisco and Kaspersky that handle
> > this situation when someone configure a firewall rule based on domain
> name,
> > it automatically resolves the IPv4 and IPv6 addresses for that domain and
> > update the firewall rules so that it cannot be bypassed through
> accessing a
> > server through IP based.
>
> Exactly.
>
> > But, these are highly expensive firewalls and normally not
> > affordable for every organization.
>
> Any 50 US $ OpenWRT router can do it (iptables accepts domain names).
>
> % sudo iptables -A OUTPUT -d www.example.com -j DROP
>
> % sudo iptables -n -v -L OUTPUT
> Chain OUTPUT (policy ACCEPT 184 packets, 22306 bytes)
>  pkts bytes target prot opt in out source
>  destination
> 0 0 DROP   all  --  *  *   0.0.0.0/0
> 93.184.216.34
>



-- 
Regards
Tariq Saraj
Riphah Institute of Systems Engineering, Islamabad
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop