[DNSOP]Re: Further comment re algorithm life cycles

[Jim Reid]

> On 19 May 2024, at 18:21, Steve Crocker  wrote:
> 
> No: I don't think the scheme is quite right.
> 
> In my view, an algorithm moves through seven phases during its lifecycle.
> 
> 1. Experimental – defined and included in the IANA registry 
> 2. Adopted – begin inclusion in validation suite
> 3. Available – ok to use for signing
> 4. Mainstream – recommended for signing
> 5. Phaseout  – transition to newer signing algorithm
> 6. Deprecated  – signing should have stopped
> 7. Obsolete  – ok to remove from validation suite

Remarkably similar to the Kubler-Ross model for dealing with grief. :-)

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Re: [DNSOP] [dnsdir] Dnsdir last call review of draft-ietf-dnsop-dnssec-bootstrapping-08

[Jim Reid]

> On 18 Apr 2024, at 15:36, Scott Rose via Datatracker via dnsdir 
>  wrote:
> 
> Reviewer: Scott Rose
> Review result: Ready
> 
> I believe the draft is ready, with a minor typo/nit that don't change the 
> document:
> 
> In Section 5.1 second paragraph has "Signaling Zone" while other instances 
> are "signaling zone”.

Many thanks Scott.

IMO “signalling” would be even better. OED spelling y’see. :-)


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

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-automation-02

[Jim Reid]

> On 18 Mar 2024, at 12:50, David Lawrence via Datatracker  
> wrote:
> 
> Reviewer: David Lawrence
> Review result: On the Right Track
> 
> Early review of draft-ietf-dnsop-dnssec-automation.

Thanks *very* much for such a detailed review Tale. I’m sure the authors will 
appreciate your comments and suggestions.


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

Re: [DNSOP] unrelated name server name recommendation

[Jim Reid]

> On 4 Mar 2024, at 19:14, Paul Wouters  wrote:
> 
> It means every registrant, who doesn’t know about DNS, has to create host 
> objects for glue and whenever the ISP changes nameserver names (eg gets 
> bought, sold or merges), or IP address

Er, no. It’ll be the registant’s registrar who will screw this up - not the 
registrant (who can’t even spell DNS). Besides in most cases, the it’ll be the 
registrar who looks after that delegation info and also provides DNS service 
for the registant’s domain name.

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

Re: [DNSOP] [Ext] About key tags

[Jim Reid]

> On 16 Feb 2024, at 16:17, Paul Hoffman  wrote:
> 
> I keep hoping that this group will focus more on those who go through the 
> effort to sign their zones than those who write the software.

Hmmm. If it wasn’t for those who write the software, there would be nothing for 
those who sign their zones. Both groups deserve equal focus.

Won’t someone think of the DNS camel?

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

Re: [DNSOP] [Ext] About key tags

[Jim Reid]

> On 16 Feb 2024, at 15:19, Joe Abley  wrote:
> 
> Resolvers are routinely managed in order to safeguard local resources, harden 
> themselves against attacks, etc. Not every query gets answered. Seems to me 
> that limiting the time a validating resolver spends churning its organs over 
> a particular RRSIG and causing it to fail to validate if the indigestion gets 
> too bad is just another example of sensible local policy.

True. IMO, that shouldn’t be the only indigestion-avoidance remedy.

> While I think some centralised guidance about how to harden your resolver 
> against this attack (or any attack) is useful (and similarly guidance to 
> avoid duplicate key tags seems like a great idea for signers) I am struggling 
> to see any of this as a problem with the protocol or a fundamental weakness 
> in DNSSEC that needs a "long-term solution".

Guidance to signers is lovely. [I’m sure bad actors will faithfully follow it.] 
Saying “avoid duplicate key tags” is all very well. However it assumes everyone 
plays nice and that’s unlikely to be true. Despite our best efforts, malice and 
incompetence on the Interenet haven’t gone away. So IMO something is also 
needed on the validator side.

Guidance to validators on what to do when they come across duplicate key tags 
would be lovely. A hard fail is a reasonable way to handle these errors. YMMV. 
Don’t chase > N duplicate key tags could also be a reasonable approach. For 
some value of N. It’s just a question on how and when to return a hard error.

I think what’s needed here is something similar to RFC9276’s advice on unwise 
choices of NSEC3PARAM settings. Broadly speaking, it’s the same sort of signer 
and validator problem: signer does some/thing bad which hurts validating 
resolvers. 

RFC9276 says return SERVFAIL for badly chosen NSEC3PARAM values. IMO a BCP 
needs to say the same thing about key tag collisions.

> If a zone's signatures and keys are constructed and published in such a way 
> that it causes indigestion in validators, and as a consequence validators 
> fail to return responses for data in that zone, that's a self-inflicted 
> problem and the zone administrator surely has every incentive to fix the 
> problem. If the tools the zone administrator is using make the problem hard 
> to make, then so much the better.

If validators can also make this problem hard to make, that’s so much the 
better too. That should give signers a strong incentive to fix their 
self-inflicted problem and stop hurting validating resolvers.

> The DNS is filled with misconfigurations and junk. Things get fixed if they 
> need to when things break. Sometimes things break in painful ways and so we 
> make changes to mitigate or avoid the pain. How is this not just another day 
> on the Internet?

Who said it wasn’t? :-)


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

Re: [DNSOP] [Ext] About key tags

[Jim Reid]

> On 16 Feb 2024, at 12:35, Edward Lewis  wrote:
> 
> The potential for abuse does exist, but the potential isn't addressed by 
> documenting "key collisions should not allowed." 

Indeed.

> I do agree that key collisions should be avoided, for the sake of key 
> management, but given the difficulty in avoiding them in all cases, I can't 
> see that a protocol action can be taken to rule them out.  And there will 
> always be non-compliant malicious-intent code available to cause collisions 
> if collisions are indeed desired for abusive reasons.  The solution here is 
> to roll out the notion across implementations that it is acceptable for a 
> validator to fail a data set's DNSSEC validation based on time/computational 
> complexity.

I agree with this too. The latest patches to mitigate the keytrap vulnerability 
are welcome and much appreciated. Though IMO they’re a short-term fix. A 
long-term solution would be implementation guidelines as outlined above or to 
hard-fail validation whenever there’s a key tag collision.

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

Re: [DNSOP] [Ext] About key tags

[Jim Reid]

> On 14 Feb 2024, at 15:17, Paul Hoffman  wrote:
> 
> On Feb 14, 2024, at 07:10, Jim Reid  wrote:
>> That said, I think a minor tweak to the core DNSSEC specs would be a good 
>> idea. For instance, whenever a validator comes across a key tag collision, 
>> it MUST stop validating and either return a hard error or an unvalidated 
>> response.
>> 
>> My concern here is a bad actor using key tag collisions to disrupt important 
>> validating resolver services. For some definition of important.
> 
> That is not a "minor tweak", that will occasionally break validation in 
> hard-to-detect ways.

Could you please elaborate the hard-to-detect ways Paul? Key tag collision is 
an obscure corner case (modulo the current keytrap excitement) and refusing to 
validate in these circumstances seems more than reasonable to me. Fail early, 
fail “safe”. The resolver would presumably log the error and return a suitable 
response to the client.

DNSSEC validation is already far too complex. Let’s not add more. IMO, the 
pragmatic approach here would be for a validator to say “Duplicate key tags 
mean the signer has messed up and I give up. Have a nice day.”.

> The problem is not the collisions, it is the collisions causing almost 
> unbounded processing.

Indeed. So at the earliest opportunity for a validating resolver, nuke that 
from orbit. It’s the only way to be sure. :-)

> A better update would be to say "watch for excessive processing due to keytag 
> collisions and abort when you detect it".

Seems a bit fluffy to me. Define “excessive” and “watch". More code/moving 
parts would be needed to implement this approach too.

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

Re: [DNSOP] [Ext] About key tags

[Jim Reid]

> On 14 Feb 2024, at 14:47, Edward Lewis  wrote:
> 
> I raise the key tag issue in the sense of "let's not do this again" and not 
> to try to change what it is now.  Clearly, changing it (to avoid collisions) 
> would be difficult.  And, given the relative rarity of any problem stemming 
> from it, not worth fixing at this point.  Just don't do it again.

I agree with Ed. [Shock! Horror!] The long tail of DNS implementations means 
retro-fixing this vulnerability will be awkward. Key tag collisions are 
unlikely to cause a major problem. So let’s not repeat this mistake/oversight 
in new protocol work and move on.

That said, I think a minor tweak to the core DNSSEC specs would be a good idea. 
For instance, whenever a validator comes across a key tag collision, it MUST 
stop validating and either return a hard error or an unvalidated response.

My concern here is a bad actor using key tag collisions to disrupt important 
validating resolver services. For some definition of important.

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

Re: [DNSOP] [dnsdir] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01

[Jim Reid]

> On 17 Jan 2024, at 20:42, Matt Brown via Datatracker via dnsdir 
>  wrote:
> 
> Reviewer: Matt Brown
> Review result: Ready
> 
> I have been selected as the DNS Directorate reviewer for this draft.

> The draft itself is clear and understandable. Both the language and the
> substance of the proposal make sense to me.
> 
> Given this previous discussion and clarity of proposal I see no blockers or
> issues for the ADs to consider and recommend this draft is ready to be
> progressed further.

Excellent! Many thanks for your review Matt.

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

Re: [DNSOP] [dnsdir] Dnsdir telechat review of draft-ietf-dnsop-dns-error-reporting-07

[Jim Reid]

> On 10 Dec 2023, at 22:28, James Gannon via Datatracker via dnsdir 
>  wrote:
> 
> I have reviewed 07 against the feedback on both the -04 and -06 and the
> document seems to be in good shape to move forward at this time. Thank you for
> the comprehensive feedback to all the reviewers and god engagement on some of
> the topics.

Many thanks James.

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

Re: [DNSOP] [dnsdir] Dnsdir early review of draft-ietf-dnsop-compact-denial-of-existence-01

[Jim Reid]

> On 29 Nov 2023, at 12:43, Nicolai Leymann via Datatracker via dnsdir 
>  wrote:
> 
> I found no major or minor issues and think the draft is in a good
> shape and can be progressed.

Great stuff Nic! Many thanks.

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

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-dns-error-reporting-06

[Jim Reid]

> On 5 Nov 2023, at 14:04, David Lawrence via Datatracker  
> wrote:
> 
> Hi Roy and Matt, this is my review on behalf of the DNS Directorate.

Many thanks!

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

Re: [DNSOP] Automated delegation management via DDNS

[Jim Reid]

> On 30 Oct 2023, at 13:00, Johan Stenstam 
>  wrote:
> 
> But let’s ensure that we have identified the correct scope of the problem 
> rather than cherry-picking the two simplest cases.

+1

IMO the discussion of this I-D has lost focus. Let’s find it and get back on 
track. :-)

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

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-avoid-fragmentation-15

[Jim Reid]

> On 14 Oct 2023, at 08:41, Vladimír Čunát via Datatracker  
> wrote:
> 
> 
> I've already posted about -15, though not with dnsdir hat.  So, I see nothing
> wrong with the current version. (The complaint about DF=1 in current
> implementations has been addressed.)

Many thanks for the prompt review Vladimir. Sorry this landed on you so soon 
after the datatracker picked you to review draft-ietf-cdni-delegation-acme.

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

[DNSOP] Dnsdir early review of draft-ietf-dnsop-domain-verification-techniques-02

[Jim Reid via Datatracker]

Reviewer: Jim Reid
Review result: Not Ready

Since this I-D was submitted for early dnsdir review, the draft is
essentially a work in progress and much remains to be done.

I doubt this I-D will be a valuable addition to the DNS oeuvre that
merits WG attention. As written, it's a mixture of implementation
guidelines and a survey of current approaches to domain verification
techniques. These might be better as discrete documents on the ISE
track. However the I-D has been adopted by the WG. It's not adding or
changing the core protocol and therefore won't be a burden to the DNS
Camel.

There are quite a few gaps that need to be filled. Which is to be
expoected in early versions of a draft.

There isn't a clear enough problem statement or use case: what
problems does this I-D solve and how does it do that?

The I-D is unclear about the roles and responsibilities commonly found
in today's DNS where the domain name holder is not the controller or
administrator for the domain and neither provides authoritative DNS
service for it. How could/should domain verification work in these
settings?

The doc could be clearer on the semantics of these validation domain
RRs. ie Their presence only proves who had control of the domain when
these RRs were added or removed, not who holds the domain name or is
ultimately responsible for it. This is important, especially when so
many aspects of DNS operations are outsourced these days.

Section 1 describes how domain verification is performed today but
doesn't explain why. Or discuss the strengths and weaknesses of this
approach. Could non DNS-based approaches - some out of band method -
work or not? Are there scenarios where these could be better than
using something stored in the DNS? Or does the DNS-based approach
obliterate these?

A definition for the counterpart of Provider is missing. Client
perhaps?

Several Sections are missing. The I-D jumps directly from Definitions
to Recommendations! The authors need to show their working. In
detail. ;-) This should include details of which approaches were
considered and their advantages and disadvantages. There needs to be
an explanation why TXT records are RECOMMENDED and, by implication,
why other RRTypes are not. CERT records for instance could be a valid
alternative that offer additional security features. Section 3.2
explains (somewhat clunkily) why CNAMEs are unsuitable. But that's
only a small part of the story.

A Section on procedural/process issues is needed: how the Provider and
Client synchronise their updates, how this gets agreed and documented,
when/how validation domain names get added or removed, max/min TTL
values, problem escalation considerations, etc.

The discussion of the TXT record in Section 3.1 is defective. The
validation domain name probably needs to have a unique owner-name as
well as some unique token in the RDATA. There's no explanation or
justification for using a random token with at least 128 bits of
entropy. Why not 256 or 64 (say)? A small number of entropy bits could
be "good enough", for instance when the validation RRtype is
short-lived or only used once. Similar issues arise from mandating
SHA-256. One day that algorithm will be deprecated => updating this
prospective RFC. A "strong" hash algorithm isn't always necessary
either. That's also holds for RFC4086's randomness requirements.
Should the validation domain name include a timestamp to
detect/prevent replay attacks?

If these parameters are to be requirements and/or mandatory to
implement, the rationale for their adoption needs to be given.

Is this part of the I-D documenting one provider's approach? Should it
be defining a generalised, interoperable solution?

The last paragraph of 3.1 is in the wrong place. It belongs in a
section on implementation considerations. Some of the text is
fluffy. What would "offer detailed help pages that are accessible
without needing a login on the provider website" look like in
practice? What content should be in the detailed help pages? The
sentence beginning "Similarly, for clarity," is confusing. Who is
expected to provide the full DNS record? How? And in what format?

The Security Considerations Section needs a lot more work. It should
document the threat model which outlines roles and responsibilities as
well as potential attack vectors and how to mitigate them. These would
include MitM attacks, spoofing, (D)DoS, Client-side or Provider-side
bad actors, poorly chosen TTL values, replay attacks, securing the
Client-Provider channel(s), etc.

Appendix A is an excellent idea and much appreciated. Some of tha
material needs to go elswhere in the document though. A 1.3 and A1.4
should be in the main body of the I-D. It should not be in an appendix
which describes the domain verification techniques used by significant
Providers. The discussion of fragmentation also needs to move from
Appendix A. It should explain that using discrete owner-names for each
val

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt

[Jim Reid]

> On 23 Feb 2023, at 22:36, Ted Lemon  wrote:
> 
> How much DNS traffic is even still inspectable these days?

Depends on the definition of DNS traffic Ted. DNS-OARC has many TB of pcaps and 
query logs from the DITL project. Whether that data could be good enough to 
meaningfully measure the incidence of QDCOUNT>1 in the real world is anyone’s 
guess. I suppose it’ll be difficult (and very subjective) to distinguish 
between “real” QDCOUNT>1 queries and the ones from junk implementations that 
are just part of the DNS’s background noise.

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

Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9

[Jim Reid]

> On 20 Jan 2023, at 15:20, Paul Hoffman  wrote:
> 
> Given the long list of things in this document that ISC has thought about and 
> actively decided not to do, is it a good idea that we call it a "best current 
> practice"?

Maybe. Though a BCP should go beyond documenting what BIND9 does.

In many cases, what BIND9 does is the de facto BCP. However IMO a “real” BCP 
should include insights from other implementations and from operators.

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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-19

[Jim Reid]

> On 14 Dec 2022, at 16:28, Eliot Lear  wrote:
> 
> We're off in the woods again.  Let's keep these two principles in mind:
> 
>   • The DNS resolution mechanisms are not expected to resolve, let alone 
> secure names ending in .ALT.
>   • How other resolution mechanisms secure names is their affair.

If these principles apply, why is the IETF bothering with .alt at all? This 
pseudo-TLD won’t be part of the One True DNS Name Space that uses the One True 
DNS Resolution Mechanism. I fail to understand why it continues to get airtime 
in dnsop. Please make it stop.

Anyways to get back on topic, I do not support this ID. IMO it’s out of scope 
for dnsop or the IETF more generally. If the ID goes ahead, it will open up far 
too many layer-9+ issues and encourage others to abuse IETF processes to get 
around ICANN’s rules for gTLD sales. The IETF and dnsop would be wise to steer 
well away from that. Although I realise that train has kind of left the station 
already because of .onion, I think the WG and the IETF has to minimise the risk 
of getting embroiled in further collateral damage and layer-9+ food fights over 
TLDs.

I still don’t see why a special TLD has to be set aside or needed for these 
alternate name spaces. What can be done with .alt that couldn’t be equally done 
in (say) alt.arpa? The ID says nothing on that issue. Or why alternate name 
spaces that aren’t part of the DNS need to be somehow anchored in the DNS.



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

[DNSOP] Dnsdir telechat review of draft-ietf-dnsop-rfc5933-bis-13

[Jim Reid via Datatracker]

Reviewer: Jim Reid
Review result: Ready

The issues raised in the previous dnsdir reviews about the content of the I-D
have been addressed.

The meta-issue about an Informational RFC updating a Standards Track RFC still
exists, though this remains out of scope for the I-D and dnsdir.

I have no opinion on whether the I-D should proceed on the ISE or IETF stream.


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Jim Reid]

> On 20 Oct 2022, at 13:01, Eliot Lear  wrote:
> 
> ducking that says that when the IETF faces tough problems, others must step 
> in.

IMO, it doesn’t say that at all Eliot. A fairer PoV here would be when the IETF 
gets handed non-IETF problems, it keeps well away (perhaps after a discussion 
of the merits and/or scope of that problem).

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

Re: [DNSOP] Possible alt-tld last call?

[Jim Reid]

> On 17 Oct 2022, at 15:12, Joe Abley  wrote:
> 
> Since it's not clear, my favoured approach to this entire subject is to do 
> whatever is the quickest way to resolve the conversation so that this working 
> group can get on with work that, in my opinion, no disrespect intended, is 
> less pointless. I do not believe this proposal does any harm, since I think 
> it will have a practical effect that is the same as doing nothing at all.

I agree with Joe. The WG’s spent too much time on this issue. It has been 
unable to make useful progress. The prospects of reaching an approximation of 
rough consensus are no closer than they were when this was first discussed. I 
think it’s time for the WG to declare defeat and give up.

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

Re: [DNSOP] Possible alt-tld last call?

[Jim Reid]

> On 17 Oct 2022, at 13:00, Independent Submissions Editor (Eliot Lear) 
>  wrote:
> 
> I don't want to adjudicate names, but I have no problem adjudicating naming 
> systems, including transparent attempts to get vanity names.  Since none of 
> those are naming systems, they would all get the official "bubye".

Eliot, I have no doubt you’d always do The Right Thing here. That might not be 
the case for the next ISE. Or the one after. Or... Besides, decisions that 
depend on subjective judgements, no matter how clueful, are likely to cause 
inconsistencies and controversy. That’s best avoided IMO - more so for 
something as icky as ad-hoc TLDs. 

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

[DNSOP] Dnsdir last call review of draft-ietf-dnsop-rfc5933-bis-10

[Jim Reid via Datatracker]

Reviewer: Jim Reid
Review result: Ready with Nits

The I-D is a no brainer. It requests a code point for a new crypto algorithm
for Secure DNS and deprecates one for an algorithm that has been obsoleted.

Some language nits.

1) The text in 4.1 "algorithm number 23 is used here as an example..." should
be moved to earlier in the document, before any of the examples are shown.

2) In 2.2 "in the private key file, it must be in one line" should be deleted.

3) The text at the start of 3.1 does not scan well and is confusing. The
private key shown in the ID does not consist of an MX record.


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

Re: [DNSOP] draft-hardaker-dnsop-must-not-sha1

[Jim Reid]

> On 14 Aug 2022, at 04:55, Wes Hardaker  wrote:
> 
> Something like:
> 
> # Deprecating SHA-1 algorithms in DNSSEC
> 
> The SHA-1 {{RFC3685}} algorithm MUST NOT be used when creating DS records.
> Validating resolvers MUST treat DS records as insecure.  If no other DS
> records of accepted cryptographic algorithms are available, the DNS
> records below the delegation point MUST be treated as insecure.
> 
> The RSASHA1 {{RFC4034}}, DSA-NSEC3-SHA1 {{RFC5155}}, and
> RSASHA1-NSEC3-SHA1 {{RFC5155}} algorithms MUST NOT be used when
> creating DNSKEY and RRSIG records.  Validating resolvers MUST treat
> RRSIG records created from DNSKEY records using these algorithms as
> insecure.  If no other RRSIG records of accepted cryptographic
> algorithms are available, the validating resolver MUST consider the
> associated resource records as Bogus.

Works for me Wes. Though we could lose the last sentence IMO because the 
preceding one already says how SHA1 flavoured RRtypes should be treated.

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

Re: [DNSOP] draft-hardaker-dnsop-must-not-sha1

[Jim Reid]

> On 13 Aug 2022, at 13:48, Mark Andrews  wrote:
> 
> So you are ready to replace SHA1 in NSEC3 and do a second algorithm renumber 
> which is what is required to actually get rid of SHA1 or do you mean retire 
> RSA-SHA1.

Neither. I said the I-D needs to say something about not using crypto reliant 
on SHA1 for either signing or validation. That doesn't have to mean the code 
points for RSA-SHA1 (or whatever) have to go away. They could/should remain in 
the IANA register alongside a note saying "don't use these", like we eventually 
did with RSA-MD5. If "don't use SHA1 ever" means changes for NSEC3 are needed, 
so be it. If we agree on "don't use SHA1, except for *NSEC3-SHA1" that might be 
OK. Though that may need further thought and analysis if SHA1 hash collisions 
pose a real threat to the integrity of NSEC3.

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

[DNSOP] draft-hardaker-dnsop-must-not-sha1

[Jim Reid]

Wes, I'm all for killing SHA1. Though the mechanism might need a rethink. We 
probably should have a simpler way to add/remove DNSSEC crypto algorithms. IIRC 
Paul Hoffman explained the problem a year or so ago when new code points were 
needed for the latest GOST algorithms: something about that could only be done 
with the overkill of a Standards Track RFC. Maybe that could get fixed and SHA1 
could be its first victim?

As for the I-D, I think it should also say validating resolvers MUST NOT use 
SHA1-flavoured RRtypes for validation. ie Give SHA1 two shots to the head, just 
to be sure. :-)

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

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[Jim Reid]

> On 8 Aug 2022, at 11:16, Independent Submissions Editor (Eliot Lear) 
>  wrote:
> 
> I caution against those approaches that would set such a high bar that they 
> would require researchers to fork out hundreds of thousands of dollars on 
> application fees alone plus who knows how much else for, as someone else 
> wrote, an uncertain outcome.  They'll simply go elsewhere. That in itself 
> would encourage squatting (or whatever you want to call it).  The benefits of 
> avoiding squatting accrue not only to those researchers, but to those who use 
> their technology, and others as well.

These are valid points Eliot and I agree with them - at least in principle. 
However the opposite PoV is equally valid IMO. Those who can’t/won’t go to 
ICANN to get their new TLD shouldn’t come to the IETF to get around ICANN’s 
policies. [Not that I’m suggesting this is what the GNS draft’s authors are 
doing.] IMO it’s the start of a very slippery slope if the IETF accommodates 
ad-hoc requests for “special” TLDs that are probably for ICANN to decide. 
Resolving those mutually exclsuive positions is why you get the big bucks 
Eliot, isn’t it? :-)

I suppose the question that needs to be asked is why on technical/engineering 
grounds MUST some new name space require a new TLD and why can’t that new name 
space be anchored elsewhere in the public DNS? OK, that’s two questions.

Perhaps we’re over-thinking this. Putting these magic strings into the root is 
a problem for both IETF and ICANN policies. So let’s not do that.

How about having an IANA registry of these experimental TLDs? Those strings 
don’t go in the root. And they don't get added to the IETF’s special use list 
and ICANN is still free to create these TLDs if/when they decide to create 
more. This hypothetical IANA registry would primarily be to avoid name 
collisions between those who are experimenting with new name spaces or running 
stuff inside them. For bonus points, entries in that registry have to be 
supported by (say) an Informational RFC. Those registry entries could also come 
with a health warning: if ICANN or the IETF one day creates your TLD for real, 
you’re out of luck.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] DNSSEC as a Best Current Practice

[Jim Reid]

> On 11 Apr 2022, at 14:01, Masataka Ohta  
> wrote:
> 
> I can't see any as discussion is still ongoing.

There is no discussion, just you arguing with yourself. Please stop.

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Jim Reid]

> On 21 Mar 2022, at 14:36, Masataka Ohta  
> wrote:
> 
> How can you say I must provide some draft for some protocol by
> myself even though an alternative of DNS cookie already is an rfc?

Modulo the IETF's code of conduct, I can say whatever I like - as can you or 
anyone else.

If you're saying DNS cookies are the answer, there's nothing more to say on 
this thread. Goodbye.

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Jim Reid]

> On 21 Mar 2022, at 14:12, Masataka Ohta  
> wrote:
> 
> No implementation or code is necessary to say DNSSEC is
> fundamentally hopeless.

That might or might not be true. But where's your draft and code for an 
alternative?

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

Re: [DNSOP] IANA Policy for SVCB

[Jim Reid]

> On 21 Mar 2022, at 09:19, Ben Schwartz  
> wrote:
> 
> Personally, I favor #3.  What do you think?
 
Ben, I think 2 (Expert Review) is the right approach. This would hopefully 
ensure any specifications are complete/valid and raise the threshold to 
discourage bad or frivolous SrvParamValues "registrations".

An Expert Review seems right to me. It's culturally compatible with how we 
handle the allocation of new RRtypes. 

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

Re: [DNSOP] How Slack didn't turn on DNSSEC

[Jim Reid]

> On 1 Dec 2021, at 18:49, Andrew Sullivan  wrote:
> 
> Wouldn't that create a vicious circle in which the only way to start 
> operating DNSSEC is already to have operated DNSSEC?

I think we’ve been in that vicious circle (or downward spiral) for several 
years now.

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

Re: [DNSOP] Draft-ietf-dnsop-private-use-tld and the ISO

[Jim Reid]

> On 27 Jul 2021, at 01:56, Donald Eastlake  wrote:
> 
> Looks like initial query from IAB to ISO is
> https://datatracker.ietf.org/liaison/1720/
> 
> Maybe I'm blind but I don't see a response...

It can take a day or so for inbound Liaison Statements from other SDOs to make 
their way to the datatracker. It can take a *lot* longer than that for an SDO 
to send a response. I think ISO is one of the organisations where a reply 
depends on how frequently the appropriate committee or whatever meets.

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

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

[Jim Reid]

> On 28 Apr 2021, at 13:24, Roy Arends  wrote:
> 
> The working group can (after a potential clarification from the ISO about the 
> future status of code elements) decide if a subset suffices and if so, the 
> composition of the subset.

I agree with this approach.

IMO it’s reasonable for the WG to produce an RFC which says “If you need a TLD 
for private use, pick from the two letter codes that ISO 3166 MA says they’ll 
never allocate. Bear in mind if they later change their mind, you’ll be on your 
own and could well be in a world of pain. Have a nice day.”.

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

Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation

[Jim Reid]

