Re: [DNSOP] 4 DNS presentations on MAPRG (Thu 9:30 @Place du Canada)

[Patrick McManus]

I will say that maprg has become my favorite "value added" event of IETF
week - terrific opportunity to learn about how the Internet really works in
ways a bit beyond (but relevant to) our usual focuses. (whatever those
focuses might be). Highly recommend.



On Wed, Jul 18, 2018 at 2:21 PM, Tim Wicinski  wrote:

> Thanks Giovane.   I am hoping some DNSOP folks will show up.
>
> It does conflict with DNS-SD, but those look like interesting talks.
> I've included the links for the click-adverse:
>
> https://datatracker.ietf.org/meeting/102/materials/slides-
> 102-maprg-dmap-automating-domain-name-ecosystem-
> measurements-and-applications-giovane-c-m-moura-00
> https://datatracker.ietf.org/meeting/102/materials/slides-
> 102-maprg-monitoring-dns-with-open-source-solutions-felipe-espinoza-00
> https://datatracker.ietf.org/meeting/102/materials/slides-
> 102-maprg-when-the-dyke-breaks-dissecting-dns-
> defenses-during-ddos-giovane-c-m-moura-00
> https://datatracker.ietf.org/meeting/102/materials/slides-
> 102-maprg-dnssec-ksk-2010-trust-anchor-signal-analysis-wes-hardaker-00e
>
>
>
> On Wed, Jul 18, 2018 at 2:13 PM, Giovane C. M. Moura <
> giovane.mo...@sidn.nl> wrote:
>
>>
>>
>> Hello Folks,
>>
>> So in the end of today's session, I briefly mention that there will be 4
>> presentations on MAPRG tomorrow about DNS. After that, some people told
>> me they'd would have liked  to know a bit more these presentations and
>> the group itself, since many people on DNSOP may not be aware of MAPRG.
>>
>> While I cannot speak for the MAPRG chairs[1], the group brings Internet
>> measurement folks to the IETF , and many of the works are about
>> evaluating protocols engineered here.
>>
>> Tomorrow's session will have 4 presentations on DNS[2], and two of them
>> are 20min long:
>>
>>   * When the Dike breaks: dissecting DNS Defenses during DDoS (by me, so
>> I can elaborate a bit):
>>
>> There has been various DDoS attacks against DNS; with different impact
>> on users. DNS recursives has various built-in mechanisms
>> (caching,replication, retries). In this paper, we evaluate the user's
>> experience, based on the built-in resilence of DNS, in emulated DDoS
>> attacks using Ripe Atlas. There is various tips for ops teams in
>> engineering auth servers for DDoS.
>>
>>  * Finding the source of DNS resolver users that were using old DNSSEC
>> keys, by Wes Hardaker
>>
>> Then, there are two 'heads-ups'  presentations (5min each):
>>
>>* Heads-up talk: Dmap: Automating Domain Name Ecosystem Measurements
>> and Applications, by me too
>>
>>* Heads-up talk: Monitoring DNS with open-source solutions, by Felipe
>> Espinoza
>>
>>
>> So it would be nice to have some DNSOP folks in the room for some
>> interesting discussions. It will start at 9:30 at Place du Canada.
>>
>> Best,
>>
>> /giovane
>>
>>
>> [1] https://datatracker.ietf.org/group/maprg/about/
>> [2] https://datatracker.ietf.org/meeting/102/materials/agenda-10
>> 2-maprg-02
>>
>> ___
>> 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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dns-capture-format

[Stephane Bortzmeyer]

On Fri, Jul 06, 2018 at 08:32:42PM -0400,
 Tim Wicinski  wrote 
 a message of 22 lines which said:

> This starts a Working Group Last Call for
> draft-ietf-dnsop-dns-capture-format

At IETF 99 in Prague, I implemented the version of this time
. Some problems were
raised and I think they are now addressed. C-DNS is quite different
now (much less mandatory things, for instance) and, in my opinion, the
document -07 is ready and useful. (Unfortunately, I didn't port my
work to the last draft.)


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

Re: [DNSOP] 4 DNS presentations on MAPRG (Thu 9:30 @Place du Canada)

