Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

2017-03-15 Thread Roy Arends 
Dear Paul (and wg)

I apologise for the tone. This went south quick and was due to my 
confrontational style of writing. The secspider-stats are indeed a good 
indicator, and convinced me that we shouldn’t make SHA1 related DNSKEY 
algorithms a "MUST NOT”.

In the spirit of being constructive, we (Jakob Schlyter, Matt Larson and I) 
have written a small draft (draft-arends-dnsop-dnssec-algorithm-update) that 
does two things:

it changes RSASHA1 from “Must Implement” to “Recommended to Implement”. 
(RSASHA1 is the only “MUST IMPLEMENT”)
it changes RSASHA256 from “Recommended to Implement” to “Must Implement”. 

The main motivator for this is that implementors have an incentive to move 
their implementations “default use” away from RSASHA1 (for instance, when a 
user generates a DNSKEY without specifying an algorithm, or when choosing an 
algorithm for signing in the presence of more than one algorithm.

This is done in the style of RFC6944, which states that anything that updates 
the registry table must obsolete RFC6944 (not just update). Therefor, it is as 
minimal as possible, with no guidelines and no recommendations for the future.

This is NOT a competing draft, though the titles look alike, and I do like to 
see advice and guidelines for developers and operators in a draft on the BCP 
track, not proposed standard.

I’m looking forward to discuss this with the working group on the list and 
during the Chicago IETF DNSOP session.

Warmly

Sometimes Grumpy.
(Roy Arends)

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-03.txt

2017-03-15 Thread Petr Špaček 
On 14.3.2017 12:28, Ralph Droms wrote:
> draft-ietf-dnsop-sutld-ps-03 includes revised text to address issues raised 
> during the WG last call and other editorial improvements.  The list of 
> issues, discussion and resolution are in GitHub: 
> https://github.com/Abhayakara/draft-tldr-sutld-ps
> 
> There is one substantial addition to the list of problems in section 3: the 
> use of DNSSEC with Special-Use Domain Names.

The 03 version is a very good one.

I would like to comment on one side-effect of the changes:
The Summary section was removed and the text moved elsewhere. IMHO this
makes the document less understandable to a person who was not involved
with its development.

For this reason I propose new Summary section, which would be basically
current 4.1.4.  Liaison Statement on Technical Use of Domain Names.

The reference to these two I-Ds can be at the same place as current 4.1.4.


So the new text would look like:

4.1.4.  Expired Internet Drafts Relating to SUDN
   /links to/
   [I-D.chapin-additional-reserved-tlds]
   [I-D.grothoff-iesg-special-use-p2p-names]

6. Summary
   As a result of processing requests to add names to the Special-Use
   Domain Name registry, as documented in
   [I-D.chapin-additional-reserved-tlds] and
   [I-D.grothoff-iesg-special-use-p2p-names], the IAB initiated a review
   of the process defined in RFC 6761 for adding names to the registry.
   This review was identified as in the charter of the IETF DNSOP
   working group, and the review has been conducted in that working
   group.  The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of
   the review, affirmed that the discussion would be "open and
   transparent to participation by interested parties" and explicitly
   invited members of the ICANN community to participate.
   This document is a product of the IETF DNSOP working group review of
   the registry process in RFC 6761.


I believe that original 4.1.4 nicely summarizes what this document is about.

Petr Špaček  @  CZ.NIC


> 
> In the authors' opinion, draft-ietf-dnsop-sutld-ps-03 addresses all of the WG 
> last call issues and the document is ready to be forwarded to the IESG.
> 
> - Ralph
> 
> 
>> On Mar 13, 2017, at 3:26 PM, internet-dra...@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Domain Name System Operations of the IETF.
>>
>>Title   : Special-Use Domain Names Problem Statement
>>Authors : Ted Lemon
>>  Ralph Droms
>>  Warren Kumari
>>  Filename: draft-ietf-dnsop-sutld-ps-03.txt
>>  Pages   : 27
>>  Date: 2017-03-13
>>
>> Abstract:
>>   The Special-Use Domain Names IANA registry policy defined in RFC 6761
>>   has been shown through experience to present unanticipated
>>   challenges.  This memo presents a list, intended to be comprehensive,
>>   of the problems that have been identified.  In addition it reviews
>>   the history of Domain Names and summarizes current IETF publications
>>   and some publications from other organizations relating to Special-
>>   Use Domain Names.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-03
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-03
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

2017-03-15 Thread Paul Wouters 

On Wed, 15 Mar 2017, Roy Arends wrote:


I apologise for the tone. This went south quick and was due to my confrontational 
style of writing. The secspider-stats are indeed a good indicator, and convinced me 
that we shouldn’t make SHA1 related DNSKEY algorithms a "MUST NOT”.


Thanks for reaching out Roy. I'm looking forward to talking about both
documents and ensuring that we can speed up the phasing out of SHA1,
and speed up the phasing in of newer prefered algorithms.

Paul

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

Re: [DNSOP] Fwd: New Version Notification for draft-arends-dnsop-dnssec-algorithm-update-00.txt

2017-03-15 Thread Petr Špaček 
Thank you for the draft.

I have to say that from my perspective the
draft-wouters-sury-dnsop-algorithm-update selected a better approach to
the problem. IMHO it is important to distinguish consumers and producers
of signatures as discussed in the original thread.

While I agree that draft-wouters-sury-dnsop-algorithm-update requires
substantial editorial changes the spirit seems to be correct to me so I
would rather advance draft-wouters-sury-dnsop-algorithm-update instead
of this new draft.

Sorry for being mean!

Petr Špaček  @  CZ.NIC

On 14.3.2017 09:04, Jakob Schlyter wrote:
> This draft should be of interest to this WG, providing an alternative to
> draft-wouters-sury-dnsop-algorithm-update.
> 
> jakob
> 
> 
> Forwarded message:
> 
>> From: internet-dra...@ietf.org
>> To: Roy Arends , Jakob Schlyter
>> , Matt Larson 
>> Subject: New Version Notification for
>> draft-arends-dnsop-dnssec-algorithm-update-00.txt
>> Date: Mon, 13 Mar 2017 10:47:24 -0700
>>
>> A new version of I-D, draft-arends-dnsop-dnssec-algorithm-update-00.txt
>> has been successfully submitted by Roy Arends and posted to the
>> IETF repository.
>>
>> Name:draft-arends-dnsop-dnssec-algorithm-update
>> Revision:00
>> Title:DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry
>> Updates
>> Document date:2017-03-12
>> Group:Individual Submission
>> Pages:6
>> URL:   
>> https://www.ietf.org/internet-drafts/draft-arends-dnsop-dnssec-algorithm-update-00.txt
>>
>> Status:
>> https://datatracker.ietf.org/doc/draft-arends-dnsop-dnssec-algorithm-update/
>>
>> Htmlized:  
>> https://tools.ietf.org/html/draft-arends-dnsop-dnssec-algorithm-update-00
>>
>>
>> Abstract:
>>The DNS Security Extensions (DNSSEC) require the use of cryptographic
>>algorithm suites for generating digital signatures and cryptographic
>>hashes over DNS data.  The algorithms specified for use with DNSSEC
>>are reflected in IANA registries.  This document updates some entries
>>in these registries.  The main reason for these updates is to retire
>>the use of SHA1.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
> 
> ___
> 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] Fwd: New Version Notification for draft-arends-dnsop-dnssec-algorithm-update-00.txt

