bert hubert | 20 Dec 13:58 2014
Picon

Empty AA=0 AD=1 answers to AAAA queries: your thoughts pls

Hi everybody,

I have a question if I am right in concluding something is a protocol
violation, and if we should reward it by papering it over or (finally)
concluding that enough is enough.

A few weeks ago we posted this
http://mailman.powerdns.com/pipermail/pdns-users/2014-December/011004.html
about Microsoft Azure nameservers sending empty answers (AD=1 no less) to
AAAA queries. Microsoft has indicated they'll get to addressing this early
2015, by the way (thanks Mehmet).

However, we're now seeing more and more of this, for example from the most
popular news site in the Netherlands nu.nl: 

$ dig +trace -t aaaa nu-nl.gslb.sanomaservices.nl.

Which ends on:

$ dig -t aaaa nu-nl.gslb.sanomaservices.nl.  <at> 62.69.175.251
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58444
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;nu-nl.gslb.sanomaservices.nl.	IN	AAAA

Note that this is the same pattern as Microsoft Azure. But this empty AA=0
answer leads PowerDNS to:

(Continue reading)

Paul Hoffman | 14 Dec 23:30 2014

Middleboxes and EDNS(0)

Greetings again. Section 6.1.1.1 of RFC 6891 says:

   OPT RRs MUST NOT be cached,
   forwarded, or stored in or loaded from master files.

Section 6.2.6 says:

   Middleboxes that simply forward requests to a recursive resolver MUST
   NOT modify and MUST NOT delete the OPT record contents in either
   direction.

If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT RR on a query coming in my left side, what do
I send that OPT RR out the right side? Do I follow the first or the second quote?

--Paul Hoffman
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

KSK Rollover SOI | 12 Dec 20:08 2014
Picon

Solicitation for Statements of Interest regarding Root KSK Rollover

ICANN, as the IANA functions operator, in cooperation with Verisign as the
Root Zone Maintainer and the National Telecommunications Information
Administration (NTIA) as the Root Zone Administrator, together known as
the Root Zone Management (RZM) partners, seek to develop a plan for
rolling the DNS root zone key-signing key (KSK). The KSK is used to sign
the
root zone zone-signing key (ZSK), which in turn is used to DNSSEC-sign the
Internet’s root zone. The Root Zone Partners are soliciting five to seven
volunteers from the community to participate in a Design Team to develop
the Root Zone KSK Rollover Plan (“The Plan”). These volunteers along with
the RZM partners will form the Design Team to develop The Plan.

Individuals interested in volunteering approximately 5 hours per week for
the Design Team should consult the announcement:

https://www.icann.org/en/system/files/files/ksk-soi-11dec14-en.pdf


and submit their Statement of Interest to ksk-rollover-soi <at> icann.org no
later than January 16, 2015.

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
RFC Errata System | 2 Dec 17:36 2014

[Editorial Errata Reported] RFC6840 (4191)

The following errata report has been submitted for RFC6840,
"Clarifications and Implementation Notes for DNS Security (DNSSEC)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6840&eid=4191

--------------------------------------
Type: Editorial
Reported by: Edward Lewis <edward.lewis <at> icann.org>

Section: 5.11

Original Text
-------------
...

A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  The
      zone MUST also be signed with each algorithm (though not each key)
      present in the DNSKEY RRset.  

Corrected Text
--------------
A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  Each
      authoritative RRset in the zone MUST be signed with each 
      algorithm (though not each key) present in the DNSKEY RRset.  

Notes
(Continue reading)

Hosnieh Rafiee | 24 Oct 10:33 2014

Review request - new version of CGA-TSIG draft - draft-rafiee-intarea-cga-tsig-11

Folks,

I have revised CGA-TSIG document . You can find the following summary in the introduction as well. Just to
motivate more people to review the draft, the following is the description of the mechanism.

Thanks Joel Halpern for his comments and reviews which helped to improve its readability and content.

I would love to receive your inputs on this version so that I know whether now it is easily readable and
understandable. :-)

Thanks,
Best,
Hosnieh

