Subject: [DNSOP] Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

From: Tim Wicinski <[email-masked]>
Date: Fri, 06 Jul 2018 17:13:06 -0700

Tim Wicinski has requested publication of draft-ietf-dnsop-rfc5011-security-considerations-12 as Proposed Standard on behalf of the DNSOP working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/

---

From: Michael StJohns <[email-masked]>
Date: Fri, 6 Jul 2018 21:08:04 -0400

On 7/6/2018 8:13 PM, Tim Wicinski wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

*sigh*

Point of order:  Did I miss the final WGLC on this after this last 
version was published?  I can't actually find anything in the DNSOP 
archives and I don't remember seeing the call.   So I'm suggesting that 
we've missed a required stage.

With respect to the shepher's writeup:

1) The first reference in the shepherd's write-up  is wrong - its 
pointing to a whole other set of discussions related to Joe Abley's ideas.
2) The second reference isn't representative of the actual discussion, 
but only shows the point at which I got worn down. Please include a 
reference that actually shows the attempts to try and resolve my issues.
3) This document should not be a Proposed Standard as it documents 
nothing implementable (that is nothing implementable in a computer), but 
is operational guidance for the publication process.
4) Is it usual for the WG chair to write the shepherd's report? 
Specifically, it seems a conflict of interest for items (3) -(6).
5) The technical summary is misleading.  This is not an update to 5011, 
but guidance to the zone publisher who may have not understood the 
implications of operational choices (e.g. steady state single trust 
anchor vs 5011s recommendation of multiple trust anchors). E.g. "RFC5011 
DNSSEC Key Rollover Strategy" isn't a document referenced by this 
document, and that would be the document that would be in need of an update.
6) Same comment - it's not an update to the 5011 timers, but to the 
understanding of the publishers of such zones that use 5011.
7) Please include references of the emails of the "root server 
community" review - AFAICT, Ed Lewis was the only one to comment on the 
list and the last comment was last year.

Mike

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 9 Jul 2018 12:05:15 -0400

Tim/Suzanne -

Please cancel the request for publication until you complete the WGLC 
for this document.

The last WGLC for the document was October of last year - it failed on 
28 October 
https://www.ietf.org/mail-archive/web/dnsop/current/msg21225.html. No 
WGLC has been made since then.

The consensus referenced in the shepherd's report was meeting consensus 
- not mailing list consensus AFAICT.  Specifically, I'd like to see if 
Ed's removed his objections.  I don't have a problem with the WGLC being 
used to judge consensus - but that's not what happened here.

Later, Mike

On 7/6/2018 9:08 PM, Michael StJohns wrote:
>> Tim Wicinski has requested publication of 
>> draft-ietf-dnsop-rfc5011-security-considerations-12 as Proposed 
>> Standard on behalf of the DNSOP working group.
>>
>> Please verify the document's state at 
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/
>>
> archives and I don't remember seeing the call.   So I'm suggesting 
> that we've missed a required stage.
>
> nothing implementable (that is nothing implementable in a computer), 
> but is operational guidance for the publication process.
> 5) The technical summary is misleading.  This is not an update to 
> 5011, but guidance to the zone publisher who may have not understood 
> the implications of operational choices (e.g. steady state single 
> trust anchor vs 5011s recommendation of multiple trust anchors). E.g. 
> "RFC5011 DNSSEC Key Rollover Strategy" isn't a document referenced by 
> this document, and that would be the document that would be in need of 
> an update.
> community" review - AFAICT, Ed Lewis was the only one to comment on 
> the list and the last comment was last year.
>
> Mike
>
>
> Mike
>
>
>
>
>
>

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 10 Jul 2018 01:38:22 -0400

Michael

We talked it over and if there was a process fail, it's easier to fix now
then later. I already reached out to the AD who is stepping in for Warren
to hold off for now.

Let this be a Working Group Last Call on
draft-ietf-dnsop-rfc5011-security-considerations.
This will go from now until the end of the IETF next Friday.

The Current Intended Status is: Standards Track

We will be take comments on the changes now, and as well as during the
session on Wednesday.

Tim

On Mon, Jul 9, 2018 at 12:05 PM, Michael StJohns <[email-masked]>
wrote:

> Tim/Suzanne -
>
> Please cancel the request for publication until you complete the WGLC for
> this document.
>
> The last WGLC for the document was October of last year - it failed on 28
> October https://www.ietf.org/mail-archive/web/dnsop/current/msg21225.html.
> No WGLC has been made since then.
>
> The consensus referenced in the shepherd's report was meeting consensus -
> not mailing list consensus AFAICT.  Specifically, I'd like to see if Ed's
> removed his objections.  I don't have a problem with the WGLC being used to
> judge consensus - but that's not what happened here.
>
> Later, Mike
>
>
>
>>> Tim Wicinski has requested publication of draft-ietf-dnsop-rfc5011-security-considerations-12
>>> as Proposed Standard on behalf of the DNSOP working group.
>>>
>>> Please verify the document's state at https://datatracker.ietf.org/d
>>> oc/draft-ietf-dnsop-rfc5011-security-considerations/
>>>
>> nothing implementable (that is nothing implementable in a computer), but is
>> operational guidance for the publication process.
>> implications of operational choices (e.g. steady state single trust anchor
>> vs 5011s recommendation of multiple trust anchors). E.g. "RFC5011 DNSSEC
>> Key Rollover Strategy" isn't a document referenced by this document, and
>> that would be the document that would be in need of an update.
>> 7) Please include references of the emails of the "root server community"
>> review - AFAICT, Ed Lewis was the only one to comment on the list and the
>> last comment was last year.
>>
>> Mike
>>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>>
>

---

From: Michael StJohns <[email-masked]>
Date: Tue, 10 Jul 2018 11:35:46 -0400

Thanks Tim -

Note the changed subject line.

And as you may have guessed I object to the publication of this document 
on the basis of quality for all the reasons previously stated.  This 
version of the document is actually in worse shape than the one that 
failed last call back in October.

I strongly object to the publication of this document as a Standards 
Track document. The appropriate status  - if published - is 
Informational with or without a BCP tag on it.  The document does not 
provide any implementable protocol, and by that I mean that the only 
protocol elements in this document must be executed by humans.  There is 
no on-the-wire elements, nor any process that can be implemented by a 
DNS resolver or server.  This is solely and only an operational 
practices document, and AFAICT, none of these have ever ended up as 
Standards Track.   Or to put it more bluntly - humans are not protocol 
elements that can be standardized.  Finally, this purports to update 
RFC7538 which is Informational.

Mike

On 7/10/2018 1:38 AM, Tim Wicinski wrote:
> Michael
>
> We talked it over and if there was a process fail, it's easier to fix 
> now then later. I already reached out to the AD who is stepping in for 
> Warren to hold off for now.
>
> draft-ietf-dnsop-rfc5011-security-considerations.  This will go from 
> now until the end of the IETF next Friday.
>
> On Mon, Jul 9, 2018 at 12:05 PM, Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Tim/Suzanne -
>
>     Please cancel the request for publication until you complete the
>     WGLC for this document.
>
>     The last WGLC for the document was October of last year - it
>     failed on 28 October
>     https://www.ietf.org/mail-archive/web/dnsop/current/msg21225.html
>     <https://www.ietf.org/mail-archive/web/dnsop/current/msg21225.html>.
>     The consensus referenced in the shepherd's report was meeting
>     consensus - not mailing list consensus AFAICT. Specifically, I'd
>     like to see if Ed's removed his objections.  I don't have a
>     problem with the WGLC being used to judge consensus - but that's
>     not what happened here.
>
>     Later, Mike
>
>
>
>             draft-ietf-dnsop-rfc5011-security-considerations-12 as
>             Proposed Standard on behalf of the DNSOP working group.
>
>             <https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/>
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/dnsop>
>
>
>         *sigh*
>
>         Point of order:  Did I miss the final WGLC on this after this
>         last version was published?  I can't actually find anything in
>         the DNSOP archives and I don't remember seeing the call.   So
>         I'm suggesting that we've missed a required stage.
>
>         1) The first reference in the shepherd's write-up  is wrong -
>         its pointing to a whole other set of discussions related to
>         Joe Abley's ideas.
>         2) The second reference isn't representative of the actual
>         discussion, but only shows the point at which I got worn down.
>         Please include a reference that actually shows the attempts to
>         try and resolve my issues.
>         3) This document should not be a Proposed Standard as it
>         documents nothing implementable (that is nothing implementable
>         in a computer), but is operational guidance for the
>         publication process.
>         4) Is it usual for the WG chair to write the shepherd's
>         report? Specifically, it seems a conflict of interest for
>         items (3) -(6).
>         5) The technical summary is misleading.  This is not an update
>         to 5011, but guidance to the zone publisher who may have not
>         understood the implications of operational choices (e.g.
>         steady state single trust anchor vs 5011s recommendation of
>         multiple trust anchors). E.g. "RFC5011 DNSSEC Key Rollover
>         Strategy" isn't a document referenced by this document, and
>         6) Same comment - it's not an update to the 5011 timers, but
>         to the understanding of the publishers of such zones that use
>         5011.
>         community" review - AFAICT, Ed Lewis was the only one to
>         comment on the list and the last comment was last year.
>
>         Mike
>
>
>         Mike
>
>
>
>
>
>
>
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 10 Jul 2018 12:34:59 -0400

On 10 Jul 2018, at 11:35, Michael StJohns wrote:

> And as you may have guessed I object to the publication of this 
> document on the basis of quality for all the reasons previously 
> stated.  This version of the document is actually in worse shape than 
> the one that failed last call back in October.

Documents go to WG Last Call to determine consensus and fix errors; this 
document appears to have done both, so there was no failure.

> Informational with or without a BCP tag on it. 

There is no such thing as a "BCP tag". An RFC that is a BCP is treated 
as a standard. See Section 5 of RFC 2026.

> The document does not provide any implementable protocol, and by that 
> I mean that the only protocol elements in this document must be 
> executed by humans.  There is no on-the-wire elements, nor any 
> process that can be implemented by a DNS resolver or server.  This is 
> solely and only an operational practices document,

True.

> and AFAICT, none of these have ever ended up as Standards Track.

Not true. Plenty of WGs, including this one, put operational documents 
on standards track.

>    Or to put it more bluntly - humans are not protocol elements that 
> can be standardized. 

True, but not relevant to the issue at hand.

> Finally, this purports to update RFC7538 which is Informational.

That's a good point. The WG draft that led to RFC 7538 was marked as 
Informational for its entire lifetime, so the WG must have thought it 
was OK to treat key rollover timing considerations as Informational.

--Paul Hoffman

---

From: Michael StJohns <[email-masked]>
Date: Tue, 10 Jul 2018 13:25:07 -0400

On 7/10/2018 12:34 PM, Paul Hoffman wrote:
> Documents go to WG Last Call to determine consensus and fix errors; 
> this document appears to have done both, so there was no failure.

I'm not sure if you're word parsing or what here, but the result of the 
WGLC was that the document still needed work and that there was no 
consensus.  Generally referred to as "failing to pass the WGLC".   
Generally, passing means nits to be fixed, with a general consensus to 
publish.  That didn't happen - the "pass", so the opposite of "pass" is 
"fail".

If you're saying that the document has both fixed the issues and gained 
consensus - well, that's what this call is for.  My opinion is that the 
document still needs work, others may not agree.  As for consensus, 
AFAICT, there has been no on-the-list call from consensus since the 
previous WG meeting that noted meeting consensus - and as we all know - 
meeting consensus isn't sufficient to determine consensus.

> as a standard. See Section 5 of RFC 2026.

Mostly fair point - but while treated as a standard, a BCP is not a 
standard in the meaning of Standards Track.   So Informational or BCP, 
not Proposed Standard.  And given 7893, I'd say Informational.

>> executed by humans. There is no on-the-wire elements, nor any process 
>> that can be implemented by a DNS resolver or server.  This is solely 
>> and only an operational practices document,
>
> True.
>

Here are the RFCs that come up with "Standard Track" and "dnsop" as the 
search terms.   Which one is an "operational document"?    I didn't have 
time to search through the other pile of 8K plus RFCs, but did check 
dnsext and found a dearth of operational documents as standards there.  
AFAICT, all of these propose modifications to resolver or server behavior.

> Number 
> <https://www.rfc-editor.org/search/rfc_search_detail.php?sortkey=Number&sorting=DESC&page=25&wg_acronym=dnsop&pubstatus[]=Standards%20Track&std_trk=Proposed%20Standard&pub_date_type=any> 
>
>
> 	Files 	Title 	Authors 	Date 
> <https://www.rfc-editor.org/search/rfc_search_detail.php?sortkey=Date&sorting=DESC&page=25&wg_acronym=dnsop&pubstatus[]=Standards%20Track&std_trk=Proposed%20Standard&pub_date_type=any> 
> 	More Info 	Status
> RFC 7344 <http://www.rfc-editor.org/info/rfc7344> 	ASCII 
> <http://www.rfc-editor.org/rfc/rfc7344.txt>, PDF 
> <http://www.rfc-editor.org/pdfrfc/rfc7344.txt.pdf> 	Automating DNSSEC 
> Delegation Trust Maintenance 	W. Kumari, O. Gudmundsson, G. Barwood 
> September 2014 	Updated by RFC 8078 
> <http://www.rfc-editor.org/info/rfc8078> 	Proposed Standard (changed 
> from Informational March 2017 <https://www.rfc-editor.org/info/rfc8078>)
> RFC 7477 <http://www.rfc-editor.org/info/rfc7477> 	ASCII 
> <http://www.rfc-editor.org/rfc/rfc7477.txt>, PDF 
> <http://www.rfc-editor.org/pdfrfc/rfc7477.txt.pdf> 	Child-to-Parent 
> Synchronization in DNS 	W. Hardaker 	March 2015 	Errata 
> <http://www.rfc-editor.org/errata/rfc7477> 	Proposed Standard
> RFC 7686 <http://www.rfc-editor.org/info/rfc7686> 	ASCII 
> <http://www.rfc-editor.org/rfc/rfc7686.txt>, PDF 
> <http://www.rfc-editor.org/pdfrfc/rfc7686.txt.pdf> 	The ".onion" 
> Special-Use Domain Name 	J. Appelbaum, A. Muffett 	October 2015 	 
> Proposed Standard
> RFC 7766 <http://www.rfc-editor.org/info/rfc7766> 	ASCII 
> <http://www.rfc-editor.org/rfc/rfc7766.txt>, PDF 
> <http://www.rfc-editor.org/pdfrfc/rfc7766.txt.pdf> 	DNS Transport over 
> TCP - Implementation Requirements 	J. Dickinson, S. Dickinson, R. 
> Bellis, A. Mankin, D. Wessels 	March 2016 	Obsoletes RFC 5966 
> <http://www.rfc-editor.org/info/rfc5966>, Updates RFC 1035 
> <http://www.rfc-editor.org/info/rfc1035>, RFC 1123 
> <http://www.rfc-editor.org/info/rfc1123> 	Proposed Standard
> RFC 7828 <http://www.rfc-editor.org/info/rfc7828> 	ASCII 
> <http://www.rfc-editor.org/rfc/rfc7828.txt>, PDF 
> <http://www.rfc-editor.org/pdfrfc/rfc7828.txt.pdf> 	The 
> edns-tcp-keepalive EDNS0 Option 	P. Wouters, J. Abley, S. Dickinson, 
> R. Bellis 	April 2016 		Proposed Standard
> RFC 7873 <http://www.rfc-editor.org/info/rfc7873> 	ASCII 
> <http://www.rfc-editor.org/rfc/rfc7873.txt>, PDF 
> <http://www.rfc-editor.org/pdfrfc/rfc7873.txt.pdf> 	Domain Name System 
> (DNS) Cookies 	D. Eastlake 3rd, M. Andrews 	May 2016 		Proposed Standard
> RFC 8020 <http://www.rfc-editor.org/info/rfc8020> 	ASCII 
> <http://www.rfc-editor.org/rfc/rfc8020.txt>, PDF 
> <http://www.rfc-editor.org/pdfrfc/rfc8020.txt.pdf> 	NXDOMAIN: There 
> Really Is Nothing Underneath 	S. Bortzmeyer, S. Huque 	November 2016 
> Updates RFC 1034 <http://www.rfc-editor.org/info/rfc1034>, RFC 2308 
> <http://www.rfc-editor.org/info/rfc2308> 	Proposed Standard
> RFC 8078 <http://www.rfc-editor.org/info/rfc8078> 	ASCII 
> <http://www.rfc-editor.org/rfc/rfc8078.txt>, PDF 
> <http://www.rfc-editor.org/pdfrfc/rfc8078.txt.pdf> 	Managing DS 
> Records from the Parent via CDS/CDNSKEY 	O. Gudmundsson, P. Wouters 
> March 2017 	Errata <http://www.rfc-editor.org/errata/rfc8078>, Updates 
> RFC 7344 <http://www.rfc-editor.org/info/rfc7344> 	Proposed Standard
> RFC 8145 <http://www.rfc-editor.org/info/rfc8145> 	ASCII 
> <http://www.rfc-editor.org/rfc/rfc8145.txt>, PDF 
> <http://www.rfc-editor.org/pdfrfc/rfc8145.txt.pdf> 	Signaling Trust 
> Anchor Knowledge in DNS Security Extensions (DNSSEC) 	D. Wessels, W. 
> Kumari, P. Hoffman 	April 2017 		Proposed Standard
> RFC 8198 <http://www.rfc-editor.org/info/rfc8198> 	ASCII 
> <http://www.rfc-editor.org/rfc/rfc8198.txt>, PDF 
> <http://www.rfc-editor.org/pdfrfc/rfc8198.txt.pdf> 	Aggressive Use of 
> DNSSEC-Validated Cache 	K. Fujiwara, A. Kato, W. Kumari 	July 2017 
> Updates RFC 4035 <http://www.rfc-editor.org/info/rfc4035> 	Proposed 
> Standard
>

> True, but not relevant to the issue at hand.

And that's where you're wrong.

DNS is problematic because there are some humans in the loop - basically 
on the database management and publication side.    This is never so 
obvious as when thinking about RFC5011.  In that case, it was possible 
to specify the behavior for the resolver based on the zone content, but 
it was impossible to specify that a zone manager actually place the 
content at a specific time and with a specific set of keys and 
signatures.   If you'll note, 5011 has normative (the resolver behavior) 
and informative (suggested ways that a zone manager can publish data 
that 5011 would find useful) sections for just this purpose.

In this case, this document is all about human behavior - NMI - no 
machines involved.   Protocol standards are about consistent, coherent 
and repeatable behavior - terms rarely used with humans.

If this document had "here's the modifications to the protocol engine" 
and "here's what people should do about it" you could publish this as a 
standard, but the second section would be marked "Informative".

> was OK to treat key rollover timing considerations as Informational.

*sigh*  Sorry - RFC7583 - not 7538.

Mike

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 10 Jul 2018 11:31:59 -0700

Michael StJohns <[email-masked]> writes:

> I strongly object to the publication of this document as a Standards Track
> document.

I'll catch up on the rest of the thread later tonight (I've been gone),
but I agree with MSJ here: it should be informational; it's not a
protocol.
-- 
Wes Hardaker
USC/ISI

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 10 Jul 2018 18:06:41 -0400

> *sigh*  Sorry - RFC7583 - not 7538.

We both gave the wrong number, but what you say and what I say still 
stands: this WG earlier decided that an earlier document on key rollover 
timing considerations was Informational.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Thu, 12 Jul 2018 13:23:48 -0400

> timing considerations was Informational.

Just a quick note - the authors have no unhappiness with
Informational, and I've updated the GitHub version of the draft to
make it Informational (and also added a sentence to the Abstract which
says what this updates in RFC7583).

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