2017-03-15 Thread John Dickinson 
On Tue, 2017-03-14 at 09:04 +0100, Jakob Schlyter wrote:
> This draft should be of interest to this WG, providing an alternative
> to 
> draft-wouters-sury-dnsop-algorithm-update.
> 
>   jakob

I like this simple short draft. I prefer its terminology. The only tiny
issue I have is with the wording "Must Not Implement". Since there is
no capability exchange you can not avoid talking with a peer that
happens to support RSAMD5. However, I do of course agree with the
sentiment.

John



> 
> 
> Forwarded message:
> 
> > From: internet-dra...@ietf.org
> > To: Roy Arends , Jakob Schlyter 
> > , Matt Larson 
> > Subject: New Version Notification for 
> > draft-arends-dnsop-dnssec-algorithm-update-00.txt
> > Date: Mon, 13 Mar 2017 10:47:24 -0700
> > 
> > A new version of I-D, 
> > draft-arends-dnsop-dnssec-algorithm-update-00.txt
> > has been successfully submitted by Roy Arends and posted to the
> > IETF repository.
> > 
> > Name:   draft-arends-dnsop-dnssec-algorithm-update
> > Revision:   00
> > Title:  DNS Security (DNSSEC) DNSKEY Algorithm IANA
> > Registry Updates
> > Document date:  2017-03-12
> > Group:  Individual Submission
> > Pages:  6
> > URL:
> > https://www.ietf.org/internet-drafts/draft-arends-dnsop-dnssec-algo
> > rithm-update-00.txt
> > Status: 
> > https://datatracker.ietf.org/doc/draft-arends-dnsop-dnssec-algorith
> > m-update/
> > Htmlized:   
> > https://tools.ietf.org/html/draft-arends-dnsop-dnssec-algorithm-upd
> > ate-00
> > 
> > 
> > Abstract:
> >    The DNS Security Extensions (DNSSEC) require the use of 
> > cryptographic
> >    algorithm suites for generating digital signatures and 
> > cryptographic
> >    hashes over DNS data.  The algorithms specified for use with
> > DNSSEC
> >    are reflected in IANA registries.  This document updates some 
> > entries
> >    in these registries.  The main reason for these updates is to 
> > retire
> >    the use of SHA1.
> > 
> > 
> > 
> > 
> > Please note that it may take a couple of minutes from the time of 
> > submission
> > until the htmlized version and diff are available at
> > tools.ietf.org.
> > 
> > The IETF Secretariat
> 
> ___
> 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] New Version Notification for draft-arends-dnsop-dnssec-algorithm-update-00.txt