[Tim Wicinski]

Thanks Giovane.   I am hoping some DNSOP folks will show up.

It does conflict with DNS-SD, but those look like interesting talks.
I've included the links for the click-adverse:

https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-dmap-automating-domain-name-ecosystem-measurements-and-applications-giovane-c-m-moura-00
https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-monitoring-dns-with-open-source-solutions-felipe-espinoza-00
https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-when-the-dyke-breaks-dissecting-dns-defenses-during-ddos-giovane-c-m-moura-00
https://datatracker.ietf.org/meeting/102/materials/slides-102-maprg-dnssec-ksk-2010-trust-anchor-signal-analysis-wes-hardaker-00e



On Wed, Jul 18, 2018 at 2:13 PM, Giovane C. M. Moura 
wrote:

>
>
> Hello Folks,
>
> So in the end of today's session, I briefly mention that there will be 4
> presentations on MAPRG tomorrow about DNS. After that, some people told
> me they'd would have liked  to know a bit more these presentations and
> the group itself, since many people on DNSOP may not be aware of MAPRG.
>
> While I cannot speak for the MAPRG chairs[1], the group brings Internet
> measurement folks to the IETF , and many of the works are about
> evaluating protocols engineered here.
>
> Tomorrow's session will have 4 presentations on DNS[2], and two of them
> are 20min long:
>
>   * When the Dike breaks: dissecting DNS Defenses during DDoS (by me, so
> I can elaborate a bit):
>
> There has been various DDoS attacks against DNS; with different impact
> on users. DNS recursives has various built-in mechanisms
> (caching,replication, retries). In this paper, we evaluate the user's
> experience, based on the built-in resilence of DNS, in emulated DDoS
> attacks using Ripe Atlas. There is various tips for ops teams in
> engineering auth servers for DDoS.
>
>  * Finding the source of DNS resolver users that were using old DNSSEC
> keys, by Wes Hardaker
>
> Then, there are two 'heads-ups'  presentations (5min each):
>
>* Heads-up talk: Dmap: Automating Domain Name Ecosystem Measurements
> and Applications, by me too
>
>* Heads-up talk: Monitoring DNS with open-source solutions, by Felipe
> Espinoza
>
>
> So it would be nice to have some DNSOP folks in the room for some
> interesting discussions. It will start at 9:30 at Place du Canada.
>
> Best,
>
> /giovane
>
>
> [1] https://datatracker.ietf.org/group/maprg/about/
> [2] https://datatracker.ietf.org/meeting/102/materials/agenda-102-maprg-02
>
> ___
> 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] 4 DNS presentations on MAPRG (Thu 9:30 @Place du Canada)

[Giovane C. M. Moura]

Hello Folks,

So in the end of today's session, I briefly mention that there will be 4
presentations on MAPRG tomorrow about DNS. After that, some people told
me they'd would have liked  to know a bit more these presentations and
the group itself, since many people on DNSOP may not be aware of MAPRG.

While I cannot speak for the MAPRG chairs[1], the group brings Internet
measurement folks to the IETF , and many of the works are about
evaluating protocols engineered here.

Tomorrow's session will have 4 presentations on DNS[2], and two of them
are 20min long:

  * When the Dike breaks: dissecting DNS Defenses during DDoS (by me, so
I can elaborate a bit):

There has been various DDoS attacks against DNS; with different impact
on users. DNS recursives has various built-in mechanisms
(caching,replication, retries). In this paper, we evaluate the user's
experience, based on the built-in resilence of DNS, in emulated DDoS
attacks using Ripe Atlas. There is various tips for ops teams in
engineering auth servers for DDoS.

 * Finding the source of DNS resolver users that were using old DNSSEC
keys, by Wes Hardaker

Then, there are two 'heads-ups'  presentations (5min each):

   * Heads-up talk: Dmap: Automating Domain Name Ecosystem Measurements
and Applications, by me too

   * Heads-up talk: Monitoring DNS with open-source solutions, by Felipe
Espinoza


So it would be nice to have some DNSOP folks in the room for some
interesting discussions. It will start at 9:30 at Place du Canada.

Best,

/giovane


