Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Paul Hoffman]

On 10 Mar 2017, at 12:38, Dave Lawrence wrote:


Paul Hoffman writes:

Is there a community of zone admins who want this so much that they
won't start signing until it exists?


I think that question is a little extreme and need not go that far to
determine whether something is worthwhile to pursue.


Fully agree. That's why I followed it with:

Short of that, is there a community of zone admins who are using 
NSEC/NSEC3 white lies who find this to be a significant improvement?



My interest in NSEC5 is largely around the significant performance
gains it has over NSEC3-WhiteLies, with double the throughout reported
in "Can NSEC5 be Practical for DNSSEC Deployments"
.


I found the paper intriguing, but possibly confusing. My reading is that 
it compares an optimized server using NSEC5 against an unoptimized 
server using NSEC3 White Lies. If my reading is correct, a better 
comparison would be if they added a reasonably-efficient NSEC3 White 
Lies feature to their server for comparison. If my reading is wrong, 
then great, 2x for negative answers seems like a good speedup.



We have a large number of zones that are not yet signed, and a
non-trivial part of that is because of performance.  NSEC5 has an
impact in addressing that issue.

Professionally, I'm somewhat less concerned about the enumeration
issue because the at least some of the zones where I want to use it
have highly structured names anyway.  Enumerating them is trivial even
in plain old non-DNSSEC DNS.  In the other, less-structured zones that
we already sign we use classic NSEC3 and are considering going to
NSEC3-WL on behalf of customers that do care about it. We have online
ksks for other features required of these zones.

On a personal level I appreciate that this proposal enhances ksk
security while addressing the enumeration problem.


Thanks, this makes me hopeful if the 2x performance number holds up.

--Paul Hoffman

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Dave Lawrence]

Paul Hoffman writes:
> Is there a community of zone admins who want this so much that they 
> won't start signing until it exists?

I think that question is a little extreme and need not go that far to
determine whether something is worthwhile to pursue.

My interest in NSEC5 is largely around the significant performance
gains it has over NSEC3-WhiteLies, with double the throughout reported
in "Can NSEC5 be Practical for DNSSEC Deployments"
.

We have a large number of zones that are not yet signed, and a
non-trivial part of that is because of performance.  NSEC5 has an
impact in addressing that issue.

Professionally, I'm somewhat less concerned about the enumeration
issue because the at least some of the zones where I want to use it
have highly structured names anyway.  Enumerating them is trivial even
in plain old non-DNSSEC DNS.  In the other, less-structured zones that
we already sign we use classic NSEC3 and are considering going to
NSEC3-WL on behalf of customers that do care about it. We have online
ksks for other features required of these zones.

On a personal level I appreciate that this proposal enhances ksk
security while addressing the enumeration problem.

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Jim Reid]

> On 10 Mar 2017, at 18:33, Phillip Hallam-Baker  wrote:
> 
> Shhh. don't confuse with facts.

Presumably those are Trump-flavoured alternative facts? :-)

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

[DNSOP] Opt-in, zone enumeration and dnsext history

[Jim Reid]

> On 10 Mar 2017, at 18:30, Frederico A C Neves  wrote:
> 
> I know others have already stated this but zone enumeration, at least
> at that time, was never the real reason for NSEC3, size of signing
> zones with mostly unsigned delegations was. This was only needed
> because of the wg lack of management and sensibility to operators
> needs leading to the historical debacle of opt-in.

There’s some selective rewriting of history going on here Fred.

Zone enumeration was an absolute showstopper for a bunch of European ccTLDs. 
They said they would not deploy DNSSEC-bis under any circumstances. I 
distinctly remember several conversations with the board and management of 
Nominet about this, their willingness to spend “whatever it took” to get NSEC3 
done, and how long it would take the IETF to finish that new protocol. AFAICT 
the size of the signed zone or the time it took to sign was not a significant 
concern for those TLDs.

Opt-in was largely a side issue in the development of DNSSEC-ter, albeit an 
important one for Verisign.

Roy Arends invented opt-in while DNSSEC-bis was being developed ~15 years ago. 
[I was his boss at the time and deeply unhappy that opt-in was going to create 
so much controversy that it would delay completion of DNSSEC-bis for at least a 
year or two. The company we worked for planned to sell DNS software that 
supported this new-fangled DNSSEC thing, so there were business drivers to get 
DNSSEC finalised quickly.] There was a *very* long and tedious argument in 
dnsext about opt-in. The eventual consensus in the WG was authenticated proof 
of non-existence mattered. So opt-in for DNSSEC-bis got killed and DNSSEC-bis 
was finally pushed out the door.

