Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Ralf Weber]

Moin!

On 10 Mar 2017, at 19:15, Shumon Huque wrote:

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

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

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

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

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] Updated NSEC5 protocol spec and paper

[Roy Arends]

> On 9 Mar 2017, at 21:12, Phillip Hallam-Baker  wrote:
> 
> 
> 
> On Thu, Mar 9, 2017 at 4:05 PM, Roy Arends  wrote:
> 
> > On 9 Mar 2017, at 20:58, Phillip Hallam-Baker  wrote:
> >
> > I suggest we first deploy NSEC0 which simply nulls out the whole NSEC/NXT 
> > issue entirely.
> 
> What is NSEC0?
> 
> 
> ​That which "simply nulls out the whole NSEC/NXT issue entirely.”

What is “the whole NSEC/NXT issue” ?

Roy



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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Tim Wicinski]

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


tim


On 3/9/17 12:31 PM, Paul Hoffman wrote:

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.

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

___
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

[Phillip Hallam-Baker]

On Thu, Mar 9, 2017 at 4:05 PM, Roy Arends  wrote:

>
> > On 9 Mar 2017, at 20:58, Phillip Hallam-Baker 
> wrote:
> >
> > I suggest we first deploy NSEC0 which simply nulls out the whole
> NSEC/NXT issue entirely.
>
> What is NSEC0?
>
>
​That which "simply nulls out the whole NSEC/NXT issue entirely."

To be specified but we could do that if we wanted to.​
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Phillip Hallam-Baker]

On Thu, Mar 9, 2017 at 4:05 PM, Roy Arends  wrote:

>
> > On 9 Mar 2017, at 20:58, Phillip Hallam-Baker 
> wrote:
> >
> > I suggest we first deploy NSEC0 which simply nulls out the whole
> NSEC/NXT issue entirely.
>
> What is NSEC0?
>
>
​That which "simply nulls out the whole NSEC/NXT issue entirely."

To be specified but we could do that if we wanted to.​
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Roy Arends]

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

What is NSEC0?

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Phillip Hallam-Baker]

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

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

[Paul Wouters]

> On Mar 9, 2017, at 18:31, Paul Hoffman  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 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated NSEC5 protocol spec and paper

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


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

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Dave Lawrence]

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.

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

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Phillip Hallam-Baker]

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

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

[DNSOP] Updated NSEC5 protocol spec and paper

[Shumon Huque]

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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop