TC bit is unacceptable too.
We need to come to a decision about this, and that will require everyone
with an opinion to chime in.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
as well:
https://datatracker.ietf.org/doc/draft-hardaker-dnsop-drop/
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
y
> >provides secured AXFR transfers, which helps defeat issues with
> >unsigned glue records being potentially modified in transit (see
> >Section 2).
>
> I'm hesitant to do this because the text you give here is different
> than the text on the web site
ry for adoption). But thanks, your voice matches what
looks to be the rest to the norm.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e original client will
be perceived only to have come from the resolver or forwarder sending
it.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
as intentional. (if it is intentional,
clarification text would certainly be good)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
igned to indicate you
should somehow describe where you got the information from. But we're
not prescribing how, since that's implementation dependent. Any
suggested text you'd prefer?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://w
at, but shortened it a bit to:
When doing so, the source of the error SHOULD be
attributed in the EXTRA-TEXT field, since an EDNS0 option
received by the original client will be perceived only to have
come from the resolver or forwarder sending it.
Sound ok?
--
Wes Hardaker
U
u (yet), so if others think this suggestion from Mike is
worth holding the draft up further, please speak ASAP.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
but falling back to the old zone when none
of the "new" glue were working (aka, DoSed by changes). I could also
see someone else make the opposite change. I could see some
implementations deciding to stop service (it sure makes users notice
faster).
These are all engineering and deplo
verage zone update frequency."
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Eric Orth writes:
> Took a look at the diff. I believe this resolves all my previous
> concerns.
Awesome, thanks Eric.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
MUST NOT alter DNS protocol processing.
We could add a note as well about the scope of the document, though I
think it can be derived from the above sentence:
EDE content is not attempting to address the lack security in DNS
error messages.
--
Wes Hardaker
USC/ISI
__
cument
introduces a new DNSKEY flag called DELEGATION_ONLY that indicates that
the particular zone will never sign zone data across a label.". IE, the
whole point is to communicate that a zone is such a zone.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
us things with an EDE while still following the specs
> on the important handling of the RCODE as the primary error code.
>
>
Hi Eric,
Thanks for the (again) well thought out comments. Do you have a counter
proposal sentence?
>
> --
> Wes Hardaker
> USC/ISI
>
&
us things with an EDE while still following the specs
> on the important handling of the RCODE as the primary error code.
>
>
Hi Eric,
Thanks for the (again) well thought out comments. Do you have a counter
proposal sentence that could be added to the security seciton?
--
Wes Hardaker
USC/ISI
at this isn't just a boilerplate
> description of standard DNS behavior but is actually an important warning
> specific to subtle implications of the
> nature of EDE.
Thanks for the feedback Eric.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
quot; one beyond that. IE, the text now looks like:
INFO-CODE: 25-65535
Purpose: Unasigned
Reference: Section 5.2
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
lso do not add the "reserved" section since the IANA ranges were
discussed extensively and the current number ranges are the result of a
consensus I didn't want to have one person change without a lot of
backup agreement.
--
Wes Hardaker
USC/ISI
er). But, IMHO, it shouldn't be tied to a larger topic's
(DNSSEC Transparency) implementation.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Tim Wicinski writes:
> We are looking for *explicit* support for adoption.
I support it, though I'd feel more comfortable hearing from operators
that want to deploy it. I suspect there are many, but that's just suspicion.
--
Wes Hardaker
USC/
Joe Abley writes:
> On Apr 27, 2020, at 18:28, Wes Hardaker wrote:
>
> > Thanks for the comments. I'm working on a more clear rewrite of the
> > introduction. I'd love your feedback on it once I get it wrapped up.
>
> Yes, for sure! Happy to do that.
Half done. Ei
records that link to both a DELEGATION_ONLY marked and an unmarked
DNSKEY would be considered suspicious (or at least in transition).
Circumventing this through obfuscation would require the collusion of
their parent as well. Finally, a DELEGATION_ONLY flagged DNSKEY for
the root zon
couldn't deploy it.
> Anyway, thanks for the edits; I will send comments back to the list
> when I've had a chance to read them thoroughly.
Great!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
h a stronger background history and purpose. Hopefully.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
DNSSEC Transparency would certainly be helpful for auditing purposes.
But protection is provided to validating resolvers even without it. And
yes, DNSSEC Transparency probably needs our draft in order to reach scalability.
--
Wes Hardaker
USC/ISI
___
what-complex security cases)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
an NS to its own name [curious minds want to know].
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
scussed (multiple times) in the WG and the
conclusion was that EDE cannot alter processing, hence the strong
language. So in the end we didn't change the text to soften it, as it
would counter the decisions of the larger past discussions.
--
Wes Hardaker
USC/ISI
__
Tim Wicinski writes:
> We are looking for *explicit* support for adoption.
Yes please!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
that before
accepting this as a viable path forward.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Hoffman writes:
> If the WG wants, this short draft could be a WG document.
Yes please.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Roy Arends writes:
> The can never be registered. There is no collision. That is the point
> of all of this.
Then why does your draft say "unlikely" in multiple places rather than
the strength of your wording above: "can never"
and short
talks. We are soliciting short (1 page text + 1 page references)
abstracts for people who are interested presenting. Abstracts are due
soon (June 25), but it's only a short abstract (limit of 1
page). Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI).
Please let me know
//blog.apnic.net/2020/04/13/whats-in-a-name/
[2]: https://xkcd.com/1170/
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
rded from something upstream (double hops
provide no trust in DOH (or any other secured transport) without
DNSSEC or some other signing mechanism)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
d, try again
later" essentially?
> 2) rate-limiting was applied
So this would be used in the common RRL case, where information would be
left out and the TC bit was set? IE, the EDE code would indicate that
RRL had been hit; that makes some sense.
-namespace-options-00.txt
has been successfully submitted by Wes Hardaker and posted to the
IETF repository.
Name: draft-hardaker-dnsop-private-namespace-options
Revision: 00
Title: DNS Private Namespace Options
Document date: 2020-11-02
Group: Individual Submission
ying to use something that included the world "global" to be
super-clear this is the "big one".
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Hoffman writes:
> There is "global DNS" from RFC 8499. Or is your GID supposed to be something
> different?
Same thing.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
op-internal].
>
> I read the above text as telling me that .internal will never exist in
> the GID.
Ahh... thanks for the precise reference.
Yes, those two bullets are backwards in their examples. Ugh. .internal
and .zz should be switched there.
(f
"John Levine" writes:
> They think DoH is swell, but not when it bypasses security controls
> and leaks info to random outside people
At least 15% of network operators seem to agree.
https://www.isi.edu/~hardaker/news/20191120-canary-domain-measuring.html
--
Wes
ements.
Hope to get a new version out soon.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
out
conversation where most of the WG stopped reading due to the harsh
language of some messages. It can probably be dropped from the active
list because of this.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listi
veys various techniques in wide use today,
> the pros and cons of each, and possible improvements.
Adding my thoughts: well written and highly useful document. Should
definitely be an informational document.
--
Wes Hardaker
USC/ISI
___
DNSOP mai
FYI, we've updated the draft with the latest discussion "maybe
consensus" about insecure vs servfail vs various nsec3 iteration counts.
Start of forwarded message
From: internet-dra...@ietf.org
To: "Viktor Dukhovni" ,
"We
there may be consensus to put something like
that in we'll put that on a todo list for the next version.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
certainly an interesting thing to think about, but it starts to
get in between the relationship of primaries and secondaries. Is that
something that should be "standardized"?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
h
Florian Obser writes:
> I did have to refresh my memory on how NSEC3PARAM works by glancing at
> RFC 5155 though. Maybe something like this at the end of
> "3. Best-practice for zone publishers" would be helpful:
Thanks for the suggested text, added!
--
W
to do in order to get consensus around a few points, but this
shouldn't be a long process I don't think to get out the door.
Please do drop comments to the list about any changes, or feel free to
submit PRs as well.
--
Wes Hardaker
USC/ISI
___
DNSOP mailin
decide to create some new
special _label that does a privacy separation. Because we hack DNS
never-endingly.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
leaves what to publish it as. Maybe informational would leave
everyone more comfortable?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
des that without the ultra-security required by others?
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Here's another document for folks to think about wrt its contents. I'd
love feedback. Or if the WG is brave, adoption.
Start of forwarded message
From: internet-dra...@ietf.org
To: "Wes Hardaker"
Subject: New Version Notification for
draf
Greetings all,
Viktor and I have been working on a BCP to provide guidance on selecting
reasonable NSEC3 parameters. We'd love your feedback and for dnsop to
consider adopting it.
A new version of I-D, draft-hardaker-dnsop-nsec3-guidance-02.txt
has been successfully submitted by Wes Hardaker
k the IAB to make a request to
IANA to change things, and it does seem like dropping DS/SHA-1 is a
reasonable thing to ask. I don't think it needs a specification (RFC)
or anything -- we don't specify operational parameters much (nor do I
think we should).
--
Wes Hardake
he end, there should be a goal behind why we want to publish
something. If that goal is "know people do this. don't do this.
please stop", then that may be a reasonable goal. If we're just going
to document history, without recommendations (to stop), then I think it
may bring more harm than good.
). But there is of course a risk of we'll never
get to a definitive value, and may operators by constantly lowering it
and they have to keep changing values.
So, the question: what's the right FINAL value to put in the draft
before LC?
--
Wes Hardaker
USC/ISI
to should eventually be published as an RFC.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
and short talks. We are
soliciting short (1 page text + 1 page references) abstracts from people who
are interested presenting. Abstracts are due soon (October 26), but they're
short. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI).
For details about DINR2021, see https://ant.isi
he end of the reasons sentence, which I've just done.
Thanks for the comment!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
dance is good to have.
Thanks Peter. I agree completely on the "I'm torn" feeling.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
internet-dra...@ietf.org writes:
> Title : Guidance for NSEC3 parameter settings
> Authors : Wes Hardaker
> Viktor Dukhovni
> Filename: draft-ietf-dnsop-nsec3-guidance-02.txt
> Pages :
to submit something.
FYI, I'm CCing the new DANCE WG since I think DANCE is a great example
how we're using the DNS in potentially new ways and DANCE participants
may be interested in participating as well.
Start of forwarded message
From: Wes Hardaker
To: dnsop
OP
strives for implementations of specs, I think this is the number we
should publish *unless the vendors speak up and say they'll drive lower*.
150 is higher than almost everyone would ideally like, and zero would
certainly be a nice target. But without implementation...
--
Wes Hardak
Miek Gieben writes:
> To update, my 'wants' would actually be 0.
Thanks Miek,
Its always hard to interpret what people say into hard numbers :-)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listi
hink we need to hear from most
implementations in order to publish as an RFC. So...
> As for Knot Resolver, I see no problem in setting the hard limit
> lower, especially if that gets published in this RFC.
Excellent, thank you!
--
Wes Hardaker
USC/ISI
___
h
minimally covering NSEC records [RFC4470] also incures a cost, and
zone owners should measure the computational difference in deploying
both RFC4470 or NSEC3.
Which is fairly strong (SHOULD [use NSEC]) with reasoning behind the
statement already. How do you think we should specifical
ions refuse to switch to"?
In part, I worry that code authors would object to having just changed
something and refused to change again. It seems like reports are
overcoming that problem though :-)
[I'm not sure we're at zero yet...]
--
Wes
t them to post that note here
soon (IETF week is always busy, as everyone knows, but I'm sure it'll
arrive today).
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Vladimír Čunát writes:
> On 26/02/2022 00.30, Wes Hardaker wrote:
> > Validating resolvers MAY choose to not respond to NSEC3 records with
> > iterations larger than 0.
>
> The -05 version sounds clearer here than -04 ("not respond" above) or
> -03. Than
lementers SHOULD
> set the point above which a zone is treated for certain values of NSEC3
> iterations counts to the same as the point where a validating resolver
> begins returning SERVFAIL.
>
> Is "as insecure" missing after "treated"?
Yep, good catch.
--
I just published draft-ietf-dnsop-nsec3-guidance-06.txt which has much
better text in 3.2 (Recommendation for Validating Resolvers). -06
resolves all outstanding issues that I'm aware of at the moment.
(please don't read -05 -- it was broken [thanks Viktor]).
--
Wes Hardaker
USC/ISI
Petr Špaček writes:
> On 07. 03. 22 17:51, internet-dra...@ietf.org wrote:
> > Filename: draft-ietf-dnsop-nsec3-guidance-06.txt
>
> I have no nits to report.
>
> Such thing have not happened to me for a long time - well done!
:-) :-) :-)
--
t's been discussed before. So to
the others: please chime in if you agree and we want to revert the
existing consensus based on this new thinking.
> Additionally I've submitted PR#6 with purely editorial nits.
Thank you!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
internet-dra...@ietf.org writes:
> Title : Guidance for NSEC3 parameter settings
> Authors : Wes Hardaker
> Viktor Dukhovni
> Filename: draft-ietf-dnsop-nsec3-guidance-04.txt
> Pages :
Vladimír Čunát writes:
> On 09/02/2022 22.41, Wes Hardaker wrote:
>
> So I've re-arranged things a bit to hopefully address the flow better.
> Let em know if you think further improvements are warranted.
>
> I'd still probably suggest at least a minimalist ch
d to the end of the 3.1 section, fyi, and integrated with other salt
discussions there.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
d of changes. In general, I believe most people are
happy with it and its ready for LC.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
will likely result in
>returning a SERVFAIL to the client when no acceptable responses are
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e rest of the "line", though that's a horrible
misuse of a noun as the order of acceptance was never assured based on
the poll results.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
crease risk of
> interoperability problems.
> --
Sentence added -- seems wildly agreed upon.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Vixie writes:
> if we must say this, s/vendors/implementers/, please. some of us when
> we play with dns or dnssec don't share our resulting code. --vixie
Good catch; I've changed all references.
--
Wes Hardaker
USC/ISI
___
DNSOP mailin
Whoops, good catch thanks.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e-read it and tell me any of my edits were incorrect or changed the
meaning :-)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t;iteration count.
Thanks for the good text Matthijs. I've added it tot he bottom of the
existing 3.2, which seems to be where consensus indicated it should go.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ase that way, but I
> don't care really. It's an
> advantage unstated in the draft that this is very easy to do, leaving no room
> for bugs (e.g.
> unintentional downgrade opportunities).
So I've re-arranged things a bit to hopefully address the flow better.
Let em know if you think fu
internet-dra...@ietf.org writes:
> A new version of I-D, draft-ietf-dnsop-nsec3-guidance-03.txt
> has been successfully submitted by Wes Hardaker and posted to the
> IETF repository.
>
> Name: draft-ietf-dnsop-nsec3-guidance
> Revision: 03
Sorry the
and will be ok in -10.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
This version only fixes rendering issues.
Tim/Paul: I think this version should resolve all comments/etc from the IESG.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Petr Špaček writes:
> Sorry for being so late on this ...
Thanks Petr!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ing” (signing again) instead of
> “resigning” (quitting).
>
> 3. Appendix B has “The table (Appendix C)
>below”
>
> The “(Appendix C)” part appears to be a mistake? The table is uncaptioned, I
> guess you either should caption it
a pain. I haven't figured out the right way to fix that in
markdown source yet, but by the time its all published we'll get it fixed.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Zaheduzzaman Sarker via Datatracker writes:
> - the updating RFC 5155 issue like others have, so, lets support Paul's
> discuss.
I've added a reference.
> - RFC 8174 should be in the normative reference.
Also done.
--
Wes Hardake
```
> Two consecutive dots.
Were you perhaps reading a different reference or something?
> "Appendix A.", paragraph 2
> ```
> Vixie * Tim Wicinski Appendix D. Github Version of This Document While this
> ^^
> ```
> The official na
Wes Hardaker writes:
> > Section 5, paragraph 1
> > ```
> > y Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI
> > 10.17487/R
> >^^^
> > ```
> > Do not mix variants of the same wor
credit we give it, the better :)
Ha, good point.
> in deploying both RFC4470 or NSEC3
>
> This read awkward. Perhaps "in deploying either RFC4470 or NSEC3"
Done
>
> "and the zone resigned." -> "and the full zone needs to be
> resigned.&qu
ISI
Updates: 5155 (if approved) V. Dukhovni
Intended status: Best Current Practice Bloomberg, L.P.
Expires: 13 November 202212 May 2022
--
Wes Hardaker
USC/ISI
___
DN
on! The likely, not-excellent answer is "we
> don't". That is, if you look at similar documents for other protocol
> sets like SIP and IPsec, they were never updated.
Living documents
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
"guidance for" - not sure if anyone else agrees with me,
> but it seems strange to see a BCP document requesting IANA actions
So the IANA action is asking for an EDE code point. I believe this was
also resolved in the IESG teleconference too.
--
Wes Hardaker
USC/ISI
__
201 - 300 of 355 matches
Mail list logo