After DNSSEC-bis was done, work began on DNSEC-ter. Opt-in got dug up. Or 
hadn’t really gone away. By then the WG was long past caring and had no 
appetite to repeat the same arguments about authenticated proof of 
non-existence all over again. So opt-in found its way into the DNSEC-ter spec.

Verisign might well have said then that signing .com/.net/.org wouldn’t happen 
unless they got a protocol than included opt-in. [They may have made (and 
lost?) the same argument when work DNSSEC-bis was under way.] But that would 
have been after dnsext had already decided to do DNSSEC-ter and solve the zone 
enumeration problem that had effectively killed DNSSEC-bis deployment at birth.

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Phillip Hallam-Baker]

Shhh. don't confuse with facts.

On Fri, Mar 10, 2017 at 1:30 PM, Frederico A C Neves 
wrote:

> On Fri, Mar 10, 2017 at 01:15:42PM -0500, Shumon Huque wrote:
> ...
> >
> > Apparently there are many folks in the community who think so, otherwise
> > NSEC3 would not have been developed. I personally don't care for any
> zones
>
> I know others have already stated this but zone enumeration, at least
> at that time, was never the real reason for NSEC3, size of signing
> zones with mostly unsigned delegations was. This was only needed
> because of the wg lack of management and sensibility to operators
> needs leading to the historical debacle of opt-in. We changed the
> name, and voila opt-out ;-)
>
> Fred
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Frederico A C Neves]

On Fri, Mar 10, 2017 at 01:15:42PM -0500, Shumon Huque wrote:
...
> 
> Apparently there are many folks in the community who think so, otherwise
> NSEC3 would not have been developed. I personally don't care for any zones

I know others have already stated this but zone enumeration, at least
at that time, was never the real reason for NSEC3, size of signing
zones with mostly unsigned delegations was. This was only needed
because of the wg lack of management and sensibility to operators
needs leading to the historical debacle of opt-in. We changed the
name, and voila opt-out ;-)

Fred

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Shumon Huque]

Here are some of my arguments in support of NSEC5.

I would like to see us deploy an authenticated denial of existence
mechanism that is not eminently susceptible to offline dictionary
attack. My experience so far is that most people in the crypto
community do not look favorably on NSEC3. Not just Dan Bernstein,
whose strong criticisms are well known (and correct in my opinion).
IETF protocols should pass muster with the professional cryptographer
community.

I don't mean to bash NSEC3 - I think it was the best solution at the
time given the constraints we imposed on ourselves. But it might be
time to look forward.

I certainly agree that the deployment challenges are significant.
But we have several similar challenges already on the radar, which
we will have to tackle:

  - EdDSA

  - NSEC3 hash replacement

(The recent SHA-1 collision news does not pose an immediate threat
to NSEC3, but will surely put pressure on us to upgrade the hash
algorithm on the well known principle that attacks will inevitably
get better fast.)

  - Post Quantum Crypto algorithms (slightly longer term, but something we
need to start designing very soon).

I also wonder, given the challenges of deploying new algorithms, and
the downsides to multiple signing due to packet size concerns - is it
time to design an algorithm negotiation protocol for DNSSEC? It would
have the same initial deployment challenge, but then could help out with
new algorithm transitions going forward.

Arguably, there is an additional "implementation challenge" for NSEC5,
which is a bit more complex than rolling out just a new DNSSEC algorithm.
But I think the implementation work already done presents a positive
picture.

I know several additional folks who have expressed interest in NSEC5 -
I hope they'll speak up.

On Fri, Mar 10, 2017 at 12:46 PM, Warren Kumari  wrote:

> Especially with the prevalence of passive DNS services, I believe that
> publishing something in the DNS makes it "public" - sure, you can hide
> some things behind split-DNS, but putting `super-skrit-key.exmaple.com
> IN 600 TXT "Hunter3"` is guaranteed to end poorly.
>
> NSEC5 has some very cute tricks, but I don't agree with the premise
> that it solves a real world problem.
>

