=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)

RFC Errata System | 14 Aug 17:51 2014

[Editorial Errata Reported] RFC6944 (4083)

The following errata report has been submitted 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

--------------------------------------
Type: Editorial
Reported by: Bodo Moeller <bmoeller <at> acm.org>

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
merely optional.)

Instructions:
-------------
(Continue reading)

Frederico A C Neves | 23 Jul 23:34 2014
Picon

OPENPGPKEY RRTYPE review - Comments period ends Aug 6th

Dear Colleagues,

Bellow is a completed template requesting a new RRTYPE assignment
under the procedures of RFC6895.

This message starts a 2 weeks period for an expert review of the DNS
RRTYPE parameter allocation for OPENPGPKEY specified at:

http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2

If you have comments regarding this request please post them here
before Aug 6th 21:00 UTC.

Best Regards,
Frederico Neves

--begin 6895 template TLSA--
 A. Submission Date: 23-07-2014

 B.1 Submission Type:  [x] New RRTYPE  [ ] Modification to RRTYPE
 B.2 Kind of RR:  [x] Data RR  [ ] Meta-RR

 C. Contact Information for submitter (will be publicly posted):
    Name: Paul Wouters         Email Address: pwouters <at> redhat.com
    International telephone number: +1-647-896-3464
    Other contact handles: paul <at> nohats.ca

 D. Motivation for the new RRTYPE application.

    Publishing RFC-4880 OpenPGP formatted keys in DNS with DNSSEC
(Continue reading)

Olafur Gudmundsson | 15 Jul 23:18 2014

Re: [Editorial Errata Reported] RFC3757 (4018)


Brian, (guess you are AD responsible) 
IMHO this errata is correct and should be approved. 

	Olafur 

On Jun 20, 2014, at 2:56 AM, RFC Errata System <rfc-editor <at> rfc-editor.org> wrote:

> The following errata report has been submitted for RFC3757,
> "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3757&eid=4018
> 
> --------------------------------------
> Type: Editorial
> Reported by: St├ęphane Bortzmeyer <bortzmeyer <at> nic.fr>
> 
> Section: 1
> 
> Original Text
> -------------
> A SEP key either used to generate a
>   DS RR or is distributed to resolvers that use the key as the root of
>   a trusted subtree
> 
> Corrected Text
> --------------
> A SEP key _is_ either used to generate a
(Continue reading)

RFC Errata System | 20 Jun 09:05 2014

[Errata Held for Document Update] RFC3757 (4018)

The following errata report has been held for document update 
for RFC3757, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag". 

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

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: St?phane Bortzmeyer <bortzmeyer <at> nic.fr>
Date Reported: 2014-06-19
Held by: Ted Lemon (IESG)

Section: 1

Original Text
-------------
A SEP key either used to generate a
   DS RR or is distributed to resolvers that use the key as the root of
   a trusted subtree

Corrected Text
--------------
A SEP key _is_ either used to generate a
   DS RR or is distributed to resolvers that use the key as the root of
   a trusted subtree

Notes
(Continue reading)

Paul Vixie | 31 May 08:08 2014

icann rssac caucus

Greetings,

If you are interested in participating at ICANN's Root Server System Advisory Committee
(https://www.icann.org/resources/pages/charter-2013-07-14-en) as a Caucus member, please kindly
read the relevant information and Caucus document published at
https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en and submit your statement of
interest to rssac-membership <at> icann.org 

The RSSAC executive is working on publishing the final version "Procedures documents" and at the moment is
establishing  the Caucus and with a few work items ready to be discussed by the Caucus.

If you would like to volunteer please kindly indicate those intentions known by sending an email to rssac-membership <at> icann.org.

Kind Regards,

Kaveh Ranjbar, RSSAC Membership Committee Chair
Tripti Sinha, RSSAC Membership Committee Member
Paul Vixie, RSSAC Membership Committee Member

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

S Moonesamy | 1 May 17:20 2014

Fwd: Last Call: <draft-moonesamy-sshfp-ed25519-01.txt> (Using ED25519 in SSHFP Resource Records) to Informational RFC

Hello,

I am forwarding this Last Call announcement (see below) as it is 
something to do with DNS.

Regards,
S. Moonesamy

>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'Using ED25519 in SSHFP Resource Records'
>   <draft-moonesamy-sshfp-ed25519-01.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-05-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
>
>
>    The Ed25519 signature algorithm has been implemented in OpenSSH.
>    This document updates the IANA "SSHFP RR Types for public key
>    algorithms" registry by adding an algorithm number for Ed25519.
>
>
>
>The file can be obtained via
>http://datatracker.ietf.org/doc/draft-moonesamy-sshfp-ed25519/
(Continue reading)

Mark Andrews | 19 Mar 17:19 2014

BADVERS returned for unknown EDNS option


	Is the vendor of the nameservers cpb.gov are runnning willing
	to standup and issue a recall notice for the version they
	are running.  version.bind returns "3.2.2" 

	When presented a unknown EDNS option they return BADVERS
	rather then ignoring the option.  The EDNS RFCs (both the
	original and the replacement) are explict about what
	conditions set BADVERS.

	This sort of mis-behaviour make it very difficult to deploy
	new EDNS options.

	Mark

; <<>> DiG 9.10.0b2 <<>>  <at> sauthns1.qwest.net cpb.gov +nsid
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39491
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cpb.gov.			IN	A

;; Query time: 12 msec
;; SERVER: 2001:428::7#53(2001:428::7)
(Continue reading)

Hosnieh Rafiee | 4 Mar 15:29 2014

Please submit your questions about cga-tsig to mailing list

Just a two remarks or highlights about the presentation:
-  Data confidentiality can also be used in the resolver scenario the same
way as zone transfer scenario that is explained during presentation as an
example scenario. 
- The proof of concept or implementation in NL Net labs is only available
for resolver scenario as I also explained in my previous messages to the
mailing list everytime I discussed about the implementation
But the early versions of this draft was implemented for powerDNS (as a
proof of concepts)
- This draft does not only works in cases where SeND is available but as
also Erik mentioned, it works when you generate your CGA address and assign
it like a static address.

Thank you,
Best,
Hosnieh 

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

Hosnieh Rafiee | 28 Feb 15:55 2014

We want to have fruitful discussions - please review

Dear All,

Since we have a timeslot to present
http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig in DNSOP. I ask you
please review it so that the discussion would be fruitful and we can receive
good comments to improve it and to move ahead.  This draft is not a new one
as many of you already know or heard about it, it was first presented in
IETF 85 and recently in IETF 88 in Int-area. The reason was because it was
more related to DNSEXT and at that time it was going to shut down. It had
several volunteer reviewers and it received some good comments. However, we
would like to receive more comments in case we missed anything that needs to
be addressed or we missed to clarify any section in the draft that needs
more clarifications. Since now the DNS confidentiality is also an important
topic and this proposal could handle it for IPv6 and during data transfer, I
also included a section and explained the required changes to the original
proposal.

Here again I briefly explain the purpose of this document for those who do
not know about it or who do not know the exact purpose of it:

This proposal is for the cases where DNS uses IPv6 and there is a need to
use a security mechanism for DNS authentication or provide the data
confidentiality for the DNS data during transferring data over the network.
It is possible to use this proposal in different DNS scenarios such as DNS
update, updating FQDN and PTR, or DNS resolving. In this case it is enough
that the verifier node only knows the IP address of the DNS server or
resolver. For DNS update, this IP address can be set manually for the first
time in the DNS configuration file and for other times, the CGA-TSIG can
handle the changes with the proposed specifications. For DNS resolver, it
receives this IP address securely via the option in the router advertisement
(Continue reading)


Gmane