On 19 Mar 2021, at 02:42, Viktor Dukhovni  wrote:
> 
> On Mon, Mar 15, 2021 at 05:38:40PM +0000, Jim Reid wrote:
> 
>> Measuring the MTU to well-known locations on the Internet won’t be
>> appropriate for some use cases. For instance inside private nets that
>> aren’t connected to the Internet or for forwarding-only servers that
>> never query an authoritatve server.
> 
> Right, the forwarding-mostly (or only) servers should just measure the
> PMTU to the relevant upstream(s).

The current draft says nothing about this. I’m suggesting it should.

>> IMO it’s a bad idea to recommend specific servers that could be the
>> target for those PMTU probes. [Suppose those names change one day -
>> unlikely for the above but you never know.] That could become a vector
>> of (D)DoS attacks - probably not on the above name servers themselves
>> but on the access routers in front of them that might well be
>> rate-limiting ICMP packets.
> 
> I don't see the DDoS, such measurements should be rather infrequent, in
> particular, I don't see why these would be much more frequent than root
> zone priming queries, which full service resolvers do routinely at
> startup.

The PMTU probing rate could well end up being broadly similar to the rate of 
priming queries to the root. However those priming queries are almost certainly 
not going to result in ICMP responses. Which usually take a different code path 
through routers and get rate-limited. Which means PMTU probing could be a 
vector for (D)DoS attacks: not on the well-known authoriatative name servers 
but the access routers and firewalls in front of them.

>> This could get nasty with icky CPE
>> firmware: imagine every home router in (say) Comcast’s net doing PMTU
>> to the same root server.
> 
> These would generally not all boot up at the same time, and would be
> expected to be configured in forward-only mode to the relevant Comcast
> iterators.

It’s unwise to make these assumptions. Besides, Comcast’s net and CPE 
configuration isn’t the only game in town.

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

Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation

[Jim Reid]

> On 15 Mar 2021, at 04:16, fujiw...@jprs.co.jp wrote:
> 
> Dear DNSOP participants,
> 
> Thanks very much for good comments for draft-ietf-dnsop-avoid-fragmentation.
> 
> These are my proposal of Section 3.3.  Default Maximum DNS/UDP payload size.
> 
> I'm not sure what to do with "MAY, "SHOULD", or "MUST",
> so please give us your opinion.

Fujiwara-san, “resolvers MAY use PMTU” is probably right. A SHOULD or a MUST 
seems too strong: for instance when the resolver already has a priori knowledge 
of the MTU or that’s somehow hard-wired into the link-layer technology 
end-to-end.

>   However, operators of DNS servers SHOULD measure their path MTU to
>   well-known locations on the Internet, such as [a-m].root-servers.net
>   or [a-m].gtld-servers.net at setting up the servers.

I think it would be better to replace this with “Operators of DNS servers MAY 
measure their path MTU.”.

Measuring the MTU to well-known locations on the Internet won’t be appropriate 
for some use cases. For instance inside private nets that aren’t connected to 
the Internet or for forwarding-only servers that never query an authoritatve 
server.

IMO it’s a bad idea to recommend specific servers that could be the target for 
those PMTU probes. [Suppose those names change one day - unlikely for the above 
but you never know.] That could become a vector of (D)DoS attacks - probably 
not on the above name servers themselves but on the access routers in front of 
them that might well be rate-limiting ICMP packets. This could get nasty with 
icky CPE firmware: imagine every home router in (say) Comcast’s net doing PMTU 
to the same root server. Besides, is the PMTU to a root or .com server, going 
to be the same as that for the example.whatever name servers?

If PMTU is to be used, maybe it needs to be applied to all authoritative name 
servers a resolver queries? And maybe these will need to be re-probed from time 
to time, just like how resolving servers continually monitor RTTs to 
authoritative servers. PMTUs might well change when the links and routes change.

I think it would also be helpful to discuss some of the trade-offs of using 
PMTU for DNS resolution. Some of these are mentioned in RFC8899. I’m sure PMTU 
will unquestionably be the right thing to do in some settings. But in others, 
it could cause more operational trouble than fragmented DNS packets: increased 
latency for example. It would be great if the ID helped developers and 
operators to make informed choices on when to use or not use PMTU.


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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-iana-cons-00.txt

[Jim Reid]

> On 11 Mar 2021, at 15:38, Paul Hoffman  wrote:
> 
> The size of the namespace isn't all that relevant in that, for any namespace, 
> if it is filling up "too fast", one can quickly change the requirements to be 
> more stringent. I'm pretty sure that has happened in the thousands of IANA 
> registries, but the last time I checked, it happened "very, very rarely".

I agree with Paul. We’ve burnt through < 20 code points since DNSSEC was 
invented ~20 years ago. At that rate, code point exhaustion could well be a 
problem for our great-great-great-great-grandchildren. I think we can safely 
kick that can down the road for a century or two.



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] signalling mandatory DNSSEC in the parent zone

[Jim Reid]

> On 1 Mar 2021, at 13:29, Ulrich Wisser  
> wrote:
> 
> 100% signed would mean unsigned zones do not get delegated, going insecure is 
> no longer an option.
> I would like the protocol to be able to handle that case. 

Ulrich, that seems to be a (registry-specific?) policy matter => probably out 
of scope for the DNS protocol.

How could a parent signal “everything below this point of the tree is signed”? 
How could they guarantee that was true, given delegation means there’s a change 
of control for some part of the name space? How would resolving servers be 
expected to use this signalling information? If they come across an unsigned 
but working delegation, should they treat that as a validation failure or 
continue to resolve the query? That would seem to be a local 
policy/configuration matter too.

I’m not sure it matters to anyone if some parent zone has this sort of policy 
or not. Could you explain the use case or problem statement?

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

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Jim Reid]

> On 6 Jan 2021, at 20:48, Ben Schwartz  
> wrote:
> 
>> > Telling validators to "insist" that all signatures are valid would resolve 
>> > this dilemma.  Zone owners could add algorithms without weakening anything.
>> 
>> How do you deploy a new signing algorithm alongside an established one 
>> without going dark to users using validators that don't support it, in that 
>> case?
>> 
> To clarify, I meant "all signatures under algorithms that are implemented by 
> the validator", i.e. "check everything you can".

??? Are you saying validators should check every RRSIG for each algorithm that 
they support even after they’ve found one of these RRSIGs that validated?


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

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Jim Reid]

> On 4 Jan 2021, at 16:18, Paul Wouters  wrote:
> 
> You want to see a Status column at the IANA registry for marking
> something "NOT RECOMMENDED" / "DEPRECATED" etc ?

Yes!

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

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Jim Reid]

> On 4 Jan 2021, at 15:27, Stephen Farrell  wrote:
> 
> On 04/01/2021 14:23, Paul Wouters wrote:
>> On Mon, 4 Jan 2021, Stephen Farrell wrote:
>>> WRT GOST, we're not really talking about an algorithm but
>>> rather a national crypto standards scheme that selects sets
>>> of algorithms. For such things, whether from Russia or the
>>> US or anywhere, I think it's quite fair to ask "how has
>>> version N deployment gone?"
>> Why is that fair? 
> 
> Eh? Seems to me that asking about the facts is fair.

It’s a bit odd to be asking about fairness now. [Better late than never I 
suppose.] IIRC nobody asked about usage when typecodes got issued for DNSSEC 
algorithms - until now. It was just assumed, perhaps wrongly, they would be 
used.

However I think you’re conflating two different things Stephen. This I-D is a 
sensible and pragmatic solution to a real problem. Mandating a standards-track 
RFC to get a new DNSSEC type code is unreasonable. [Dare I say unfair? :-)] So 
let’s fix that.

The question of whether a new DNSSEC crypto algorithm will get used/supported 
or not can be discussed as and when there’s an I-D proposing to adopt one. And 
of course there’s a meta-discussion to be had about how/where that discussion 
takes place. IMO some sort of lightweight expert review process like the one 
used for RR typecode allocation seems appropriate. It doesn’t necessarily 
follow that writing up such an (Informational?) RFC guarantees an IANA type 
code allocation. YMMV.

BTW, does anyone ask usage questions before typecodes get allocated for 
algorithms/modes used in TLS crypto?

I suport WG adoption of draft-hoffman-dnssec-iana-cons and am willing to review 
it. Maybe there needs to be another I-D to document the process for adding and 
deprecating DNSSEC type codes?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Authoritative servers announcing capabilities

[Jim Reid]

> On 14 Sep 2020, at 17:07, Paul Hoffman  wrote:
> 
> On Sep 14, 2020, at 2:33 AM, Peter van Dijk  
> wrote:
>> In general, this document appears to suffer from a disconnect between 
>> 'information published by an auth about itself' and 'information published 
>> in a zone'.
> 
> You and others here are completely correct about this, and it is definitely 
> something that needs to be resolved before this idea moves forward.

I think more clarity is needed on what problem this draft solves. Is it to help 
resolving servers select the authoritative server to query? How are resolving 
servers expected/required to use this information? Publishing this sort of info 
as a JSON blob or whatever purely for informational purposes seems fine. I’m 
not so sure it’s a good idea if it will complicate resolver behaviour or leads 
to operational difficulties: eg send all queries to the only name server for 
some zone (on the other side of the planet) which does/doesn’t do (say) ECS.

Could this I-D lead on to something ickier, like stub resolvers signalling to 
resolving servers that they want their queries to be resolved with/without 
QNAME minimisation, ECS, some flavour of encrypted transport, etc, etc?

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

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Jim Reid]