2017-03-15 Thread Roy Arends 

> On 15 Mar 2017, at 16:39, John Dickinson  wrote:
> 
> I like this simple short draft. I prefer its terminology. The only tiny
> issue I have is with the wording "Must Not Implement". Since there is
> no capability exchange you can not avoid talking with a peer that
> happens to support RSAMD5. However, I do of course agree with the
> sentiment.

Thanks John!

The RSAMD5 status is copied verbatim from RFC6944 and this draft does not alter 
it.

Hope this helps,

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

[DNSOP] draft-arends-dnsop-dnssec-algorithm-update

2017-03-15 Thread Michael StJohns 

On 3/15/2017 6:26 AM, Roy Arends wrote:

In the spirit of being constructive, we (Jakob Schlyter, Matt Larson and I) 
have written a small draft (draft-arends-dnsop-dnssec-algorithm-update) that 
does two things:

it changes RSASHA1 from “Must Implement” to “Recommended to Implement”. 
(RSASHA1 is the only “MUST IMPLEMENT”)
it changes RSASHA256 from “Recommended to Implement” to “Must Implement”.

The main motivator for this is that implementors have an incentive to move 
their implementations “default use” away from RSASHA1 (for instance, when a 
user generates a DNSKEY without specifying an algorithm, or when choosing an 
algorithm for signing in the presence of more than one algorithm.



Hi Roy -

I did read through the draft and it looks fairly benign, but I'm 
wondering if perhaps giving some warning and planning a transition might 
be possible while still meeting the spirit of the registry table.



E.g.

Must Implement:   RSASHA1 (Until 5/31/2018), RSASHA256 (after 6/1/2018))

Must Not Implement:  RSASHA1 (After 1/1/2021)