Apparently there are many folks in the community who think so, otherwise
NSEC3 would not have been developed. I personally don't care for any zones
that I run. But if we are providing a solution for folks that do care, we
should
have the most secure (yet practical) solution we know how to design.

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Warren Kumari]

Especially with the prevalence of passive DNS services, I believe that
publishing something in the DNS makes it "public" - sure, you can hide
some things behind split-DNS, but putting `super-skrit-key.exmaple.com
IN 600 TXT "Hunter3"` is guaranteed to end poorly.

NSEC5 has some very cute tricks, but I don't agree with the premise
that it solves a real world problem.

W

On Fri, Mar 10, 2017 at 12:26 PM, Evan Hunt  wrote:
> On Fri, Mar 10, 2017 at 03:16:05PM +, Woodworth, John R wrote:
>> > Is there a community of zone admins who want this so much that they
>> > won't start signing until it exists?
>>
>> With the draft's aliasing of algorithms, why couldn't (wouldn't) a zone
>> at least experimenting with this be able to provide 2 sets of keys,
>> one pre-NSEC5 and the other NSEC5 and forward?
>
> I think the question pertains to whether it's worthwhile for us to adopt
> this.
>
> If there are operators who need NSEC5 badly enough that they won't deploy
> DNSSEC until it exists, then it makes sense for the working group to take
> it on. If it turns out, however, that everyone who might like NSEC5 is also
> reasonably satisified with NSEC3, then we'd be wasting time on an academic
> exercise.  It's clever, but it's only necessary if we broadly agree that
> NSEC3 isn't meeting our needs.  I'm not sold on that point.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Evan Hunt]

On Fri, Mar 10, 2017 at 03:16:05PM +, Woodworth, John R wrote:
> > Is there a community of zone admins who want this so much that they
> > won't start signing until it exists?
> 
> With the draft's aliasing of algorithms, why couldn't (wouldn't) a zone
> at least experimenting with this be able to provide 2 sets of keys,
> one pre-NSEC5 and the other NSEC5 and forward?

I think the question pertains to whether it's worthwhile for us to adopt
this.

If there are operators who need NSEC5 badly enough that they won't deploy
DNSSEC until it exists, then it makes sense for the working group to take
it on. If it turns out, however, that everyone who might like NSEC5 is also
reasonably satisified with NSEC3, then we'd be wasting time on an academic
exercise.  It's clever, but it's only necessary if we broadly agree that
NSEC3 isn't meeting our needs.  I'm not sold on that point.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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

[DNSOP] RFC 8078 on Managing DS Records from the Parent via CDS/CDNSKEY

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 8078

Title:  Managing DS Records from the 
Parent via CDS/CDNSKEY 
Author: O. Gudmundsson, P. Wouters
Status: Standards Track
Stream: IETF
Date:   March 2017
Mailbox:olafur+i...@cloudflare.com, 
pwout...@redhat.com
Pages:  10
Characters: 21001
Updates:RFC 7344

I-D Tag:draft-ietf-dnsop-maintain-ds-06.txt

URL:https://www.rfc-editor.org/info/rfc8078

DOI:10.17487/RFC8078

RFC 7344 specifies how DNS trust can be maintained across key
rollovers in-band between parent and child.  This document elevates
RFC 7344 from Informational to Standards Track.  It also adds a
method for initial trust setup and removal of a secure entry point.

Changing a domain's DNSSEC status can be a complicated matter
involving multiple unrelated parties.  Some of these parties, such as
the DNS operator, might not even be known by all the organizations
involved.  The inability to disable DNSSEC via in-band signaling is
seen as a problem or liability that prevents some DNSSEC adoption at
a large scale.  This document adds a method for in-band signaling of
these DNSSEC status changes.

This document describes reasonable policies to ease deployment of the
initial acceptance of new secure entry points (DS records).

It is preferable that operators collaborate on the transfer or move
of a domain.  The best method is to perform a Key Signing Key (KSK)
plus Zone Signing Key (ZSK) rollover.  If that is not possible, the
method using an unsigned intermediate state described in this
document can be used to move the domain between two parties.  This
leaves the domain temporarily unsigned and vulnerable to DNS
spoofing, but that is preferred over the alternative of validation
failures due to a mismatched DS and DNSKEY record.

This document is a product of the Domain Name System Operations Working Group 
of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Dave Crocker]