< https://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-11 >
------------------------------
Overview of CGA-TSIG/e Mechanisms
The purpose of CGA-TSIG and CGA-TSIGe is to minimize the human intervention required to accomplish a
shared secret or key exchange (automation as much as possible), secure authentication, with the end
result of providing data confidentiality to prevent DNS spoofing. Minimizing the amount of human
intervention reduces the vulnerability to attacks introduced by human errors. As explained earlier,
CGA-TSIG/e can be used to assist DNSSEC server in last mile of Internet. CGA-TSIG/e supports both IPv4 and
IPv6 scenarios. In the IPv6 scenario, the algorithms use Cryptographically Generated Addresses (CGA)
[RFC3972] or Secure Simple Addressing Scheme for IPv6 Autoconfiguration (SSAS) [1]. Both CGA and SSAS
provide the nodes with the necessary proof of IP address ownership by providing a cryptograp
 hic binding between a host's public key and its IP address without the need for the introduction of
infrastructure. For example, in DNS stub resolver to resolver scenario, CGA-TSIG provides this sec
 ure authentication by receiving the IP address of a DNS resolver via an option from a secure Router
Advertisement (RA) or from DHCPv6 server that is protected via SAVI approaches [savi-dhcp]. When it
(client) wants to resolve a query, it sends a DNS query message by only setting algorithm type to
(Continue reading)

Matthijs Mekking | 14 Oct 10:49 2014

Re: How are people implementing hold-down in RFC 5011?

On 13-10-14 17:58, Michael StJohns wrote:
> At 04:59 AM 10/13/2014, Matthijs Mekking wrote:
>> Hi,
>>
>> On 09-10-14 18:46, Michael StJohns wrote:
>>> At 07:57 PM 10/7/2014, Paul Hoffman wrote:
>>>> Thanks for the clarifications. I still have a bunch of
>>>> questions, and I really do wonder if implementers agree with
>>>> your interpretations.
>>
>>
>>>>>
>>>>>> 2: Attacker's zone: B signs (A Br C) (Here, "Br" means "B
>>>>>> with the REVOKE bit set".)
>>>>>
>>>>> 2 is actually B and C sign (Br C).
>>>>
>>>> When the RFC says "and signing it with B", it might be clearer
>>>> if it says "and signing it with B and C". It is far from clear
>>>> which messages from the attacker are for public consumption
>>>> (which would be seen by the zone owner) and which are meant for
>>>> restricted relying parties.
>>>
>>> That's not actually a matter of concern for the zone owner. The
>>> incantation to revoke a key K is "K signs (Kr)".  As I noted
>>> elsewhere, you can't actually have multiple disjoint DNSKEY
>>> RRSets for a given name, so that you end up doing a union of all
>>> the keys to be signed into a single DNSKEY RRSet and you provide
>>> signatures by all signers over all the keys.
>>
(Continue reading)

Matthijs Mekking | 13 Oct 10:59 2014

Re: How are people implementing hold-down in RFC 5011?

Hi,

On 09-10-14 18:46, Michael StJohns wrote:
> At 07:57 PM 10/7/2014, Paul Hoffman wrote:
>> Thanks for the clarifications. I still have a bunch of questions, and
>> I really do wonder if implementers agree with your interpretations.

I have implemented this (http://nlnetlabs.nl/projects/autotrust/) and I 
agree with Michael's interpretations (even if it was after an hour 
asking questions at some past IETF).

I am trying to clarify below, although most stuff seems already 
straighted out.

>> On Oct 7, 2014, at 1:03 PM, Michael StJohns <mstjohns <at> comcast.net> wrote:
>>
>> > At 01:13 PM 10/7/2014, Paul Hoffman wrote:
>> >> Greetings. In reading RFC 5011 more carefully, I am finding that
>> some of the wording is confusing (possibly just to me). I have a few
>> questions for people who have implemented it in systems, but also want
>> to hear from the greater DNS community.
>> >>
>> >> Section 2.2 says:
>> >>
>> >>  Assume two trust point keys A and B.  Assume that B has been
>> >>  compromised.  An attacker could generate and add a new trust anchor
>> >>  key C (by adding C to the DNSKEY RRSet and signing it with B), and
>> >>  then invalidate the compromised key.  This would result in both the
>> >>  attacker and owner being able to sign data in the zone and have it
>> >>  accepted as valid by resolvers.
(Continue reading)

Michael StJohns | 7 Oct 22:03 2014
Picon
Picon

Re: How are people implementing hold-down in RFC 5011?