[1] https://datatracker.ietf.org/group/maprg/about/
[2] https://datatracker.ietf.org/meeting/102/materials/agenda-102-maprg-02

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

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Tony Finch]

Ólafur Guðmundsson  wrote:

> Support adoption

+1

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger, Southwest Fisher: Variable 3 or less,
increasing 4 at times. Smooth or slight. Fair. Good.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf

[Murray S. Kucherawy]

On Wed, Jul 18, 2018 at 12:50 PM, Dave Crocker  wrote:

>
>
>> I imagine myself as a SECDIR reviewer, and believe this would be the
>> first section I would read for any document to which I'm assigned.
>> Discovering there a sentence that basically says "None" would get my back
>> up ("We'll see about that!").
>>
>> More generally, I have had success with my proposed tactic in the past,
>> so I thought I'd suggest it here.
>>
>
> I've gotten decreasingly tolerant of using gambits in a specification
> document, in order to maneuver through the process. I think the document
> should say what it needs to to do its job and not have material that is
> primarily for appeasement those in charge.  Gambits add cruft, and often
> mislead the reader into thinking there is substance when there isn't.
>
> (I think I hit my limit when we appeased an AD for KIM and added the
> requirement for the DKIM signature cover the From: field, thereby aiding in
> community misunderstanding of what DKIM does.)
>
> If the suggested change had any actual substance with respect to security
> issues, that would be quite a different matter.  But it doesn't.
>
> Obviously if the wg would prefer different language, we'll use it...
>

It's not a major issue (to me).  Just a suggestion.


> Reading the document, I got the impression that in your research you
>> discovered some underscore names that don't quite follow the proposed
>> placement.  If my inference is wrong, then so is that clause.
>>
>
> sorry, but apparently something is getting in the way of my understanding
> this issue.  Now I'm confused about the 'placement' reference.
>

I'm willing to accept that I'm inventing a problem here that doesn't
actually exist, and you're advocating more generally for keeping this
section as terse as possible, so let's skip it.

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

Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf

[Dave Crocker]

On 7/18/2018 9:28 AM, Murray S. Kucherawy wrote:
On Wed, Jul 18, 2018 at 12:21 PM, Dave Crocker > wrote:


Folks,

I'm responding to Murray's impressive proofreading details offlist,
but there are some points he raises that might need wg discussion:


Aw shucks.


COMMENT:

The text specifically calls for a stable reference. Do we have
guidance about what constitutes such a thing? I believe IANA has
its own guidelines to that end; are they available to the
Designated Expert?


I'm inclined to let IANA raise this if they see and issue and then
let them drive the resolution of this point.


Yeah, I don't have the right answer either, but I'm concerned that we're 
asking the DE to make a decision with guidelines she doesn't have (or 
worse, come up with some that are not consistent with what IANA usually 
does).



Section 6:

COMMENT:

I have doubts that SECDIR would accept this one-sentence
comment. I suggest saying something more specific, like:

"This document establishes a registry, and encourages a slight
reorganization of attributes stored in the DNS. It establishes
no new security issues."


The first clause is redundant and makes sense to have here only
either if the readers of this section haven't read the rest of the
document, or if the clause is useful to what follows.  I believe
neither applies here.


I imagine myself as a SECDIR reviewer, and believe this would be the 
first section I would read for any document to which I'm assigned.  
Discovering there a sentence that basically says "None" would get my 
back up ("We'll see about that!").


More generally, I have had success with my proposed tactic in the past, 
so I thought I'd suggest it here.


I've gotten decreasingly tolerant of using gambits in a specification 
document, in order to maneuver through the process. I think the document 
should say what it needs to to do its job and not have material that is 
primarily for appeasement those in charge.  Gambits add cruft, and often 
mislead the reader into thinking there is substance when there isn't.


(I think I hit my limit when we appeased an AD for KIM and added the 
requirement for the DKIM signature cover the From: field, thereby aiding 
in community misunderstanding of what DKIM does.)


If the suggested change had any actual substance with respect to 
security issues, that would be quite a different matter.  But it doesn't.


Obviously if the wg would prefer different language, we'll use it...




I don't understand the 'encourages' statement but suspect I don't agree.

