Mark Andrews | 25 Jul 00:02 2014

Changing NSEC3 salts regularly is useless


I just sent the following to bind-users.  We need to kill the myth
that changing NSEC3 salt provides any real benefit.

"Actually it is useless to change the salt regularly.  Changing the
salt provides no real benefit against discovering the names in a
zone which is the reason people were saying to change the salt.

The attacker uses cached NSEC3 records.  When it gets a cache miss
it asks the servers for the zone, puts the answer in the cache and
continues.  When the salt changes it just maintains multiple nsec3
chains eventually discarding the old nsec3 chain eventually.  I
would wait until the new NSEC3 chain has as many cached records as
the old NSEC3 chain.  Changing the salt slows things up miniminally
for a very short period of time after the change.  Additionally
once you have some names you ask for those names for a non-exisisting
type to quickly pull in part of the new NSEC3 chain you know exists.

The only reason to change the salt is if you have a collision of
the hashed names.  This will be a very very very rare event."

Mark
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka <at> isc.org

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
(Continue reading)

David Conrad | 22 Jul 16:22 2014

Masataka Ohta's 2004 draft...

Since I mentioned it and some folks said "where is it?":

http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03

Regards,
-drc

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Suzanne Woolf | 22 Jul 13:12 2014
Picon

scribes, notetakers

As usual…..desperately needed. Any volunteers in advance will be welcome.

thanks,
da chairs
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Stephane Bortzmeyer | 21 Jul 03:10 2014
Picon

AD bit with DNS64

The resolver on the IETF NAT64 network at the Royal York hotel in
Toronto sets the AD bit when the zone is signed, even when we ask it
about a AAAA record... which does not exist in the zone.

I checked the RFC on DNS64, RFC 6147 (specially section 3). The IETF
resolver is "security-aware" and "validating". RFC 6147 says "the
resolver should also set the Authentic Data (AD) bit on the response"
For me, it seems obvious for me that it is true only if the data has
been actually validated, which is not possible for the synthetized
AAAA record. Do I read the RFC correctly?

Unsigned domain, AD is absent, which is expected:

% dig AAAA twitter.com

; <<>> DiG 9.9.5-3-Ubuntu <<>> AAAA twitter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30741
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;twitter.com.		IN AAAA

;; ANSWER SECTION:
twitter.com.		30 IN AAAA 64:ff9b::c710:9c46
twitter.com.		30 IN AAAA 64:ff9b::c710:9c66
twitter.com.		30 IN AAAA 64:ff9b::c710:9cc6
(Continue reading)

Tim Wicinski | 20 Jul 22:39 2014
Picon

Final Agenda Uploaded (probably)


All

I've uploaded the final agenda for Tuesday Morning.  If you have not 
sent us slides you should make it an effort to do so before we shame you 
into doing so.

And thank you to the few who have sent us your slides. We'll start 
uploading them tonight.

See you Tuesday Morning Bright and Early!

tim

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Andrew Sullivan | 18 Jul 20:05 2014

draft-ietf-dnsop-dnssec-key-timing

Dear colleagues,

I've had a look at draft-ietf-dnsop-dnssec-key-timing-04.  I have no
objections to the alterations to the document, and I say again what
I've been saying for, I think, two years now (maybe more): giving
useful advice, even if not perfect, on this topic will be more helpful
than producting perfect advice.  It ought to be easy to update the
document if we see that some things need improvement.  Many people are
deeply confused about key rollovers.  If we get the document out and
people start complaining about what's wrong with it, at least we'll
have evidence about what to improve.

Please publish it.

Best regards,

A

--

-- 
Andrew Sullivan
ajs <at> anvilwalrusden.com

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

The IESG | 15 Jul 16:34 2014
Picon

Last Call: <draft-ietf-dnsop-rfc6304bis-03.txt> (AS112 Nameserver Operations) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'AS112 Nameserver Operations'
  <draft-ietf-dnsop-rfc6304bis-03.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2014-07-29. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   Many sites connected to the Internet make use of IPv4 addresses that
   are not globally-unique.  Examples are the addresses designated in
   RFC 1918 for private use within individual sites.

   Devices in such environments may occasionally originate Domain Name
   System (DNS) queries (so-called "reverse lookups") corresponding to
   those private-use addresses.  Since the addresses concerned have only
   local significance, it is good practice for site administrators to
   ensure that such queries are answered locally.  However, it is not
   uncommon for such queries to follow the normal delegation path in the
   public DNS instead of being answered within the site.

   It is not possible for public DNS servers to give useful answers to
   such queries.  In addition, due to the wide deployment of private-use
   addresses and the continuing growth of the Internet, the volume of
   such queries is large and growing.  The AS112 project aims to provide
(Continue reading)

The IESG | 15 Jul 16:34 2014
Picon