> On 18 Jun 2020, at 16:01, Joe Abley  wrote:
> 
> On Jun 18, 2020, at 16:48, Paul Hoffman  wrote:
> 
>> Why is this WG considering making this document Standards Track instead of 
>> Informational? Also, why is the WG considering putting the document in our 
>> work stream at all? Can the WG can bring much value to the document itself? 
>> We do have lots of other things we are working on.
> 
> I think the question of the value the wg can bring is the important one.

I think we’re over-thinking this. Just issue new code point(s) for the new 
algorithm(s) and be done with it.

IMO there’s no need for the WG or the IETF to make any statements about the 
suitability of the underlying crypto used for optional signing and validation. 
That’s largely a matter for those who use these algorithms. Higher-level 
concerns about the crypto’s suitability should only come into play whenever an 
algorithm is a MUST/SHOULD recommendation in a standards-track RFC.

Maybe we need an RFC6895-like process for maintaining this IANA registry, like 
we have for RRtype codes?


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

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Jim Reid]

> On 18 Jun 2020, at 16:30, Paul Hoffman  wrote:
> 
> It might be better, and faster, for this WG to adopt a one-paragraph draft 
> that makes the DS registry "RFC required", like the other DNSSEC-related 
> registries.

+1



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Jim Reid]

> On 16 Jun 2020, at 15:51, Mats Dufberg  
> wrote:
> 
> I support the adoption and I am willing to review the document.

Me too!

I wish everyone else commenting on this thread just indicated if they supported 
adoption (or not).

Too much of the discussion that’s taking place at the moment seems to be about 
the content or metaissues around the I-D. That's premature IMO and should wait 
until the WG has decided to adopt the document. Or at the very least, the 
discussion should be taking place on another thread. And FWIW, the fact there’s 
been so much discussion suggests the WG should adopt the I-D.

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

Re: [DNSOP] data at delegation points

[Jim Reid]

> On 14 Apr 2020, at 16:43, Paul Vixie  wrote:
> 
> so instead of example.com DS, it should have been example._dnssec.com DS.

Sadly, that wouldn’t work for 
thisisaveryveryveryveryveryveryveryveryveryveryveryveryverylong.domain.name

Which really exists. :-)




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

Re: [DNSOP] on private use TLDS

[Jim Reid]

> On 26 Nov 2019, at 10:18, Roy Arends  wrote:
> 
> "Is it safe to use ISO3166-1 Alpha-2 code elements from the User Assigned 
> range as top level domains for my own private use?"
> 
> ...
> It is my understanding that the ISO3166 Maintenance Agency can not re-assign 
> codes from the User Assigned range. This needs an action from ISO TC46. 

It would be prudent to assume that there is a possibility, no matter how 
remote, that codes from the User Assigned range could get re-assigned one day. 
Whoever made the current policy could well change it.*

So if your idea goes forward, I think there needs to be some text which 
explains this. ie User Assigned 3166 codes *might* be OK for private use today; 
that list of code points is subject to change even if that's highly unlikely; 
plan accordingly just in case your private use two-letter code gets repurposed.

* I read documents in the late 90s, albeit not from SDOs, telling companies to 
anchor their internal name space under .corp because it was impossible for that 
TLD to ever exist in the public Internet. This was before ICANN was formed.

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

Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter

[Jim Reid]

> On 1 Aug 2019, at 18:04, Paul Wouters  wrote:
> 
> In favour of adoption. Simple, short and clear document. 

+1

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

Re: [DNSOP] [Doh] [Add] [dns-privacy] Do53 vs DoT vs DoH Page Load Performance Study at ANRW

[Jim Reid]

> On 22 Jul 2019, at 21:52, Paul Vixie  wrote:
> 
> apparently ECS creates problems for privacy, but _how could we have 
> suspected_?

IIRC the ECS privacy issues were recognised at the time. They lost out to the 
argument that CDNs were already doing (or about to do) ECS and it would be 
better (for some definition of better) if this was done in a way that had an 
RFC behind it.

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

Re: [DNSOP] Proposal: Whois over DNS

[Jim Reid]

> On 10 Jul 2019, at 14:24, Philip Homburg  wrote:
> 
> As far as I know, there is no issue with whois and the GDRP when it comes
> to voluntarily publishing information in whois.

Nope. It’s OK for you to publish your Personal Data. For anything else, you 
need to get informed consent first. And be able to prove that. And give the 
Data Subjects the ability to modify those data or get them deleted.

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

[DNSOP] dictionary of registration data elements

[Jim Reid]

> On 9 Jul 2019, at 17:26, Steve Crocker  wrote:
> 
> I would strongly support an effort within the IETF to create and maintain a 
> dictionary of registration data elements.  This would probably be in the form 
> of an IANA-maintained registry, with oversight from DNSOP.

Hmmm. That might be a better fit for regext where the EPP people gather since 
those data elements are more likely to figure in EPP transactions than in DNS 
traffic. I’m not sure dnsop is a suitable place to discuss stuff that goes in 
domain name registry databased and whois servers.

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

Re: [DNSOP] Proposal: Whois over DNS

[Jim Reid]

On 9 Jul 2019, at 17:43, John Bambenek 
 wrote:
> 
> I guess I'm not understanding the risks of people accidentally disclosing 
> what they don't intend to.

I suggest you learn more about GDPR. The penalties for non-compliance can hurt 
- up to 4% of global turnover.

Some CIOs are learning this the hard way. British Airways got fined $200M+ 
yesterday and Marriott’s been hit by a $100M+ fine today, both for data 
breaches which involved due diligence failures covered by GDPR.

Anyone proposing policies or protocols that involve Personal Data really need 
to take account of the GDPR implications of their proposals and the likely 
impact on those who will be affected.

Hey, what’s this got to do with dnsop? :-)

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

Re: [DNSOP] Proposal: Whois over DNS

[Jim Reid]

> John Bambenek  wrote:
> 
> > Why? GDPR applies to IP addresses that, doesn't impact DNS yet.

GDPR applies to *any* data which identifies a living European citizen.

If you think it only applies to IP addresses you are very badly mistaken. GDPR 
will also apply to anything in the DNS which happens to identify a living 
European citizen.

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

Re: [DNSOP] Proposal: Whois over DNS

[Jim Reid]

> On 9 Jul 2019, at 15:50, John Bambenek 
>  wrote:
> 
> I'm not married to any name, I chose WHOIS for historical reasons. We can 
> call it _hamsandwich if it builds consensus.

The concern here isn't what the label is called. Prepending a label won't work 
with absurdly long domain names because the maximum length of a domain name 
will be exceeded. That gives bad actors another way of not complying. Not that 
they would ever provide accurate contact data anyway.
 

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

Re: [DNSOP] Proposal: Whois over DNS

[Jim Reid]

> On 9 Jul 2019, at 15:15, Bjarni Rúnar Einarsson  wrote:
> 
> I think having a technical specification like this would be quite interesting 
> from the point of view of automatically updates to existing Whois databases, 
> without requiring the registrant directly (or indirectly) interact with 
> complex APIs or provider-specific web interfaces.

Interesting in the sense that novichok is interesting? :-)

DNS and whois are very different protocols which get used and abused for very 
different things. I'm struggling to understand why they should be coupled like 
this or what problem(s) would get solved by doing that.





signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Proposal: Whois over DNS

[Jim Reid]

On 8 Jul 2019, at 22:38, John Bambenek 
 wrote:
> 
> In response to ICANN essentially removing most of the fields in WHOIS for 
> domain records, Richard Porter and myself created a draft of an 
> implementation putting these records into DNS TXT records. It would require 
> self-disclosure which mitigates the sticky issues of GDPR et al. Would love 
> to get feedback. 

I think this is a spectacularly bad idea.

1. The intractable policy problems around whois won't/can't be solved by moving 
them from port 43 to port 53.

2. These policy problems are out of scope for the IETF. It deals with technical 
and operational matters around protocol design and deployment. Policy issues 
are handled in other fora - like ICANN. The IETF should keep well away from the 
whois policy swamp. The wrangling over whois policy at ICANN has gone on and on 
for 20+ years. It shows no sign of reaching a consensus. Dragging the IETF in 
to that screamfest is not going to improve matters.

3. Your proposal doesn't mitigate GDPR issues. At best it'll just move the 
goalposts. The roles of Data Controller/Processor/Subject won't necessarily fit 
with the roles that update, manage and publish DNS data.

If I outsource my DNS to $registrar and/or $dnshoster, one or other of them 
might (or might not) be the Data Controller. Or it might (or might not) be me. 
The same does for the Data Processor role. So who'd be on the hook for GDPR 
compliance?

DNS providers who are largely untroubled by GDPR today could be obliged to 
register because your proposal would mean they'd be publishing and processing 
Personal Data. As things stand currently, it's already clear who has those 
responsibilities - the registry that provides the whois server. In your 
proposal, it's not so obvious. And when I am the Data Controller, I will 
probably need to get consent to publish Personal Data in the DNS (or anywhere 
else) for an admin or tech or whatever contact who isn't me. Why should I be 
expected to bother with that hassle?

4. It's unwise to use TXT records in this way. Pick another RRtype. TXT records 
are already overloaded and used for all sorts of things. What if someone's 
already got a TXT record with RDATA that begins with (say) "aname="? It's also 
a bad idea to require a specific subdomain for these RRs. How will this work 
for a domain name that's too long to accommodate an additional _whois label? 
And where would the contact data for _whois.example.com get stored? That 
doesn't necessarily have the same contact data as its parent.


BTW, whois was originally intended to provide a way to publish out-of-band 
contact data so the domain holder could be contacted whenever their DNS or 
email was broken. Putting this info in the DNS would defeat that.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Jim Reid]

> On 2 Jul 2019, at 19:12, Matthijs Mekking  wrote:
> 
> I think it is time to move the protocol to Historic status as a clear signal 
> to
> everyone that it should no longer be implemented or deployed.

Agreed. Kill it with fire!

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

Re: [DNSOP] Verifying TLD operator authorisation

[Jim Reid]

> On 18 Jun 2019, at 14:56, Shane Kerr  wrote:
> 
>> Being able to control a zone’s SOA record (or whatever) means just that. No 
>> more, no less. It doesn’t mean someone who has that ability also has the 
>> authority to change the zone’s delegation even though they can manipulate 
>> the zone contents.
> 
> You're basically arguing against ACME-style authentication.

Shane, I’m not doing that. At least I don’t think so.

ACME-style authentication is a very good thing, provided its limitations are 
understood. Using that to demonstrate ownership or control of some zone is not 
unreasonable. However using ACME-style authentication in that way doesn’t 
necessarily prove someone has the authority to change the delegation of that 
zone - more so when the zone is a TLD. All I’m saying here is it’s unwise to 
make that assumption or build a TLD delegation validation mechanism around it.

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

Re: [DNSOP] Verifying TLD operator authorisation

[Jim Reid]

> On 18 Jun 2019, at 11:13, Bjarni Rúnar Einarsson  wrote:
> 
> The SOA record for a TLD contains two DNS names which should be
> under the control of the NIC ...
> People on this list can probably comment on whether my above
> assumption is correct, and whether those are good candidates for
> what you have in mind.

Being able to control a zone’s SOA record (or whatever) means just that. No 
more, no less. It doesn’t mean someone who has that ability also has the 
authority to change the zone’s delegation even though they can manipulate the 
zone contents.

Consider a registry that outsources authoritative DNS service. For instance one 
of the slave servers for .is could mess about with their copy of the zone file. 
[Admittedly breaking DNSSEC validation unless they also had access to the 
appropriate private key.] Modifying the SOA record doesn’t give that 
misbehaving slave provider authority to go to IANA and get the .is delegation 
changed even if they can make the SOA record or whatever “look right” in 
support of their bogus change request.

2FA on changes to TLD delegations is a good thing. However I doubt this can be 
done safely through a mechanism that relies on a magic token being present or 
absent from the TLD itself. That approach changes the threat model and 
introduces new attack vectors. These need careful consideration and testing. 
DNSSEC signing helps of course but isn’t necessarily a magic bullet: suppose 
the registry has also outsourced TLD signing.


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Verifying TLD operator authorisation

[Jim Reid]

> On 14 Jun 2019, at 14:13, Dr Eberhard W Lisse  wrote:
> 
> Would (GPG encrypted) email to the registered address to the authority
> not be sufficient?  That would make sure the recipient is authorized and
> must then cause the token to be 'delegated' as the second factor.

If there was a secure* channel between the TLD registry and IANA like the GPG 
email you suggested, there wouldn’t really be a need to insert and check for 
some token in the TLD zone. Though as you say, that measure might be a useful 
way of adding 2FA.

* For some definition of secure.

In any case, I’m not sure this list is the right place to define or develop a 
solution for this issue. We probably don’t have a complete understanding of the 
problem space or the details of how IANA and TLD registries/SOs communicate 
with each other, what the requirements are, etc, etc.

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

Re: [DNSOP] Verifying TLD operator authorisation

[Jim Reid]

> On 14 Jun 2019, at 03:18, Nick Johnson  
> wrote:
> 
> I'm working on a system that needs to authenticate a TLD owner/operator in 
> order to take specific actions. We had intended to handle this by requiring 
> them to publish a token in a TXT record

This assumes someone who is able to update the TLD has the authority or ability 
to change the TLD’s delegation. That’s not necessarily true. Think of 
registries who outsource their registry operations and/or DNS service to third 
parties. Such third parties might well be able to edit the zone file (or 
whatever) but that doesn’t necessarily mean the registry authorised or 
requested those changes.

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

Re: [DNSOP] Deprecating the status opcode

[Jim Reid]

> On 15 May 2019, at 12:55, Shane Kerr  wrote:
> 
> This seems like the most non-controversial document ever in the history of 
> documents.

A non-controversial DNS doc at the IETF? That’ll be a first. :-)

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

Re: [DNSOP] [Ext] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt

[Jim Reid]

> On 13 May 2019, at 09:22, Joe Abley  wrote:
> 
> I would prefer documented agreement about what is obsolete and what is not.

+1

Though a definition of what is meant by obsolete might be needed too: "no 
longer seen in the wild but could still be alive in closed environments", 
"deader than Elvis", "implementers MUST completely ignore this", "implementers 
SHOULD now treat this as an unknown RRype", etc.

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

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt

[Jim Reid]

On 13 May 2019, at 05:06, Ondřej Surý  wrote:
> 
> But I do have a question for the WG - should we add a text that would allow 
> the “Expert Review” to formally DEPRECATE (as defined in this I-D) other 
> RRTYPEs?

I'm not sure an expert reviewer could or should be in a position to make that 
determination Ondřej. They could probably put dead/dying RRtypes on a list that 
says something like "These RRtypes will be deprecated in N months time. Scream 
now if you disagree.". If nobody screams after a reasonable notice period, the 
RRtype(s) can then be killed. If there are complaints, we'd know if the 
RRtype(s) are still in use and/or if that use remains valid.

> This would make things much simpler in the future when we want to formally 
> cleanup more obsoleted records (like NINFO and RKEY, etc...).

NINFO and RKEY were specifically created for use in .tel. If they are used 
there -- I don't know or care -- they should mainly be seen by the 
Telnic-controlled name servers and apps that use .tel domain names. [Unless 
Telnic's T have changed, registrants can't delegate these names to arbitrary 
name servers.] Someone would need to contact Telnic to find out how often these 
RRypes are found or looked up. They're the only ones who could say for sure if 
the RRtypes are obsolete or not. An expert reviewer probably wouldn't know that 
unless they asked.

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

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Jim Reid]

> On 21 Mar 2019, at 22:29, Brian Dickson  wrote:
> 
>> On Thu, Mar 21, 2019 at 3:03 PM Jacques Latour  
>> wrote:
>> Plus! 
>> Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC?  So 
>> the local resolver and apps and browsers can go the _appropriate_ name 
>> resolution resource(s) using the protocol of choice. That would be much 
>> simpler for default configuration in enterprise and ISP.
> 
> I think that is a good starting place for the side meeting discussion.

Nope.

It could be a topic for *another* side meeting. But not the one that’s under 
consideration here. That side discussion is supposed to be about the contents 
of draft-reid-doh-operator, draft-livingood-doh-implementation-risks-issues and 
maybe draft-bertola-bcp-doh-clients. And what to do about those drafts.

I’m not so sure a side meeting on DHCP/SLAAC for DoT/DoH discovery is needed -- 
at least, not yet -- because there is a live discovery draft and work item 
already in progress in the DoH WG. That would seem to be the most appropriate 
place to first raise those issues.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Jim Reid]

> On 12 Mar 2019, at 16:01, Stephane Bortzmeyer  wrote:
> 
> I still do not understand why people have a problem with DoH whch did
> not already exist before with my-own-name-resolution-protocol-over-HTTPS.

It’s a question of scale/ubiquity. These “alterate” resolution tricks have up 
until now been mostly confined to a small number of clueful people. That is 
going to change dramatically once the world’s web browsers and other web-based 
apps start using DoH. More so if those platforms have DoH enabled by default.

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

Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Jim Reid]

> On 12 Mar 2019, at 15:49, Stephane Bortzmeyer  wrote:
> 
> the case of a commercial
> Internet access provider is clear in the other direction: a client is
> not an employee, and is entitled to a free, open and neutral Internet
> access.

Stephane, that’s simply not true. A client of an Internet access provider is 
entitled to the service that they contractually agreed to pay for. Check the 
small print. Or the T the next time you use some coffeeshop’s wifi. Even if 
your ISP offers you “free, open and neutral Internet access” (for some 
definition of that phrase), I’m pretty sure they’ll drop your service if you 
were damaging their network or or doing something else that was illegal or 
otherwise in breach of their T

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

[Jim Reid]

> On 15 Feb 2019, at 09:02, Stephane Bortzmeyer  wrote:
> 
> I really think it is important to make the difference between:
> 
> * I blocked your request because that's _my_ policy
> * I blocked your request because I'm compelled to do so, don't
>  complain, it would be useless.

Why? From the client's perspective, there's no effective difference between 
these. Their request was rejected for some policy reason and it doesn't really 
matter whose policy has been applied.

Besides in situations where blocking is being done because of someone else's 
say so, it's highly likely that the DNS operator will be subject to some sort 
of injunction which prevents them from disclosing that such blocking is taking 
place. Think warrant canaries.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Jim Reid]

> On 14 Feb 2019, at 08:58, zuop...@cnnic.cn wrote:
> 
> the premise is the recursive server should completely trust an Authenticated 
> server

You’ve already made that clear. The problem with that premise is it’s a false 
one. It represents a naive/unrealistic view of how the DNS is used.

Your proposal also needs all the authoritative servers for some zone to be 
under the same administrative/operational control. That’s also a false premise. 
And naive/unrealistic. It’s been explained to you that many organisations, TLDs 
in particular, don’t do that. They arrange service from multiple DNS providers 
to avoid single points of failure, improve redundancy, have extra capacity, 
etc, etc.

> if an DNSSEC_enabled authotative server(no matter it is Alice or Bob) is evil 
> and modifies DNS records, it will succeed because it has private key and can 
> fake anything

That premise is wrong too. Only the master server needs access to the private 
DNSSEC key. That master server isn’t necessarily in the zone's NS RRset and 
handling queries from resolving servers. Besides, if someone gives their 
private key to someone else -- in this case another authoritative DNS server -- 
by definition it isn’t a private key any more.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Jim Reid]

On 14 Feb 2019, at 06:36, zuop...@cnnic.cn wrote:
> 
> i think both DNSSEC and DoH(or DoT) can protect DNS data

It depends on your definition of “protect”. For some threats/attacks, DoH or 
DoT by themselves can’t protect DNS data - for instance a DoH or DoT server 
that intentionally or accidentally returns false data. DNSSEC can counter that. 
Provided the client can perform validation and the DoH or DoT server returns 
DNSSEC material in its responses. It might not always be wise to make these 
assumptions, especially client-side validation.

> Transiting trust is hard but may be accomplished in the future.

That simply won’t be possible until every DNS client does DNSSEC validation. 
Good luck with that.

> The deployment of DNSSEC also takes a long time and is still in progress.

Indeed. That’s yet another reason why transiting trust is hard.

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

Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

[Jim Reid]

> On 21 Jan 2019, at 10:26, Ondřej Surý  wrote:
> 
> We can’t be removing EDNS workarounds and at the same time slap another 
> workaround into the DNS.

+1

I think the WG should drop this draft.

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

Re: [DNSOP] Fundamental ANAME problems

[Jim Reid]

> On 5 Nov 2018, at 15:38, Ray Bellis  wrote:
> 
> The cost to the DNS community of *trying* my proposed HTTP record is pretty 
> negligible.  Worst case, as Brian put it, is we burn a code point, add a 
> trivial amount of code to DNS servers, but the browsers don't adopt it.  It 
> wouldn't be the first time, it won't be the last.

I think this is worth a punt. The risks/costs are low and the benefits are more 
than worth it.

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

Re: [DNSOP] KSK rollover choices

[Jim Reid]

> On 31 Oct 2018, at 00:27, Mark Andrews  wrote:
> 
> Bootstrap is still a issue.  Over fast TA rolling makes it more of a issue.

Indeed. And that's the underlying problem that needs to be fixed IMO - for 
instance when/if there's an emergency rollover.

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

[DNSOP] KSK rollover choices

[Jim Reid]

On 30 Oct 2018, at 22:31, Mark Andrews  wrote:
> 
> Ultra frequent key rolls are not necessary.  It takes years the latest 
> releases of name servers to make it into shipping OS’s.

So what? Key rollover policies cannot and should not be driven by vendor OS 
release schedules. Or the BIND/whatever version they choose to distribute. If 
key rollovers became dependent on these considerations, we’d never be able to 
roll the root’s KSK.

Software that had hard-wired the old key caused trouble for the recent rollover 
so we simply have to be in a much better place next time. I hope you don't want 
to perpetuate that legacy behaviour, albeit in a slightly different form.

If the (hypothetical) problem is DNS software gets shipped with the current KSK 
on the release date and that might lurk in vendor distributions long after the 
KSK has rolled, the solution is obvious. Don’t do that.

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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Jim Reid]

On 21 Aug 2018, at 16:23, Vittorio Bertola  
wrote:
> 
> And I have yet to see a statement from the DoH community that Mozilla's idea 
> of making DoH the default and disregarding whatever resolver is being 
> configured in the system via DHCP is not a good one.

Why would/should the DoH community -- whatever that is -- make such a 
statement? In some cases, it will be better to use the current network’s 
resolving DNS servers. In others it won’t. For some definition of “better”. The 
use or non-use of DoH is somewhat orthogonal to those underlying 
considerations. 

Deciding what’s “good” or “bad" gets very messy very quickly. For instance I 
might decide to trust $coffeeshop’s resolver in my home town (say) but not at a 
branch of $coffeeshop that's behind the Great Firewall of China. Or 
$coffeeshop’s outlet in the foyer of my employer’s building.

> Actually, during the discussions in Montreal there were people talking about 
> centralized DNS operators paying the browser makers to get their DNS traffic, 
> and then monetizing it to get back the money. How can this be presented as 
> "more privacy" is baffling.

If this happens, it can be worked around. Almost nobody is going to be forced 
to use privacy-unfriendly browsers or resolvers at gunpoint. Besides, providers 
offering “even more privacy” will emerge if this centralisation/monetisation 
thing turns out to be a problem. Having low barriers to entry is one of the 
nice things about the Internet. Well OK, it’s a nice thing some of the time. :-)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Jim Reid]

> On 27 Jul 2018, at 12:17, Tony Finch  wrote:
> 
> Ah, the obvious solution is to deprecate zone files and just ship update
> journals instead!

Why not go for distributed hash tables? :-)

Says he running away to watch the fireworks from a safe distance...

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

Re: [DNSOP] New WG for document/protocol cleanup?

[Jim Reid]

> On 28 Mar 2018, at 18:02, Phillip Hallam-Baker  wrote:
> ... long rant snipped ...
> Well that is how I plan to go forward at any rate.

Good for you. Please come back to the IETF once you've figured it all out and 
have running, interoperable code.

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

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Jim Reid]

On 24 Mar 2018, at 20:20, Ondřej Surý  wrote:
> 
>> It might be a different story if one of those zombie RRtypes required 
>> additional processing. None spring to mind though.
> 
> But (most of) those I picked actually *DO*:
> 
> a) compression is allowed, so compliant and non-compliant servers can’t speak 
> together, because non-compliant will just store junk in the RDATA when 
> received from compliant server;
> b) the RDATA needs to be understood and lowercased for canonical form when 
> DNSSEC signing; again you need to *implement* this in DNSSEC Validator as it 
> would cause validation failures if you don't

Fair enough Ondřej. Though I suspect the number of servers that sign or 
validate MAILA records  (or whatever) can be counted on the number of ears on 
one hand. :-)

FWIW the sort of additional processing I had in mind were things comparable to 
resolvers chasing CNAMEs or DNAME rewriting.

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

Re: [DNSOP] Terminology question: split DNS

[Jim Reid]

> On 19 Mar 2018, at 18:09, Artyom Gavrichenkov  wrote:
> 
> Another issue here is that, for some enterprises at least, there's no
> single "internal network" anymore.

We don't need to enumerate every potential split DNS scenario (or how it's 
implemented). The original text says "there are many potential variants". That 
should be enough for this document. The simple example of one internal and one 
external net will do for illustrative purposes.

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

Re: [DNSOP] Terminology question: split DNS

[Jim Reid]

> On 19 Mar 2018, at 17:47, Paul Hoffman  wrote:
> 
> Some folks had reservations about the current definition of "split DNS":
>   "Where a corporate network serves up partly or completely different DNS 
> inside and outside
>   its firewall. There are many possible variants on this; the basic point is 
> that the
>   correspondence between a given FQDN (fully qualified domain name) and a 
> given IPv4 address
>   is no longer universal and stable over long periods."
>   (Quoted from , Section 3.8)
> 
> What would the WG like for this definition?

The quoted definition seems wrong: the binding of a name to address isn't 
necessarily unstable in split DNS setups. And that's not the only game in town 
either: for instance MX and NS records.

How about the following:

Where a corporate network serves up partly or completely different DNS data 
inside and outside its network. There are many possible variants on this; the 
basic point is that the
correspondence between a given QNAME/QTYPE/CLASS tuple and the data for that 
tuple is no longer universal and can depend on where the query is made from or 
which DNS server(s) are queried.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question about usage of ip6.arpa and in-addr.arpa

[Jim Reid]

> On 13 Mar 2018, at 00:07, Paul Hoffman  wrote:
> 
> How could you use ACME to validate the IP address of a roving client or a P2P 
> application that has no fixed IP address?

In pretty much the same way as ACME tokens would/could be used to validate 
clients that have (fixed) names.

Or perhaps these hypothetical IP-flavoured tokens contain a public key which 
could be used for opportunistic encryption with whatever’s at that IP address. 
Add hand-waving to taste.

At this very eary stage, questions shouldn’t about how these hypothericals will 
get implemented. I’m just giving some possible examples of use cases other than 
webbery, like you asked for. They might be bad or stupid use cases. Or turn out 
to be pointless. Or unworkable. Or all of the above. For now they’re just 
things that might be on the list that you, me and Roland eventually produce.


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

Re: [DNSOP] Question about usage of ip6.arpa and in-addr.arpa

[Jim Reid]

> On 12 Mar 2018, at 23:27, Paul Hoffman  wrote:
> 
> For which other protocols did you want certificates with IP addresses as 
> identifiers?

I think these may be needed for SIP, particularly roving (nameless) clients. 
And quite possibly for P2P applications.

> If your list is longer than zero, are you willing to help Roland with a 
> solution using DNS records for validation that has any chance of being 
> usable? 

Yes, I’d be willing to work with Roland on at least finding and documenting 
likely use cases. Are you? Whether we (or others) can then come up with 
something that has any chance of being usable is another matter.

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

Re: [DNSOP] Question about usage of ip6.arpa and in-addr.arpa

[Jim Reid]

> On 12 Mar 2018, at 17:37, Paul Hoffman  wrote:
> 
> If the use case here is to be able to issue certificates for TLS servers 
> based on the IP address instead of the domain name, creating something new in 
> the DNS may be overkill. That is, why even have Section 4.1 of 
> draft-ietf-acme-ip at all? What's wrong with only having direct HTTPS access?