Recommended: RSASHA1 (From 6/1/2018 to 12/31/2020), RSASHA256 (until 
5/31/2018)


This allows immediate use of SHA256 and starts the deprecation process 
for SHA1 but gives some warning to both the vendors and the operators of 
what's coming when.



Mike




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

[DNSOP] New terminology for root name service

2017-03-15 Thread Paul Hoffman 
Greetings again. RSSAC has published a lexicon of terms that are 
commonly used with respect to the root of the public DNS, but are not in 
RFC 7719. I have opened an issue for the terminology-bis document at 
https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and 
would be intereted to hear what people think about including those terms 
in our document.


--Paul Hoffman

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

[DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt

2017-03-15 Thread internet-drafts 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

Title   : Reverse DNS in IPv6 for Internet Service Providers
Author  : Lee Howard
Filename: draft-ietf-dnsop-isp-ip6rdns-03.txt
Pages   : 14
Date: 2017-03-04

Abstract:
   In IPv4, Internet Service Providers (ISPs) commonly provide IN-
   ADDR.ARPA information for their customers by prepopulating the zone
   with one PTR record for every available address.  This practice does
   not scale in IPv6.  This document analyzes different approaches and
   considerations for ISPs in managing the ip6.arpa zone for IPv6
   address space assigned to many customers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-isp-ip6rdns-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-isp-ip6rdns-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

2017-03-15 Thread Russ Housley 

> Will I-D.lewis-domain-names be published as an Informational RFC as well?  If 
> not, then the Introduction needs to extract highlights from that document.

I see that draft-ietf-dnsop-sutld-ps-03 still references 
I-D.lewis-domain-names, but I have not seen ant WG Last Call for that document. 
 What is the plan?

Russ

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

2017-03-15 Thread Ted Lemon 
On Mar 15, 2017, at 3:22 PM, Russ Housley  wrote:
> I see that draft-ietf-dnsop-sutld-ps-03 still references 
> I-D.lewis-domain-names, but I have not seen ant WG Last Call for that 
> document.  What is the plan?

It's an informative reference.   We're going to try to get Ed to publish the 
document.   If he doesn't, we'll reference the draft.   There are tons of 
references to non-RFCs in this document, so it's never going to be as elegant 
as we might like.


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

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

2017-03-15 Thread Russ Housley 
Ted:


> On Mar 15, 2017, at 3:25 PM, Ted Lemon  wrote:
> 
> On Mar 15, 2017, at 3:22 PM, Russ Housley  > wrote:
>> I see that draft-ietf-dnsop-sutld-ps-03 still references 
>> I-D.lewis-domain-names, but I have not seen ant WG Last Call for that 
>> document.  What is the plan?
> 
> It's an informative reference.   We're going to try to get Ed to publish the 
> document.   If he doesn't, we'll reference the draft.   There are tons of 
> references to non-RFCs in this document, so it's never going to be as elegant 
> as we might like.

If you think that “on this topic” in the sentient refers only to the previous 
sentence, then I am okay with that approach.  However, I do not think that is 
okay if “topic” refers to more than that.

Russ

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt

2017-03-15 Thread Lee Howard 
This was posted a couple of weeks ago, but got wedged in systems.

Diff is at 
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-isp-ip6rdns-03

I think this version is responsive to all of the comments from the
previous WGLC.

Some specific changes:
1. I do not think there is consensus that having PTRs is or is not a best
practice, so emphasizing the lack of consensus lets us move on to what an
ISP can do, if they care to do anything.
The first paragraph has been overhauled to say "While the need for a PTR
record and for it to match
   is debatable as a best practice, some network services [see Section 3]
still do rely on PTR lookups, and some check the source address of
incoming connections and verify that the PTR and A records match before
providing service.²
The same theme is supported by watering the second paragraph: ³
Administrators at ISPs should consider whether customer PTR records are
needed, and if so, evaluate methods for responding to reverse DNS queries
in IPv6."


2. Privacy considerations.
Added section: 6.  Privacy Considerations Given considerations in
[hostname], hostnames that provideinformation about a user compromises
that user's privacy.  Some usersmay want to identify their hosts using
user-specified hostnames, butthe default behavior should not be to
identify a user, theirlocation, their connectivity, or other
information in a PTR record.


I¹ve also changed the example PTRs from ³user.town.AW.² to ³string.region."



3. Dynamic DNS, on how to find a dDNS server
Ammended the sentence: There is no
   standard way to indicate to a host what server it should send dDNS
   updates to; the master listed in the SOA is often assumed to be a
   dDNS server, but this may not scale.

4. Manual user updates.
Inserted a section on this:
It is possible to create a user interface, such as a web page, that
would allow end users to enter a hostname to associate with anaddress.
 Such an interface would need to be authenticated (only theauthorized
user could add/change/delete entries).  It would need tospecify only
the host bits if the ISP changes prefixes assigned tocustomers, and
the back end would therefore need to be integratedwith prefix
assignments, so that when a new prefix was assigned to acustomer, the
DNS service would look up user-generated hostnames anddelete the old
record and create the new one. Considerations about some records being
static and others dynamic ordynamically generated (section 2.5) and
the creativity of users(section 2.3) still apply.


Also inserted a note inside ³on the fly² records: It may be possible to
allow user-specifiedhostnames for some records and generate others on
the fly; looking upa record before generating on the fly may slow
responses or may notscale well.


5. One more use case: "Service discovery: [RFC6763] specifies "DNS-based
Service Discovery"and section 11 specifically describes how PTRs are
used."

6. Noted that several servers are capable of DNS on-the-fly and removed
concerns about load.
 
A couple of comments to which this document is not responsive:
I did not make any changes proposing new solutions: this is an operations
document, not a technical spec.
I did not describe what additional applications do when there¹s no PTR;
there are six examples.
I did not revise the paragraph on negative response; I couldn¹t think how
to make the difference between timeout (lame) and NXDomain clearer. In
reading these notes I see I¹ve used different capitalization; oops.
I did not insist that ISPs must allow residential users to host mail
servers, or provide static addresses; it is out of scope.


The point of this document is that ISPs deploying IPv6 keep (still!)
saying, ³What do we do about PTRs?² If somebody wants to propose a new
technical solution, I encourage them to do so; I¹m not up to it. A lot of
people think PTRs for residential users; while I sympathize with that
position, I am certain that there is not consensus on that point, and
therefore we cannot say it is stupid in a consensus document.

Since these changes are substantive and substantial, there should be
another WGLC. Please comment! No need to wait for WGLC!

Thanks,

Lee

On 3/15/17, 2:27 PM, "dnsop-boun...@ietf.org on behalf of
internet-dra...@ietf.org"  wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Domain Name System Operations of the
>IETF.
>
>Title   : Reverse DNS in IPv6 for Internet Service
>Providers
>Author  : Lee Howard
>   Filename: draft-ietf-dnsop-isp-ip6rdns-03.txt
>   Pages   : 14
>   Date: 2017-03-04
>
>Abstract:
>   In IPv4, Internet Service Providers (ISPs) commonly provide IN-
>   ADDR.ARPA information for their customers by prepopulating the zone
>   with one PTR record for every available address.  This practice does
>   not scale in IPv6.  T

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

2017-03-15 Thread Ted Lemon 
On Mar 15, 2017, at 3:40 PM, Russ Housley  wrote:
> If you think that “on this topic” in the sentient refers only to the previous 
> sentence, then I am okay with that approach.  However, I do not think that is 
> okay if “topic” refers to more than that.

Yes, that's the precise point of referencing the document.   Possibly we should 
have stated that more clearly?   :)

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