Reading the document, I got the impression that in your research you 
discovered some underscore names that don't quite follow the proposed 
placement.  If my inference is wrong, then so is that clause.


sorry, but apparently something is getting in the way of my 
understanding this issue.  Now I'm confused about the 'placement' 
reference.


Anyhow, the only problematic, existing specs, I think, are the SRV and 
URI documents, because they create naming complexities that invite 
problems.  Especially the two-source approach that the URI spec has.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

[DNSOP] Publication has been requested for draft-ietf-dnsop-isp-ip6rdns-05

[Tim Wicinski]

Tim Wicinski has requested publication of draft-ietf-dnsop-isp-ip6rdns-05 as 
Informational on behalf of the DNSOP working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/

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

Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf-fix

[Murray S. Kucherawy]

On Wed, Jul 18, 2018 at 12:33 PM, Dave Crocker  wrote:

> On 7/18/2018 8:37 AM, Murray S. Kucherawy wrote:
>
>> Section 3.2 replaces text in Section 4.1 of something, but I don't know
>> what; the prior paragraph refers to multiple other documents.  I suggest:
>> (a) clarify which document's 4.1 is being replaced, and (b) don't bother
>> including the original (replaced) text.
>>
>
> I'll add reference to the RFC being modified, closer to the modification
> text, but I'd rather keep the old language in there, to reduce the
> likelihood that someone will replace too-much/not-enough of the existing
> text.


My concern here is based on past ART efforts where direct citation was said
to risk inaccurate copying, and thus semantic drift.  Naturally in each
instance it's easy to argue "This is a correct copy of the text being
replaced" but it's still a generally discouraged practice.

Over in DCRUP, we faced the same problem and instead produced Section 3 of
RFC8301 with this in mind, for example.

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

Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf-fix

[Dave Crocker]

On 7/18/2018 8:37 AM, Murray S. Kucherawy wrote:
Section 3.2 replaces text in Section 4.1 of something, but I don't know 
what; the prior paragraph refers to multiple other documents.  I 
suggest:  (a) clarify which document's 4.1 is being replaced, and (b) 
don't bother including the original (replaced) text.


I'll add reference to the RFC being modified, closer to the modification 
text, but I'd rather keep the old language in there, to reduce the 
likelihood that someone will replace too-much/not-enough of the existing 
text.





I believe Section 4 can include a note to the RFC Editor to remove it 
prior to publication.


oh?



Section 5, as in the other document, is too terse.  I suggest 
summarizing the fact that the only thing going on here is creating of 
IANA requirements on future work, and updating old documents to 
reference those requirements.


Same reaction as for the other document.  I think it the change creates 
a 'form' of greater substance but not the substance of substance.


It doesn't allow a security reviewer to do a better (or worse) job and 
it doesn't demonstrate meaningfully greater security knowledge of the 
writer...


Side note: FWIW I am certainly concerned that this section be 
meaningful.  When it was first required by the IAB, we were given no 
guidance about what to include and had no skill at knowing/guessing.  So 
pro forma language, similar to what I've put in, was the norm.  In most 
cases, it represented conformance to form but had no substance.  However 
in the current case, I believe it exactly summarizes the issue for these 
documents.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf

[Dave Crocker]

Folks,

I'm responding to Murray's impressive proofreading details offlist, but 
there are some points he raises that might need wg discussion:



On 7/18/2018 8:17 AM, Murray S. Kucherawy wrote:


COMMENT:

The DNS is case-insensitive so this is a minor point, but would there be 
any benefit to specifying that the registry only records the 
all-lowercase version of an underscore name?


Mumble.  The registry entries, of course, are not DNS entities.  So 
aspects of registry use might care, such as for comparisons.


And since uniqueness is the whole goal, forcing entries to use a single 
case simplifies comparison.  I'm inclined to do as Murray suggests.




COMMENT:

The text specifically calls for a stable reference. Do we have guidance 
about what constitutes such a thing? I believe IANA has its own 
guidelines to that end; are they available to the Designated Expert?


I'm inclined to let IANA raise this if they see and issue and then let 
them drive the resolution of this point.




Section 6:

COMMENT:

I have doubts that SECDIR would accept this one-sentence comment. I 
suggest saying something more specific, like:


"This document establishes a registry, and encourages a slight 
reorganization of attributes stored in the DNS. It establishes no new 
security issues."


The first clause is redundant and makes sense to have here only either 
if the readers of this section haven't read the rest of the document, or 
if the clause is useful to what follows.  I believe neither applies here.


I don't understand the 'encourages' statement but suspect I don't agree.

That leaves language that is equivalent to the existing language...



Section 6.1:

COMMENT:

This seems to me to be content that belongs in its own section outside 
of Section 6 since it doesn't seem to me to be a security issue, but 
it's worth saying. Maybe give it its own section between what's now 
Sections 3 and 4?


Well, I agree it's awkward where it is, but gosh.  An entire major 
section?  For such a small and explanatory -- rather than 
specification/normative bit of text? Mumble.


If no one minds, I would rather make it Section 1.4, just after the 
sub-section tht describes the construct.  I think it actually works well 
there.



d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] QNAME minimisation on the standards track?

[Petr Špaček]

On 18.7.2018 16:04, Dan York wrote:
> 
>> On Jul 18, 2018, at 9:46 AM, Sara Dickinson > > wrote:
>>
>>> On 17 Jul 2018, at 17:35, Paul Wouters >> > wrote:
>>>
>>> On Tue, 17 Jul 2018, tjw ietf wrote:
>>>
 Subject: Re: [DNSOP] QNAME minimisation on the standards track?
 I’d like to see a more fleshed out operational considerations section.
> 
>>>
>>> But I do believe qname minimisation is an important privacy enhancing
>>> technology that we should strongly promote as a standards track
>>> document.
>>
>> +1
>>
>> Sara.
> 
> +1. I think this is a valuable tool in our privacy toolbox and should be
> standardized.
> 
> Dan

+1, our Knot Resolver enables it by default for couple years already.

-- 
Petr Špaček  @  CZ.NIC

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

[DNSOP] Review of draft-ietf-dnsop-attrleaf-fix

[Murray S. Kucherawy]

I've reviewed this document and it also looks like it's pretty much ready.
My suggestions here are also pretty minor:

As the other document, this one uses MUST without the RFC2119 boilerplate.

Section 3.2 replaces text in Section 4.1 of something, but I don't know
what; the prior paragraph refers to multiple other documents.  I suggest:
(a) clarify which document's 4.1 is being replaced, and (b) don't bother
including the original (replaced) text.

I believe Section 4 can include a note to the RFC Editor to remove it prior
to publication.

Section 5, as in the other document, is too terse.  I suggest summarizing
the fact that the only thing going on here is creating of IANA requirements
on future work, and updating old documents to reference those requirements.

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

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Paul Ebersman]

tjw> This starts a Call for Adoption for:
tjw> draft-huque-dnsop-multi-provider-dnssec

I support adoption of this document.

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

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Frederico A C Neves]

On Fri, Jul 06, 2018 at 08:26:59PM -0400, Tim Wicinski wrote:
> We've had some interest in moving this document forward, and the chairs
> wanted to kick off this Call for Adoption before Montreal so if there
> are concerns there will be some meeting time to address.
> 
> This document is label as: Informational.  The document is attempting
> to document operational deployment models on deploying DNSSEC signed
> zones across multiple platforms.
> 
> This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec

I support the adoption of this document

Fred

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

[DNSOP] Review of draft-ietf-dnsop-attrleaf

[Murray S. Kucherawy]

I've reviewed this document and I think it's in pretty good shape, and is
just about ready to be sent up for publication.  I have some editorial
comments that are mostly minor in nature, as follows:

Section 1.1:

OLD:

   The scoping feature is particularly useful when generalized resource
   record types are used -- notably "TXT", "SRV", and "URI" [RFC1035
],
   [RFC2782 ], [RFC6335
], [RFC7553
].

NEW (formatting):

   The scoping feature is particularly useful when generalized resource
   record types are used -- notably "TXT", "SRV", and "URI" (see
[RFC1035 ],
   [RFC2782 ], [RFC6335
], and [RFC7553
]).

OLD:

   when they are the underscored name closest to the DNS root; they are
   considered 'global'.  Underscore-based names that are farther down
   the hierarchy are handled within the scope of the global underscore
   name.

NEW (consistent quoting; this is the first of several instances):

   when they are the underscored name closest to the DNS root; they are
   considered "global".  Underscore-based names that are farther down
   the hierarchy are handled within the scope of the global underscore
   name.

Section 1.3:

OLD:

   presentation convention described in Section 3.1

or [RFC1034 ] this is

NEW (typo, comma):

   presentation convention described in Section 3.1

of [RFC1034 ], this is

Section 2:

COMMENT:

   o  If a public specification calls for use of an underscore-prefixed
  domain node name, the 'global' underscored name -- the underscored
  name that is closest to the DNS root -- MUST be entered into this
  registry.


Use of "MUST" in the RFC2119 sense needs the RFC2119 boilerplate,
which isn't included in the document. This also appears in several
spots in Section 4.

I'm also not sure it applies here; there's no obvious threat to
interoperability if someone does this but doesn't register it.

(More generally, I've frequently been told that MUSTard in IANA
Considerations is a no-no.)


OLD:

   An underscored name define scope of use for specific resource record


NEW:

   An underscored name defines the scope of use for specific resource record

Section 4.1:

OLD:

   The DNS Global Underscore Scoped Entry Registry is any DNS node name
   that begin with the underscore character (_) and is the underscored

NEW (include the ASCII value):

   The DNS Global Underscore Scoped Entry Registry is any DNS node name
   that begin with the underscore character ("_", ASCII 0x5F) and is
the underscored

OLD:

   o  The required Reference for an entry MUST have a stable resolution
  to the organization controlling that registry entry


NEW (missing trailing period):

   o  The required Reference for an entry MUST have a stable resolution
  to the organization controlling that registry entry.

COMMENT:

The DNS is case-insensitive so this is a minor point, but would there
be any benefit to specifying that the registry only records the
all-lowercase version of an underscore name?

COMMENT:

The text specifically calls for a stable reference.  Do we have
guidance about what constitutes such a thing?  I believe IANA has its
own guidelines to that end; are they available to the Designated
Expert?

Section 6:

COMMENT:

I have doubts that SECDIR would accept this one-sentence comment.  I
suggest saying something more specific, like:

"This document establishes a registry, and encourages a slight
reorganization of attributes stored in the DNS.  It establishes no new
security issues."

Section 6.1:

COMMENT:

This seems to me to be content that belongs in its own section outside
of Section 6 since it doesn't seem to me to be a security issue, but
it's worth saying.  Maybe give it its own section between what's now
Sections 3 and 4?

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

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Yoshiro YONEYA]

I support this draft to be WG I-D.

-- 
Yoshiro YONEYA 

On Fri, 6 Jul 2018 20:26:59 -0400 Tim Wicinski  wrote:

> We've had some interest in moving this document forward, and the chairs
> wanted to kick off this Call for Adoption before Montreal so if there
> are concerns there will be some meeting time to address.
> 
> This document is label as: Informational.  The document is attempting
> to document operational deployment models on deploying DNSSEC signed
> zones across multiple platforms.
> 
> This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/
> 
> Please review this draft to see if you think it is suitable for
> adoption by DNSOP, and comments to the list, clearly stating your view.
> The authors will be at the next meeting to address questions or concerns.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 20 July 2018
> 
> Thanks,
> Tim

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

Re: [DNSOP] QNAME minimisation on the standards track?

[Dan York]

> On Jul 18, 2018, at 9:46 AM, Sara Dickinson  wrote:
> 
>> On 17 Jul 2018, at 17:35, Paul Wouters  wrote:
>> 
>> On Tue, 17 Jul 2018, tjw ietf wrote:
>> 
>>> Subject: Re: [DNSOP] QNAME minimisation on the standards track?
>>> I’d like to see a more fleshed out operational considerations section.

>> 
>> But I do believe qname minimisation is an important privacy enhancing
>> technology that we should strongly promote as a standards track
>> document.
> 
> +1
> 
> Sara.

+1. I think this is a valuable tool in our privacy toolbox and should be 
standardized.

Dan



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

Re: [DNSOP] QNAME minimisation on the standards track?

[Sara Dickinson]

> On 17 Jul 2018, at 17:35, Paul Wouters  wrote:
> 
> On Tue, 17 Jul 2018, tjw ietf wrote:
> 
>> Subject: Re: [DNSOP] QNAME minimisation on the standards track?
>> I’d like to see a more fleshed out operational considerations section.
> 
> That would be good indeed. Especially with respect to broken DNS load
> balancers.
> 
> I have enabled it in Fedora from the start and did run into a few problem
> domains, and some people turning it off. But that happened less than I
> had expected. Red Hat did not yet enable this in RHEL7 but it is planned
> to be enabled in RHEL8.
> 
> But I do believe qname minimisation is an important privacy enhancing
> technology that we should strongly promote as a standards track
> document.

+1

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

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Ólafur Guðmundsson]

Support adoption

this is actually a needed document, due to the fact that many "high value
zones" want to use multiple vendors.

   Olafur



On Fri, Jul 6, 2018 at 8:26 PM, Tim Wicinski  wrote:

>
> We've had some interest in moving this document forward, and the chairs
> wanted to kick off this Call for Adoption before Montreal so if there
> are concerns there will be some meeting time to address.
>
> This document is label as: Informational.  The document is attempting
> to document operational deployment models on deploying DNSSEC signed
> zones across multiple platforms.
>
> This starts a Call for Adoption for: draft-huque-dnsop-multi-
> provider-dnssec
>
> The draft is available here: https://datatracker.ietf.org/
> doc/draft-huque-dnsop-multi-provider-dnssec/
>
> Please review this draft to see if you think it is suitable for
> adoption by DNSOP, and comments to the list, clearly stating your view.
> The authors will be at the next meeting to address questions or concerns.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 20 July 2018
>
> Thanks,
> Tim
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-13.txt

[Warren Kumari]

The authors are more than happy to change the name to that...

W
On Wed, Jul 18, 2018 at 9:13 AM Ólafur Guðmundsson
 wrote:
>
>
> Hi
> i read this document over with fresh eyes and tried to ignore any history.
>
> Summary: Publication considered harmful
>
> Reasons: This document calls itself "Security Considerations" but in reality 
> all it is covering is "Publication considerations by Authority"
> the document does not cover at all the consumption of RFC5011 events by 
> resolvers which IMHO are the more important part of the protocol.
>
>  Olafur
>
>
> On Mon, Jul 16, 2018 at 8:49 AM,  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 WG of the 
>> IETF.
>>
>> Title   : Security Considerations for RFC5011 Publishers
>> Authors : Wes Hardaker
>>   Warren Kumari
>> Filename: 
>> draft-ietf-dnsop-rfc5011-security-considerations-13.txt
>> Pages   : 20
>> Date: 2018-07-16
>>
>> Abstract:
>>This document extends the RFC5011 rollover strategy with timing
>>advice that must be followed by the publisher in order to maintain
>>security.  Specifically, this document describes the math behind the
>>minimum time-length that a DNS zone publisher must wait before
>>signing exclusively with recently added DNSKEYs.  This document also
>>describes the minimum time-length that a DNS zone publisher must wait
>>after publishing a revoked DNSKEY before assuming that all active
>>RFC5011 resolvers should have seen the revocation-marked key and
>>removed it from their list of trust anchors.
>>
>>This document contains much math and complicated equations, but the
>>summary is that the key rollover / revocation time is much longer
>>than intuition would suggest.  This document updates RFC7583 by
>>adding an additional delays (sigExpirationTime and
>>timingSafetyMargin).
>>
>>If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to
>>advertise this DNSKEY as a new Secure Entry Point key for use as a
>>trust anchor, you probably don't need to read this document.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-13
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-13
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-13
>>
>>
>> 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
>
>
>
>
> --
> Ólafur Gudmundsson | Engineering Director
> www.cloudflare.com blog.cloudflare.com
> ___
> 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] [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (room change)

[Tony Finch]

[ pruned CC list ]

Ray Bellis  wrote:

> On 17/07/2018 19:43, Shane Kerr wrote:
>
> > Ray Bellis: ANAME shifts work to resolvers; a really bad idea.
>
> correction here - what I actually said was that in the transitional
> phase ANAME shifts work to * authoritatives *.

>From my perspective, it shifts work from manual / static to automated /
dynamic, which is a really good idea :-)

In my setup, with signed zones and traditional secondaries, it isn't
possible for most of my auth servers to actively expand ANAMEs, so the
extra auth work only happens on the primary / signer.

("active" / "passive" ANAME terminology from
https://mailarchive.ietf.org/arch/msg/dnsop/0HM5FkROQ8cBMSa5ZHwdsqGvKoQ)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
North Biscay: Variable 3 or 4, becoming northerly or northeasterly 4 or 5.
Slight or moderate. Occasional rain later. Moderate or good.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-13.txt

[Ólafur Guðmundsson]

Hi
i read this document over with fresh eyes and tried to ignore any history.

Summary: Publication considered harmful

Reasons: This document calls itself "Security Considerations" but in
reality all it is covering is "Publication considerations by Authority"
the document does not cover at all the consumption of RFC5011 events by
resolvers which IMHO are the more important part of the protocol.

 Olafur


On Mon, Jul 16, 2018 at 8:49 AM,  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 WG of the
> IETF.
>
> Title   : Security Considerations for RFC5011 Publishers
> Authors : Wes Hardaker
>   Warren Kumari
> Filename: draft-ietf-dnsop-rfc5011-
> security-considerations-13.txt
> Pages   : 20
> Date: 2018-07-16
>
> Abstract:
>This document extends the RFC5011 rollover strategy with timing
>advice that must be followed by the publisher in order to maintain
>security.  Specifically, this document describes the math behind the
>minimum time-length that a DNS zone publisher must wait before
>signing exclusively with recently added DNSKEYs.  This document also
>describes the minimum time-length that a DNS zone publisher must wait
>after publishing a revoked DNSKEY before assuming that all active
>RFC5011 resolvers should have seen the revocation-marked key and
>removed it from their list of trust anchors.
>
>This document contains much math and complicated equations, but the
>summary is that the key rollover / revocation time is much longer
>than intuition would suggest.  This document updates RFC7583 by
>adding an additional delays (sigExpirationTime and
>timingSafetyMargin).
>
>If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to
>advertise this DNSKEY as a new Secure Entry Point key for use as a
>trust anchor, you probably don't need to read this document.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-
> security-considerations/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-
> security-considerations-13
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-
> considerations-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-
> security-considerations-13
>
>
> 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
>



-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] SRV and HTTP - 18:30 Tuesday (room change)

[Ray Bellis]

On 17/07/2018 19:43, Shane Kerr wrote:

> Ray Bellis: ANAME shifts work to resolvers; a really bad idea.

correction here - what I actually said was that in the transitional
phase ANAME shifts work to * authoritatives *.

Ray

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

[DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-09.txt

[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 WG of the IETF.

Title   : A Common Operational Problem in DNS Servers - Failure 
To Respond.
Author  : M. Andrews
Filename: draft-ietf-dnsop-no-response-issue-09.txt
Pages   : 25
Date: 2018-07-18

Abstract:
   The DNS is a query / response protocol.  Failing to respond to
   queries, or responding incorrectly, causes both immediate operational
   problems and long term problems with protocol development.

   This document identifies a number of common kinds of queries to which
   some servers either fail to respond or else respond incorrectly.
   This document also suggests procedures for TLD and other zone
   operators to apply to help reduce / eliminate the problem.

   The document does not look at the DNS data itself, just the structure
   of the responses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-09
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-no-response-issue-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-09


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] QNAME minimisation on the standards track?

[Paul Hoffman]

On 18 Jul 2018, at 1:33, manu tman wrote:


I'd like to see this standardized too.

Side note: I would also be interested to get a return of experience 
from

people operating qname minimization at scale, the type of issues
encountered, what are the ratios of such errors hint @marek :)


Just to be clear to the WG: Stéphane and I would love to be adding 
operational experience with minimization to the draft. That's the main 
reason we didn't just ask for the document to be moved from Experimental 
to Standards Track in-place.


--Paul Hoffman

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