Last Call: <draft-ietf-dnsop-as112-dname-04.txt> (AS112 Redirection using DNAME) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'AS112 Redirection using DNAME'
  <draft-ietf-dnsop-as112-dname-04.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2014-07-29. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   Many sites connected to the Internet make use of IPv4 addresses that
   are not globally unique.  Examples are the addresses designated in
   RFC 1918 for private use within individual sites.

   Devices in such environments may occasionally originate Domain Name
   System (DNS) queries (so-called "reverse lookups") corresponding to
   those private-use addresses.  Since the addresses concerned have only
   local significance, it is good practice for site administrators to
   ensure that such queries are answered locally.  However, it is not
   uncommon for such queries to follow the normal delegation path in the
   public DNS instead of being answered within the site.

   It is not possible for public DNS servers to give useful answers to
   such queries.  In addition, due to the wide deployment of private-use
   addresses and the continuing growth of the Internet, the volume of
   such queries is large and growing.  The AS112 project aims to provide
(Continue reading)

John Heidemann | 15 Jul 06:46 2014
Picon

updated tech report about DNS-over-TCP and DNS-over-TLS


In Feb. 2014, Zi Hu posted about a study about DNS performance over TCP
and TLS.  The context was a proposal to allow DNS to use TLS over TCP,
described in
http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-01

We got a lot of input we got from the community (particularly those at
OARC in Warsaw).  We've updated our technical report about DNS-over-TCP
and -TLS based on new work stemming from this feedback.

The new tech report is at
http://www.isi.edu/publications/trpublic/files/tr-693.pdf

This tech report (ISI-TR-2014-693) is a major revision of the prior
technical report (ISI-TR-2014-688). Since that work we have improved our
understanding of the availability of TCP fast open and TLS resumption,
and we have tightened our estimates on memory based on external reports
(section 5.2). This additional information has allowed us to conduct
additional experiments, improve our modeling, and provide a more
accurate view of what is possible today; our estimates of latency and
memory consumption are both lower than in our prior technical report as
a result. We have also added additional information about packet size
limitations (Figure 2), experiments evaluating DNSCrypt/DNSCurve
(section 6.1), analysis of DTLS, and covered a broader range of RTTs in
our experiments. We believe these additions strengthen our central
claims: that connectionless DNS causes multiple problems and that T-DNS
addresses those problems with modest increase in latency and memory
suitable for current hardware.

Discussion with the community and feedback from reviewers raised a
(Continue reading)

Paul Vixie | 5 Jul 05:04 2014

various approaches to dns channel secrecy

i've now seen a number of proposals reaction to "the snowden
disclosures", seeking channel encryption for dns transactions. i have
some thoughts on the matter which are not in response to any specific
proposal, but rather, to the problem statement and the context of any
solution.

first, dns data itself is public -- the data is there for anybody to
query for it, if you know what to query for. only the question,
questioner, and time can be kept secret. answers are only worth keeping
secret because they identify the question, questioner, and time.

second, dns transactions are not secret to protocol agents. whether stub
resolver, full resolver, forwarder, proxy, or authority server -- the
full identity of the question must be knowable to the agent in order to
properly process that question. if the agent does logging, then the
question, questioner, and time will be stored and potentially shared or
analyzed.

by implication, then, the remainder of possible problem statement
material is "hide question from on-wire surveillance", there being no
way to hide the questioner or the time. to further narrow this, the
prospective on-wire surveillance has to be from third parties who are
not also operators of on-path dns protocol agents, because any second
party could be using on-wire surveillance as part of their logging
solution, and by (2) above there is no way to hide from them. so we're
left with "hide question from on-wire surveillance by third parties."

this is extremely narrow but i can envision activists and dissidents who
rightly fear for their safety based on this narrowly defined threat, so
i'm ready to agree that there should be some method in DNS of providing
(Continue reading)

Matthijs Mekking | 4 Jul 15:12 2014
Picon

Fwd: New Version Notification for draft-mekking-dnsop-kasp-00.txt

Hi wg,

I see more and more road maps that include implementing Key and Signing
Policies, so Jerry and I thought it would be a good idea to standardize
the policy model and the behavior of its elements.

Ideally, policies can be used between multiple different software
products, and if you do, you expect the same behavior.

Here is an initial draft for this, we would appreciate your feedback.

Best regards,
  Matthijs

-------- Original Message --------
Subject: New Version Notification for draft-mekking-dnsop-kasp-00.txt
Date: Fri, 04 Jul 2014 01:25:01 -0700
From: internet-drafts <at> ietf.org
To: W. (Matthijs) Mekking <matthijs <at> nlnetlabs.nl>, "Jerry Lundstroem"
<jerry.lundstrom <at> iis.se>, Jerry Lundstroem <jerry.lundstrom <at> iis.se>,
"Matthijs Mekking" <matthijs <at> nlnetlabs.nl>

A new version of I-D, draft-mekking-dnsop-kasp-00.txt
has been successfully submitted by W. (Matthijs) Mekking and posted to the
IETF repository.

Name:		draft-mekking-dnsop-kasp
Revision:	00
Title:		DNSSEC Key and Signing Policies
Document date:	2014-07-04
(Continue reading)


Gmane