[DNSOP] BCP 209, RFC 8109 on Initializing a DNS Resolver with Priming Queries

2017-03-15 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.

BCP 209
RFC 8109

Title:  Initializing a DNS Resolver with 
Priming Queries 
Author: P. Koch, M. Larson,
P. Hoffman
Status: Best Current Practice
Stream: IETF
Date:   March 2017
Mailbox:p...@denic.de, 
matt.lar...@icann.org, 
paul.hoff...@icann.org
Pages:  7
Characters: 15645
See Also:   BCP 209

I-D Tag:draft-ietf-dnsop-resolver-priming-11.txt

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

DOI:10.17487/RFC8109

This document describes the queries that a DNS resolver should emit
to initialize its cache.  The result is that the resolver gets both a
current NS Resource Record Set (RRset) for the root zone and the necessary 
address
information for reaching the root servers.

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


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. 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

[DNSOP] RFC6891 Section 7. Transport Considerations

2017-03-15 Thread Mark Andrews 

These two paragraphs don't match reality.  Lots of servers,
incorrectly, just set the rcode to FORMERR, set QR to 1 and return
the request message.  If we want to distingish FORMERR from EDNS
aware servers we need to provide a signal that works.  The signaling
described here doesn't.

   Responders that choose not to implement the protocol extensions
   defined in this document MUST respond with a return code (RCODE) of
   FORMERR to messages containing an OPT record in the additional
   section and MUST NOT include an OPT record in the response.

   If there is a problem with processing the OPT record itself, such as
   an option value that is badly formatted or that includes out-of-range
   values, a FORMERR MUST be returned.  If this occurs, the response
   MUST include an OPT record.  This is intended to allow the requestor
   to distinguish between servers that do not implement EDNS and format
   errors within EDNS.

