Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

2016-12-02 Thread Darcy Kevin (FCA) 
Your English literacy is fine. I believe sentences which are logically 
connected into one super-sentence have been accidentally severed into one 
sentence and one non-sentence.

That super-sentence would be:

"In the case where a zone that contains HINFO RRSets is served from an 
authority server that does not provide conventional ANY responses, it is 
possible that the HINFO RRSet in an ANY response, once cached by the initiator, 
might suppress subsequent queries from the same initiator with QTYPE=HINFO."

This is then followed by another, largely redundant sentence:

"The use of HINFO in this proposal would hence have effectively mask [sic] the 
HINFO RRSet present in the zone."

I suggest a rewording that collapses the whole paragraph into a single, tighter 
sentence:

"The HINFO RRset provided as an ANY response, as per this specification, when 
cached by the initiator, may suppress subsequent QTYPE=HINFO queries for the 
same QNAME, thus effectively masking, from that initiator, an explicit HINFO 
RRset present in the zone."


- Kevin

-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of 
Sent: Friday, December 02, 2016 2:55 PM
To: tjw ietf
Cc: dnsop
Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

At Fri, 25 Nov 2016 19:50:48 -0500,
tjw ietf  wrote:

> Please review the draft and offer relevant comments. Also, if someone 
> feels the document is *not* ready for publication, please speak out 
> with your reasons.
>
> *Also*, if you have any opinion on changing the document named from 
> 'refuse-any' to 'minimal-any', please speak out.

I've read the 03 version of the document.  I do *not* think this is ready for 
publication since I still believe we should not abuse HINFO for this purpose as 
I argued a year ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
(But other than that I think the document is quite well written).

As for renaming the file, I don't have a strong opinion, but we expect a bigger 
issue like HINFO can lead to more revisions, it would be good to rename it at 
this opportunity in order to avoid confusion for future readers.

Some specific comments on the text:

- Section 3

   1.  A DNS responder can choose to select one or subset of RRSets at
   the QNAME.

  'one or subset of RRSets' sounds a bit awkward to me, partly because
  'a subset of RRSets' should include 'one of RRSets' and can thus be
  redundant, and partly because 'subset of RRSets" might sound related
  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
  So I'd suggest changing this one of the following:
  - "one or a few of RRSets (but not all of them)"
  - "one or a few of RRSets"
  - "a subset of RRSets"
  I personally prefer the first most although it may be too verbose.

- Section 4

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, or MAY instead send a response with a single
   RRSet in the answer section.

  "a single RRSet" doesn't seem to be fully consistent of "one or
  subset of RRSets" stated in the preceding section (see the previous
  bullet).

- Section 4

   If the DNS query includes DO=1 and the QNAME corresponds to a zone
   that is known by the responder to be signed, a valid RRSIG for the
   RRSets in the answer (or authority if answer is empty) section MUST
   be returned.

  Does this also apply to a synthesized HINFO (if so, by dynamically
  signing it?)?

- Section 6

   In the case where a zone that contains HINFO RRSets is served from an
   authority server that does not provide conventional ANY responses.

  This may be just because of my English literacy, but on my first
  read it was quite confusing to me; I first thought the second 'that'
  was a relative pronoun, which would make this text an incomplete
  sentence.  If there was a comma after 'server' that would be more
  readable for me.

- Section 7: a minor typo, s/implimentations/implementations/

   not return all RRSIGS.  In the wild there are implimentations that

--
JINMEI, Tatuya

___
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] Working Group Last Call draft-ietf-dnsop-refuse-any

2016-12-02 Thread John Levine 
>ready for publication since I still believe we should not abuse HINFO
>for this purpose ...

I have to agree.  I have DNS servers that send actual useful HINFO records.

If you're going to abuse an existing rrtype, an obvious candidate is
NULL (type 10) which has been experimental for 30 years and has never
been used for anything since some pre-RFC 1035 experiments.  

Or burn a code point and invent a NOTANY record.

R's,
John

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

2016-12-02 Thread 神明達哉 
At Mon, 28 Nov 2016 11:25:11 +0100,
Matthijs Mekking  wrote:

> 2. People expressed that they would like to see ANY over TCP stick to
> the original (undefined) behavior, that is to return all RRsets at the
> QNAME. Joe replied that this is still possible with this document
> because the mechanism is "a big giant MAY", but still I think it makes
> sense to call out explicitly that the behavior MAY differ depending on
> the transport protocol.

+1 (forgot to include this point in my previous message).

--
JINMEI, Tatuya

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

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

2016-12-02 Thread 神明達哉 
At Fri, 25 Nov 2016 19:50:48 -0500,
tjw ietf  wrote:

> Please review the draft and offer relevant comments. Also, if someone feels
> the document is *not* ready for publication, please speak out with your
> reasons.
>
> *Also*, if you have any opinion on changing the document named from
> 'refuse-any' to 'minimal-any', please speak out.

I've read the 03 version of the document.  I do *not* think this is
ready for publication since I still believe we should not abuse HINFO
for this purpose as I argued a year ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
(But other than that I think the document is quite well written).

As for renaming the file, I don't have a strong opinion, but we expect
a bigger issue like HINFO can lead to more revisions, it would be good
to rename it at this opportunity in order to avoid confusion for
future readers.

Some specific comments on the text:

- Section 3

   1.  A DNS responder can choose to select one or subset of RRSets at
   the QNAME.

  'one or subset of RRSets' sounds a bit awkward to me, partly because
  'a subset of RRSets' should include 'one of RRSets' and can thus be
  redundant, and partly because 'subset of RRSets" might sound related
  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
  So I'd suggest changing this one of the following:
  - "one or a few of RRSets (but not all of them)"
  - "one or a few of RRSets"
  - "a subset of RRSets"
  I personally prefer the first most although it may be too verbose.

- Section 4

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, or MAY instead send a response with a single
   RRSet in the answer section.

  "a single RRSet" doesn't seem to be fully consistent of "one or
  subset of RRSets" stated in the preceding section (see the previous
  bullet).

- Section 4

   If the DNS query includes DO=1 and the QNAME corresponds to a zone
   that is known by the responder to be signed, a valid RRSIG for the
   RRSets in the answer (or authority if answer is empty) section MUST
   be returned.

  Does this also apply to a synthesized HINFO (if so, by dynamically
  signing it?)?

- Section 6

   In the case where a zone that contains HINFO RRSets is served from an
   authority server that does not provide conventional ANY responses.

  This may be just because of my English literacy, but on my first
  read it was quite confusing to me; I first thought the second 'that'
  was a relative pronoun, which would make this text an incomplete
  sentence.  If there was a comma after 'server' that would be more
  readable for me.

- Section 7: a minor typo, s/implimentations/implementations/

   not return all RRSIGS.  In the wild there are implimentations that

--
JINMEI, Tatuya

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

[DNSOP] Other comments on draft-york-dnsop-deploying-dnssec-crypto-algs-04

2016-12-02 Thread Edward Lewis 
Ref: 
https://www.ietf.org/id/draft-york-dnsop-deploying-dnssec-crypto-algs-04.txt

 

##  Observations on Deploying New DNSSEC Cryptographic Algorithms

## draft-york-dnsop-deploying-dnssec-crypto-algs-04

## 

## Abstract

## 

##As new cryptographic algorithms are developed for use in DNSSEC

##signing and validation, this document captures the steps needed for

##new algorithms to be deployed and enter general usage.  The intent is

##to ensure a common understanding of the typical deployment process

##and potentially identify opportunities for improvement of operations.

 

"New cryptographic algorithms are" not "developed for use iN DNSSEC" but

new DNS Security Algorithms Numbers are assigned for cryptographic algorithms

and hash functions used in DNSSEC operations when the use is defined.

 

## 1.  Introduction

## 

##The DNS Security Extensions (DNSSEC), broadly defined in [RFC4033],

##[RFC4034] and [RFC4035], make use of cryptographic algorithms in both

 

"makes use"

 

##the signing of DNS records and the validation of DNSSEC signatures by

##recursive resolvers.

 

also hash functions...

 

##The current list of cryptographic algorithms can be found in the IANA

##"Domain Name System Security (DNSSEC) Algorithm Numbers" registry

##located at 

##Algorithms are added to this IANA registry through a process defined

##in [RFC6014].  Note that [RFC6944] provides some guidance as to which

##of these algorithms should be implemented and supported.

 

The registry is introduced as DNS Security Algorithm Numbers in the IANA

Considerations of "Resource Records for the DNS Security Extensions", a.k.a.

RFC 4034.  The webpage cited has DNSSEC in the top part, but the registry entry

itself says DNS.  I'm not sure where the DNSSEC title came from, I don't see

any traceback to where it came from.  I'd stick with the formal name as defined

in RFC 4034.

 

##Historically DNSSEC signatures have primarily used cryptographic

##algorithms based on RSA keys.  As deployment of DNSSEC has increased

##there has been interest in using newer and more secure algorithms,

##particularly those using elliptic curve cryptography.

 

"Recently DNSSEC" ...historically we cavepeople used DSA. ;)

 

##o  Usage in a Delegation Signer ("DS") record {{?RFC3658}} for the

##   "chain of trust" connecting back to the root of DNS

 

RFC 3658 is considered to have been obsoleted by RFC 4034, use the latter

as the reference.

 

##In order for a new cryptographic algorithm to be fully deployed, all

##aspects of the DNS infrastructure that interact with DNSSEC must be

##updated to use the new algorithm.

## 

##This document outlines the current understanding of the components of

##the DNS infrastructure that need to be updated to deploy a new

##cryptographic algorithm.

## 

##It should be noted that DNSSEC is not alone in complexity of

##deployment.  The IAB documented "Guidelines for Cryptographic

##Algorithm Agility" in [?!RFC7696] to highlight the importance of this

##issue.

 

I'd highlight that this is an issue with software and operational

infrastructure as opposed to protocol development.  Obstacles are more

likely to be found in registration than, say, the validation algorithm,

although the latter is at the mercy of a suitably modern cryptographic

library.

 

## 2.  Aspects of Deploying New Algorithms

## 

##For a new cryptographic algorithm to be deployed in DNSSEC, the

##following aspects of the DNS infrastructure must be updated:

## 

##o  DNS resolvers performing validation

 

Particularly the crypto libraries.

 

## 

## 2.2.  Authoritative DNS Servers

## 

##The one exception is if the new cryptographic algorithms are used in

##the creation of NSEC/NSEC3 responses.  In the case of new NSEC/NSEC3

##algorithms, the authoritative DNS server software would need to be

##updated to be able to use the new algorithms.

 

This is where the distinction between cryptographic algorithm and DNS

security algorithm number is important.  In NSEC3 the server needs to know

what hash-named owned NSEC3 records are to be returned.  The server needs to

be able to hash the QNAME to know how to react, beyond that nothing else is

needed.  NSEC doesn't have this dependency.

 

## 2.4.  Registries

## 

##The registry for a top-level domain (TLD) needs to accept DS records

##using the new cryptographic algorithm.

 

Or be able to make them from DNSKEYs, as some TLDs operate.

 

## 2.5.  Registrars

## 

##Note that work is currently underway in [I-D.ietf-dnsop-maintain-ds]

##to provide an automated mechanism to update the DS records with a

##registry.  If this method becomes widely adopted, registrar web

##interfaces may no longer be needed.

 

I w

Re: [DNSOP] Would you please review our draft on deploying new DNSSEC crypto algorithms?

2016-12-02 Thread Edward Lewis 
Admittedly having not read past the abstract and responding to Scott's message 
- Scott is right on a point I think is underplayed.

The protocol parameter registry is titled "DNS Security Algorithm Numbers", see:
  
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1

...it's not DNSSEC Cryptographic Algorithms Numbers.

A DNS security algorithm number indicates a combination of a cryptographic 
algorithm *and* a hashing algorithm, plus a little of signaling of NSEC3 
awareness.  E.g., registered numbers 1, 5, 6, 7, 8, and 10 are all RSA while 8 
and 13 use SHA-256.

And, as Scott reports, there are no cryptographic algorithms exclusively used 
in DNSSEC.

On 12/1/16, 16:02, "DNSOP on behalf of Rose, Scott"  wrote:

I have read the draft and support it being made into a WG document. 
I do have some minor comments - none that change the tone of the document:
1. Introduction 5th paragraph
“DNSSEC algorithms are used…” Probably should be “DNSSEC registered 
algorithms…” There are no crypto algorithms that are part of DNSSEC only, just 
defined for use with DNSSEC.
2. There is also RFC 6975 - algorithm signaling in DNSSEC. I don’t know how 
widely deployed or used the EDNS option is, but it was proposed to help gather 
data about this very thing.
Scott

On 15 Nov 2016, at 7:41, Dan York wrote:
As mentioned at the very end of DNSOP, Olafur Gudmundsson, Ondrej Sury, Paul 
Wouters and I have a draft published that aims to document the steps involved 
with deploying a new cryptographic algorithm for DNSSEC. The overall goal is to 
make it easier to get new DNSSEC crypto algorithms deployed, both through 
documenting existing steps - and then potentially building off of this  work 
with new documents to improve some of the steps.  Right now we'd like to get 
ECDSA out, but EdDSA is coming out soon and it would be great to get that 
deployed sooner rather than later.

As I said in the session, we'd like to get reviewers and then get the document 
adopted by the WG and moved along toward publication.

The draft is at either of:

https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/[datatracker.ietf.org]
 
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04[tools.ietf.org]

Please send any comments to the list or to us as authors.

I also am maintaining this over in Github at: 
https://github.com/danyork/draft-deploying-dnssec-crypto-algs[github.com]  If 
you are a Github user you are welcome to file an issue there or send text in a 
pull request.

Regardless, we'd just like any feedback (even if to say that it looks good).

Thanks,
Dan



--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.org 
Skype: danyork   http://twitter.com/danyork[twitter.com]

http://www.internetsociety.org/[internetsociety.org]



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

==
Scott Rose, NIST
sco...@nist.gov
ph: +1-301-975-8439
Google Voice: +1-571-249-3671



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop