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)

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)


Gmane