Setting a EDNS header flag in the response could provide such signaling.

Additionally there are lots of servers that just ignore the OPT
record in the request and send back a response without a OPT record
the answers the query section.  I would argue that this is a better
response if you don't want to support EDNS than returning FORMERR
which should drop to a MAY from the MUST above.


Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:  +61 2 9871 4742  INTERNET: ma...@isc.org

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

[DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

2017-03-15 Thread Yu Fu 
Hi all,

We have submitted a new draft as draft-pan-dnsop-edns-isp-location-00.
This document is an improved solution for ECS(RFC7871), describes an EDNS ISP 
Location (EIL) extension to address the privacy problem of ECS, find the right 
balance between privacy improvement and user experience optimization.  EIL is 
defined to convey ISP location information that is relevant to the DNS message. 
 It will provide sufficient information for the Authoritative Server to decide 
the response without guessing geolocation of the IP address.

Your comments are appreciated.

Thanks
Lanlan & Yu

>-Original Message-
>From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
>Sent: Monday, March 13, 2017 6:07 PM
>To: Pan Lanlan; Lanlan Pan; Yu Fu
>Subject: New Version Notification for draft-pan-dnsop-edns-isp-location-00.txt
>
>
>A new version of I-D, draft-pan-dnsop-edns-isp-location-00.txt
>has been successfully submitted by Yu Fu and posted to the IETF repository.
>
>Name:  draft-pan-dnsop-edns-isp-location
>Revision:  00
>Title: ISP Location in DNS Queries
>Document date: 2017-03-13
>Group: Individual Submission
>Pages: 14
>URL:
>https://www.ietf.org/internet-drafts/draft-pan-dnsop-edns-isp-location-00.txt
>Status: 
>https://datatracker.ietf.org/doc/draft-pan-dnsop-edns-isp-location/
>Htmlized:   
>https://tools.ietf.org/html/draft-pan-dnsop-edns-isp-location-00
>
>
>Abstract:
>   This document describes an Extension Mechanisms for DNS (EDNS0)
>   option that is in active use to carry information about the network
>   that originated a DNS query and the network for which the subsequent
>   response can be cached.
>
>   It is inspired by EDNS Client Subnet (ECS) with some privacy
>   considerations, goals to reduce the "guess geolocation of client's
>   IP" work on Authoritative Nameservers.


  



The IETF Secretariat


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

Re: [DNSOP] draft-arends-dnsop-dnssec-algorithm-update

2017-03-15 Thread Doug Barton 
I can't help finding this discussion funny, as I proposed prior to the 
-bis docs that we make RSA-SHA256 mandatory, and SHA1 optional; for the 
simple reason that it was overwhelmingly likely that the root would be 
signed with the former, making it as close to mandatory to implement as 
possible without documenting it as such; and the latter as interesting 
as day-old bread.


Now here we are 13 years later, still having the same discussion, 7 
years after the root was signed with (you guessed it) RSA-SHA256. :)


DNS has a long tail indeed.

On 03/15/2017 10:22 AM, Michael StJohns wrote:

On 3/15/2017 6:26 AM, Roy Arends wrote:

In the spirit of being constructive, we (Jakob Schlyter, Matt Larson
and I) have written a small draft
(draft-arends-dnsop-dnssec-algorithm-update) that does two things:

it changes RSASHA1 from “Must Implement” to “Recommended to
Implement”. (RSASHA1 is the only “MUST IMPLEMENT”)
it changes RSASHA256 from “Recommended to Implement” to “Must Implement”.

The main motivator for this is that implementors have an incentive to
move their implementations “default use” away from RSASHA1 (for
instance, when a user generates a DNSKEY without specifying an
algorithm, or when choosing an algorithm for signing in the presence
of more than one algorithm.


FWIW I agree with Roy that we should make 256 a must-implement ASAP 
(since for all practical purposes it is already), and encourage 
implementors in the strongest possible terms to make it the default.



Must Implement:   RSASHA1 (Until 5/31/2018), RSASHA256 (after 6/1/2018))


Michael, this is pointless, unless you can demonstrate how an existing 
implementation works without being able to use the root key.



Must Not Implement:  RSASHA1 (After 1/1/2021)

Recommended: RSASHA1 (From 6/1/2018 to 12/31/2020), RSASHA256 (until
5/31/2018)


Mostly pointless, although there was an interesting point raised about 
the difference between producing signatures with SHA1, and being able to 
validate them. Telling people that we're creating a long tail by letting 
them continue to use SHA1 for N years will result in a tail of minimum N 
+ 10 years. So telling people to stop using it NOW is the right answer.


I'm torn on how to deal with validation though. "Compliant 
implementations MUST generate a warning when validating signatures with 
algorithms weaker than RSA-SHA56. Compliant implementations MUST 
generate an error for such algorithms starting 4 years from the 
publication of this document as a draft standard, and unless the records 
are signed with a compliant algorithm they should be considered unsigned."


Something like that, although obviously it needs polishing.

Doug

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

Re: [DNSOP] New terminology for root name service

2017-03-15 Thread william manning 
do you have a pointer to the rssac document?

/Wm

On Wed, Mar 15, 2017 at 10:31 AM, Paul Hoffman 
wrote:

> Greetings again. RSSAC has published a lexicon of terms that are commonly
> used with respect to the root of the public DNS, but are not in RFC 7719. I
> have opened an issue for the terminology-bis document at
> https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and
> would be intereted to hear what people think about including those terms in
> our document.
>
> --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] New terminology for root name service

2017-03-15 Thread Wessels, Duane 
Bill,

You can find RSSAC026 at the top of this page:

https://www.icann.org/groups/rssac/documents

DW



> On Mar 16, 2017, at 6:58 AM, william manning  
> wrote:
> 
> do you have a pointer to the rssac document?
> 
> /Wm
> 
> On Wed, Mar 15, 2017 at 10:31 AM, Paul Hoffman  wrote:
> Greetings again. RSSAC has published a lexicon of terms that are commonly 
> used with respect to the root of the public DNS, but are not in RFC 7719. I 
> have opened an issue for the terminology-bis document at 
> https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and would 
> be intereted to hear what people think about including those terms in our 
> document.
> 
> --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

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