On 3/10/2017 5:07 AM, Warren Kumari wrote:

Once a document becomes a WG document the authors are required to
incorporate WG consensus.

If this does not / is not happening, the chairs have the option /
responsibility to replace the authors with ones that do...

W

On Thu, Mar 9, 2017 at 3:27 PM, Paul Wouters  wrote:

...

The authors clearly stated the document will describe only what is
currently implemented and they were not willing to make changes.
How can this ever turn into a real WG document?



While of course Warren's caution, above to authors and the wg, is always
valid, I think this misses an important point of confusion in this 
thread and in the specified adoption of this draft:


While yes, Vernon said the goal was documenting the current
implementation, so did the wg chair:

On 12/20/2016 7:16 AM, tjw ietf wrote:

The draft is being present as "Informational", and the point here is
to document current working behavior in the DNS (for the past
severalyears).



When existing work is brought into the IETF, there is always a choice 
about how the current work should related to the existing effort.  For 
anything with a significant installed base, it is common -- and 
extremely helpful -- to first issue an RFC that details current practice.


The goal of the wg, then, is to ensure that the document is clear and 
accurate and useful... in terms of the established practice.  Again, 
this is an extremely common goal for an initial effort.


It is increasingly common for such existing work to have made 
engineering choices that sit poorly with some wg participants.  While 
there can be some academic satisfaction in debating superior 
alternatives, it isn't useful when documenting existing practice.


Or are folks now seeking to have the IETF eschew running code?

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Woodworth, John R]

> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Hoffman
>
> On 7 Mar 2017, at 7:29, Shumon Huque wrote:
>
> > We've requested an agenda slot at the DNSOP working group meeting at
> > IETF98 to talk about the NSEC5 protocol. Our chairs have requested
> > that we send out a note to the group ahead of time, so here it is.
> >
> > This protocol has not to our knowledge been presented at dnsop before,
> > but has been discussed previously at other IETF venues, such as SAAG.
>
> The protocol described in draft-vcelak-nsec5 has improved since it
> was first presented, but it is still unclear why we should adopt it
> as part of DNSSEC. The benefits listed in the draft are real, but they
> come at a very steep cost for zone administrators who might use NSEC5.
>

Hi Paul,

Apologies, I am somewhat new to this draft (and admittedly to the
process) but what I read was a very elegant solution to this steep
cost.  The authors seem to have gone through great pains to bridge
this period of incompatibility.

>
> Is there a community of zone admins who want this so much that they
> won't start signing until it exists?
>

With the draft's aliasing of algorithms, why couldn't (wouldn't) a zone
at least experimenting with this be able to provide 2 sets of keys,
one pre-NSEC5 and the other NSEC5 and forward?

I might be missing something here but I think I may actually love the
simplicity of it and it seems to be at least a viable bridge to NSEC5
as part of the future.  This seems to be a great use of what RFC-4035
and RFC-6840 hint at regarding multiple keys/ multiple signatures.


Best regards,
John

>
> Short of that, is there a community of zone admins who are using
> NSEC/NSEC3 white lies who find this to be a significant improvement?
>
> If not, adopting this seems like a bad idea. No one can operationally
> sign with NSEC5 until nearly all validators have it installed. In the
> meantime, a zone admin who cares about zone enumeration and wants to
> sign will use white lies, and those who don't care about zone
> enumeration won't pay any attention to this.
>
> Even though this document has some really nice design decisions in
> it, should it be adopted in DNSSEC unless it is likely to be
> deployed?
>
> --Paul Hoffman
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.

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

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Warren Kumari]

Once a document becomes a WG document the authors are required to
incorporate WG consensus.

If this does not / is not happening, the chairs have the option /
responsibility to replace the authors with ones that do...

W

On Thu, Mar 9, 2017 at 3:27 PM, Paul Wouters  wrote:
>
>
>> On Mar 9, 2017, at 18:54, tjw ietf  wrote:
>
>> We’re going to go ahead and adopt it for DNSOP, with the intention of
>> resolving the concerns people expressed by keeping the status as
>> informational (not standards track) and making sure the cautions and
>> limitations the WG discussed on the use of RPZ are clear in the document.
>
> I don't understand how this works.
>
> The authors clearly stated the document will describe only what is currently 
> implemented and they were
> not willing to make changes. How can this ever turn into a real WG document?
>
> Paul
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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