Subject: [DNSOP] Updated NSEC5 protocol spec and paper

From: Shumon Huque <[email-masked]>
Date: Tue, 7 Mar 2017 10:29:51 -0500

Hi folks,

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.

Sharon Goldberg has recently presented NSEC5 to good reception at
the following venues:

1) Real World Crypto conference, New York (Jan 2017)
2) IETF Boston Hub Meetup (Feb 2017)
3) DNS Privacy Workshop at NDSS'17 (Feb 2017)

The latest NSEC5 protocol now supports elliptic curve cryptography,
and uses verifiable random functions. The protocol has been implemented,
and we have good performance results to share.

There is a research paper, with many more details:

    https://eprint.iacr.org/2017/099.pdf

The current draft for the NSEC5 spec is here:

    https://tools.ietf.org/html/draft-vcelak-nsec5-04

Some IETF security folk have recommended that we split out the VRF
construction (currently described in the draft's appendix) into a
separate draft, as it may be useful to other IETF protocols. We think
that's a good idea and are working on it - we hope to have updated
drafts before the IETF98 draft cutoff deadline.

Hope to chat in person at IETF, and/or on the list.

Shumon, Sharon, Dimitris, Jan, and Dave.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Mar 2017 10:54:30 -0500

There are two reasons for splitting out the VRF

1) It is a useful building block

2) The intersection between the people who really understand the VRF math
and really understand DNS is very small

I think most DNSOps folk will want to treat VRF as a black box and let the
crypto folk put what they think is right in it and many of the people we
need to review the VRF are not going to want a lesson on DNS or NSEC5 use
of it.

On Tue, Mar 7, 2017 at 10:29 AM, Shumon Huque <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 7 Mar 2017 11:01:51 -0500

Phillip Hallam-Baker writes:
> There are two reasons for splitting out the VRF [...]
 
Thanks, Phill!  Those were our thoughts as well.  Though the VRF
appendix is still included in -04, the VRF document has already been
started.  It is planned that the appendix will disappear (to be
replaced with examples of different nsec5 responses) and the VRF
document incorporated by normative reference.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 09 Mar 2017 09:31:29 -0800

> 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.

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

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Mar 2017 21:30:12 +0100

> On Mar 9, 2017, at 18:31, Paul Hoffman <[email-masked]> wrote:
> 
> 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.
> 
> Is there a community of zone admins who want this so much that they won't start signing until it exists?

> If not, adopting this seems like a bad idea.

I agree with this summary.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Mar 2017 15:58:21 -0500

The perfect is the enemy of the good.

I suggest we first deploy NSEC0 which simply nulls out the whole NSEC/NXT
issue entirely. At this point anyone who is deploying DNSSEC is helping the
cause. Do not set membership requirements that exclude them.

Node insertion is a security concern for some DNSSEC applications but not
for all.

Implementing NSEC0 would not be a burden on validators. If nobody uses it
then there is no harm to it. If people only use it for a short time during
deployment then it is useful. If people use it and won't stop then that is
proof of a demand for NSEC5.

I completely reject your notion of where validation occurs and what the
value is BTW but that is a different issue. Bottom line is that I do not
depend on validators being deployed to the end points as I do not expect
that to happen soon and quite possibly not ever.

On Thu, Mar 9, 2017 at 12:31 PM, Paul Hoffman <[email-masked]> wrote:

> 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.
>
> 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.
>

---

From: Roy Arends <[email-masked]>
Date: Thu, 9 Mar 2017 21:05:48 +0000

> On 9 Mar 2017, at 20:58, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> I suggest we first deploy NSEC0 which simply nulls out the whole NSEC/NXT issue entirely.

What is NSEC0?

Roy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Mar 2017 16:12:39 -0500

> > I suggest we first deploy NSEC0 which simply nulls out the whole
​That which "simply nulls out the whole NSEC/NXT issue entirely."

To be specified but we could do that if we wanted to.​

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Mar 2017 16:12:40 -0500

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 9 Mar 2017 16:23:12 -0500

I believe one of the authors of the paper works for a DNS Vendor, so it 
would be interesting gauge deployment.

tim

---

From: Roy Arends <[email-masked]>
Date: Thu, 9 Mar 2017 21:41:06 +0000

> On 9 Mar 2017, at 21:12, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 
> 
> ​That which "simply nulls out the whole NSEC/NXT issue entirely.”

What is “the whole NSEC/NXT issue” ?

Roy

---

From: "Woodworth, John R" <[email-masked]>
Date: Fri, 10 Mar 2017 15:16:05 +0000

> -----Original Message-----
> From: DNSOP [mailto:[email-masked]] On Behalf Of Paul Hoffman
>
> > 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.
> >
> 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.

> 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

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

-- 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.

---

From: Evan Hunt <[email-masked]>
Date: Fri, 10 Mar 2017 17:26:55 +0000

> 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 -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 10 Mar 2017 12:46:29 -0500

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

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

---

From: Shumon Huque <[email-masked]>
Date: Fri, 10 Mar 2017 13:15:42 -0500

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.

> 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

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 10 Mar 2017 15:30:26 -0300

On Fri, Mar 10, 2017 at 01:15:42PM -0500, Shumon Huque wrote:
...
> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Mar 2017 13:33:02 -0500

Shhh. don't confuse with facts.

---

From: Jim Reid <[email-masked]>
Date: Fri, 10 Mar 2017 19:53:33 +0000

> On 10 Mar 2017, at 18:30, Frederico A C Neves <[email-masked]> wrote:
> 
> 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.

---

From: Jim Reid <[email-masked]>
Date: Fri, 10 Mar 2017 19:54:47 +0000

> On 10 Mar 2017, at 18:33, Phillip Hallam-Baker <[email-masked]> wrote:
> 

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

---

From: Dave Lawrence <[email-masked]>
Date: Fri, 10 Mar 2017 15:38:51 -0500

> 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"
<https://eprint.iacr.org/2017/099.pdf>.

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.

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 10 Mar 2017 15:44:14 -0800

> <https://eprint.iacr.org/2017/099.pdf>.

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.

> security while addressing the enumeration problem.

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

--Paul Hoffman

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 11 Mar 2017 10:21:46 +0100

Moin!

> IETF protocols should pass muster with the professional cryptographer
As others have said there is more than one way to get the zone content
without doing a dictionary attack on the authoritative server (passive
DNS, browser bars, pretty much everything that collects names). So even
if you have a technical solid solution that you can't get it from the
authoritative servers it still will be possible to do it. So you don't
solve a real world problem.

NSEC3 was done to solve two problems (easy zone enumeration, opt out)
for large providers of DNS services (ccTLDs, Verisign). All of these
providers now have DNSSEC, so what is the point on introducing
something that will cause more disruption and maybe slow down adaption
of DNSSEC further?

IMHO there are other things we should work on like getting more
people to validate and rolling to ecliptic curve algorithms.

So long
-Ralf