Is web the only protocol that runs on the Internet now? I realise that might 
seem to be the case these days, but even so... :-)

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

[DNSOP] a fragmented and uncooperative Internet

[Jim Reid]

> On 21 Sep 2017, at 08:08, Davey Song(宋林健)  wrote:
> 
> In another word, we are facing the fragmented and uncooperative Internet. 
> What should we do ?

Switch it off? Hand it over to ITU control? :-)

The Internet was designed from the outset to work around breakage. Packet 
fragmentation issues will always be with us unfortunately. The networks which 
have these problems will fix them: Darwinism will take care of that eventually. 
Until then everyone else just has to work around them or ignore their 
brokenness. 'coz that's how it works.

We (for some definition of we) might come up with some tools to help identify 
the problem or do some outreach and education to help mend these broken 
networks. However I am sceptical those sort of things will be successful. After 
all we still have nets, servers and middleboxes that can't/won't handle EDNS 
correctly or assume that DNS packets only ever go over UDP and are always < 512 
bytes.

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

Re: [DNSOP] DNSSEC in local networks

[Jim Reid]

> I'd say: "either you trust the local net or not"

I'd say trust but verify. Everywhere. => In this context always doing DNSSEC 
validation.

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

[DNSOP] DNSSEC in local networks

[Jim Reid]

> On 4 Sep 2017, at 07:12, Walter H.  wrote:
> 
> by the way: why are you discussing about DNSSEC for names that are used
> only locally?

Why do you seem to assume there are never, ever any DNS security issues on the 
local net?
Why would someone want to deliberately configure things to prevent DNSSEC-aware 
applications and resolvers from working on the local net?

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

[DNSOP] missing use case and problem statement for draft-woodworth-bulk-rr

[Jim Reid]

> On 20 Jul 2017, at 16:25, Stephane Bortzmeyer  wrote:
> 
> And DNSSEC is not the only case where we introduced RRtypes where you
> have to check your slaves to be sure they support it. There was also
> DNAME.
> 
> That's why I don't share the fears about BULK

BULK would be an RRtype which *by design* prevents another part of the DNS from 
working. That’s just wrong. Behaviour like that might be acceptable for a 
non-trivial protocol change like a new header bit or EDNS option (say). But a 
new RRtype? Really?

BTW, if there are cases where an ISP’s customers care about reverse DNS for 
their IPv6 addresses, what’s stopping those customer devices using dynamic 
update to provision their names or have the DHCP server do that for them? Why 
can’t the ISP's provisioning systems and tools spit out PTR records for the IP 
addresses which need this secret sauce?

It’s still not clear to me what problem is actually being fixed by BULK and why 
no other provisioning mechanism is applicable.

If the WG is to adopt this draft, I think there first has to be a clear problem 
statement backed by use cases. [Prettier log files doesn’t do it for me. YMMV.] 
That way, the WG will be able to decide how well the final version of the 
document addresses these requirement if/when it gets to WGLC.

Apologies for introducing a meaningful and relevant Subject: header.

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

Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

[Jim Reid]

> On 20 Jul 2017, at 02:17, Woodworth, John R  
> wrote:
> 
> this is just a next-gen $GENERATE

Indeed. We all get that. However $GENERATE is a BIND-ism, like views. It’s not 
part of the DNS protocol. I’m not yet convinced $GENERATE (albeit with a BULK 
makeover) needs to be.

The use case for BULK still hasn’t been made IMO.

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

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

[Jim Reid]

> On 20 Jul 2017, at 03:12, Woodworth, John R  
> wrote:
> 
> For now, I think we've narrowed the draft opposition to two camps:
> 
> Camp#1) Don't force me to use IPv6 reverse, I simply will never
> 
> and
> 
> Camp#2) Don't break DNS, even for a second

Well I don't recognise either of these camps.

What was it you were saying about beauty being in the eye of the beholder? :-)

I'm in Camp N (for some definition of N): where's the use case/justification 
for BULK and is it worth the effort?

It's not clear if the WG has fully considered the impact of BULK on signed 
reverse zones. Doing something to the DNS that further hinders uptake of DNSSEC 
is probably a bad idea IMO. YMMV. Proposed protocol changes which do that need 
to come with compelling benefits that outweigh this drawback.

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

Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

[Jim Reid]

> On 19 Jul 2017, at 11:34, Woodworth, John R  
> wrote:
> 
> Think of this as your property (e.g. your yard).  Each IP address
> in itself is small but without the sum of each, what do you have?
> 
> Suddenly, each blade of grass has value.

What value has each IPv6 address? Or a name like 
host-2001-67c-1232-144-21f-5bff-fec3-ab9d.example.com? Please enlighten me.

If you have a need to generate PTRs on the fly for IPv6 addresses in your 
network, fine. However that doesn't seem to be a compelling reason to modify 
the DNS protocol and change every DNS server on the planet.

The cost/benefit optics of this draft are unclear.

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

Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

[Jim Reid]

> On 19 Jul 2017, at 10:37, Tony Finch  wrote:
> 
> BULK seems like far too much cleverness applied to far too small a problem.

+1. I'm not convinced there is a problem here that needs fixing.

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

Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use

[Jim Reid]

> On 18 Jul 2017, at 12:17, Francis Dupont  wrote:
> 
> It seems easier to remember that DNSSEC offers proofs for denial of existence.

Except when it doesn't. :-) RFC5155 includes opt-in.

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

[DNSOP] new DNS classes

[Jim Reid]

> On 4 Jul 2017, at 18:49, Paul Vixie  wrote:
> 
> while IETF governs the protocol, ICANN only governs the IN class. i expect 
> that there will be other classes some day, in order to avoid some aspect of 
> ICANN.

Attempts have already been made to do just that. It would be nice not to have 
to put out those fires all over again.

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

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

[Jim Reid]

> On 28 Mar 2017, at 16:05, Evan Hunt  wrote:
> 
> My problem is with elevating "pointless" to the force of a "MUST NOT".  I
> think it should be reduced in force to "OPTIONAL", "NOT RECOMMENDED", or
> even "SHOULD NOT".  Kill it on the supply side.

A "MUST NOT" should kill it on the supply side. Anything less emphatic than 
that will not. An "OPTIONAL" or whatever creates enough uncertainty to give 
implementers/operators the idea that it's advisable to persevere with MD5 
support "just in case", even if nobody is using MD5. Softer language would give 
enough wiggle room to allow MD5 support to lurk around forever in a zombie 
state and never get killed.

Give MD5 support two shots to the head. With silver bullets. Then nuke it from 
orbit. Just to be absolutely sure.

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

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

[Jim Reid]

> On 27 Mar 2017, at 20:45, Paul Vixie  wrote:
> 
> all code has bugs, eventually. or at least, there is no
> existence proof to the contrary, and also, no reason to suspect
> otherwise. so, code that is not used will not be reviewed or maintained.
> it's a risk, just by existing.

+1. The most reliable and safest code is the code that isn't there.

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

Re: [DNSOP] .arpa

[Jim Reid]

> On 27 Mar 2017, at 13:41, Ray Bellis  wrote:
> 
> On 27/03/2017 02:52, Patrik Fältström wrote:
> 
>> One important part is in the letter from NTIA (Karen Rose) to ICANN 
>> (Louis Touton) in Appendix A.
>> 
>> A letter sent April 28, 2000.
> 
> Is it online?   I can't find it in the ICANN correspondence archive.

It's in RFC3172.

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

[DNSOP] .arpa

[Jim Reid]

> On 21 Mar 2017, at 14:53, Suzanne Woolf  wrote:
> 
> RFC 3172 was written in 2001…

RFC 3172 was an attempt to rewrite history and contrive an acronym: Address and 
Routing Parameter Area - really?

> Respectfully, I’ve always wondered who has this problem (US or non-US) 
> besides network infrastructure geeks Of a Certain Age (yes, including myself, 
> and many IETF participants).

It's a convenient tool for those hostile to USG "control" of the Internet: ie 
the US military is responsible for everything under .arpa, the US military's 
ARPA has still got some special status in the operation/development/control of 
the Internet, etc, etc. [And say things like "if .arpa isn't for US military 
control, why can't the string be changed?" or ".arpa hasn't been renamed since 
the Internet started 25-30 years ago. That proves ARPA/DoD is in charge of the 
Internet.".] It's utter nonsense of course. But that doesn't stop government 
officials and policymakers from making these arguments. I have seen them do 
this many times. Sigh. RFC3172 didn't make things better.

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

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Jim Reid]

> On 21 Mar 2017, at 15:00, Mark Andrews  wrote:
> 
> The homenet working group decided that the root was a more appropriae place 
> than
> arpa.

That doesn't mean their decision was the right one. In retrospect, the 
stand-off in this WG and between the IETF and ICANN about "special" TLDs (for 
some definition of special) suggests they made a poor choice.

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

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Jim Reid]

> On 21 Mar 2017, at 14:09, Paul Wouters  wrote:
> 
> Can we tell from the queries or a timeline of query quantity if this
> is generic .home pollution that predates the homenet protocol suite,
> or actually the result the homenet protocol suite being deployed?

What's this "we"? :-)

The short answer to your question Paul is I don't know. If someone could 
confirm what qname/qtype tuples are limited to the homenet suite, I could go 
looking for them in the DITL datasets. This will not be a trivial task. One 
year's DITL data generally consists of a few TB of data spread over 300K 
compressed pcap files containing a total of ~100B queries. It takes about 1 day 
of elapsed time and a few CPU-weeks to chug through that.

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