At 01:13 PM 10/7/2014, Paul Hoffman wrote:
>Greetings. In reading RFC 5011 more carefully, I am finding that some of the wording is confusing
(possibly just to me). I have a few questions for people who have implemented it in systems, but also want to
hear from the greater DNS community.
>
>Section 2.2 says:
>
>   Assume two trust point keys A and B.  Assume that B has been
>   compromised.  An attacker could generate and add a new trust anchor
>   key C (by adding C to the DNSKEY RRSet and signing it with B), and
>   then invalidate the compromised key.  This would result in both the
>   attacker and owner being able to sign data in the zone and have it
>   accepted as valid by resolvers.
>
>I am assuming that "invalidate" means "revoke". 

Yes.  

>Pictorially, I think this means the following progression in time:
>   1: Owner's zone: A signs (A B)
>   

1.5 Attacker's zone: B signs (B C)
(This has to happen for the Add Hold down time until C becomes a valid trust anchor.  In general this is going to
be B and C sign (B, C) for the hold down period).

>2: Attacker's zone: B signs (A Br C)
>(Here, "Br" means "B with the REVOKE bit set".)

2 is actually B and C sign (Br C).
(Continue reading)

Joe Abley | 16 Sep 17:09 2014
Picon

Root Zone KSK Rollover Operations Workshop (save the date)

Hi all,

ICANN will facilitate an open, technical workshop to discuss operational plans for a future root zone KSK
rollover, during the upcoming ICANN 51 meeting to be held in Los Angeles in October 2014.

The workshop is intended for participants who have a technical, operational perspective and is an
opportunity to explore potential options, operational considerations, and other aspects of rolling
the root zone KSK.

The workshop will be held on Thursday October 16, 2014 at the ICANN meeting venue in Los Angeles. This will be
an open event, and remote participation will be available.

More details including a tentative agenda, will be made available soon. If you are able to participate,
please join the ksk-rollover mailing list at
<https://mm.icann.org/mailman/listinfo/ksk-rollover> which will be used to coordinate this
workshop, and to function as a venue for technical discussion as this work proceeds in the future.

Regards,

Joe & Roy & Jakob & Duane & Dan
ad-hoc workshop coordinators
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

=JeffH | 25 Aug 20:39 2014

fyi: NSEC5: Provably Preventing DNSSEC Zone,Enumeration

perhaps of interest, this talk will be given tomorrow Tue 26-Aug-2014 in 
Gates Hall, Stanford Univ (link to paper near bottom)...

Subject: Tuesday, August 26 -- Moni Naor: Primary-Secondary-Resolvers
  Membership Proof Systems and their Applications to DNSSEC
From: Joe Zimmerman <jzim <at> cs.stanford.edu>
Date: Mon, 25 Aug 2014 09:55:27 -0700
To: security-seminar <at> lists.stanford.edu

   Primary-Secondary-Resolvers Membership Proof Systems and
                 their Applications to DNSSEC

                          Moni Naor

                   Tuesday, August 26, 2014
                        Talk at 4:15pm
                          Gates 463A

Abstract:

We consider Primary-Secondary-Resolver Membership Proof Systems (PSR for
short)
that enable a secondary to convince a resolver whether or not a given a
element
is in a set defined by the primary without revealing more information about
the set.  The main motivation is studying the problem of zone enumeration
in DNSSEC. DNSSEC is designed to prevent network attackers from tampering
with domain name system (DNS) messages. The cryptographic machinery used
in DNSSEC, however, also creates a new vulnerability - Zone Enumeration,
where an adversary launches a small number of online DNSSEC queries and then
(Continue reading)

RFC Errata System | 14 Aug 18:20 2014

[Errata Verified] RFC6944 (4083)

The following errata report has been verified for RFC6944,
"Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6944&eid=4083

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Bodo Moeller <bmoeller <at> acm.org>
Date Reported: 2014-08-14
Verified by: Ted Lemon (IESG)

Section: 5.1

Original Text
-------------
N/A

Corrected Text
--------------
[RFC6605]  P. Hoffman, P., and Wijngaards, W.C.A., "Elliptic Curve
    Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, 2012.

Notes
-----
This Normative Reference is simply missing from the document, even though the algorithms from RFC 6605 are
"Recommended to Implement" in RFC 6944.  (Cf. how RFC 5933 is referenced, even though its algorithms are
(Continue reading)


Gmane