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

[Vladimír Čunát]

On 08/08/2022 14.53, Jim Reid wrote:

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.


I fail to see how it's better.  If you promise that ICANN won't put a 
name into root (say in the normal gTLD process), it's effectively 
taken.  That's the .onion case all over again.


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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review

[Vladimír Čunát]

On 19/08/2022 20.06, Paul Wouters wrote:

Security Considerations could say that .alt queries MUST NOT be
forwarded to other DNS servers for resolution.


There's a dilemma with SUDNs.  If a resolver isn't allowed to "send the 
name upstream", it might not be able to return DNSSEC-correct denial.  
While it's often fine to return a forged bogus answer, it's certainly 
not a perfect setup.  For example, with validators that don't support a 
SUDN yet forwarding to resolvers that already supports that SUDN - 
generating retry loops and eventually SERVFAILs.


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

Re: [DNSOP] Use of CNAMEs for NS Records

[Vladimír Čunát]

On 23/08/2022 14.15, Tobias Fiebig wrote:

Is there something I missed/should CNAME in NS be considered valid now?  [...]  
However, it seems odd that RFC2181 and operational practice seem to diverge 
here.


This sounds like running a few tests in the wild might imply that such 
setup is OK.  (compliant/valid/reliable)  I believe that's a wrong 
approach in principle and risky in practice.


DNS servers are not even *obliged* to fail on non-compliant input, 
except for explicit requirements like in DNSSEC validation.  They're 
*allowed* to fail, which is a thing depending on particular 
implementation and can change over time.


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [dns-privacy] [core] WGA call for draft-lenders-dns-over-coap

[Vladimír Čunát]

On 06/09/2022 17.06, Ben Schwartz wrote:
The choice of transport is independent of the DNS server's answering 
behavior, which must not be modified by the transport.


Nit: there's a very specific counter-example of EDNS padding which is 
meant to be added depending on transport encryption. 
https://www.rfc-editor.org/rfc/rfc7830#section-6


There might be some others (in future, too), as encryption does change 
some considerations, but yes - not basic stuff like following CNAMEs.


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt

[Vladimír Čunát]

On 07/10/2022 18.21, Paul Wouters wrote:

Perhaps even:

DNSSEC documents predating {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}
specify obsoleted DNS RRtypes that never saw deployment beyond early
adopter testing, and haven't been deployed in nearly two decades,
and are of no concern to implementers. 


I like that, mainly for the direction of giving the historical documents 
less significance.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?

[Vladimír Čunát]

On 17/10/2022 23.28, Benno Overeinder wrote:
The DNSOP WG chairs welcome feedback on the draft 
draft-homburg-add-codcp, Control Options For DNS Client Proxies 
(https://datatracker.ietf.org/doc/draft-homburg-add-codcp/). 


I find it a bit weird for a client to *choose* how the proxy/resolver 
might connect to upstream, even choosing an IP address set.  And for 
each request separately.


Moreover, I fail to understand motivation for the caching part - tagging 
by properties of transport.  If an answer is cached, what are the 
privacy concerns?  No further connection to upstream is made for that 
request anyway.


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?

[Vladimír Čunát]

OK.  I suppose I'm stuck in the model of (at least) machine-wide 
policies, thinking that it would be really messy if each app chooses 
properties of their DNS separately.  (Which sounds more like a job for a 
library API anyway.)___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?

[Vladimír Čunát]

On 19/10/2022 10.06, Philip Homburg wrote:

And then we end up with potentially many different implementations in 
applications,
which seems worse to me.


That aim doesn't seem consistent with the statement that the proxy won't 
be trusted with DNSSEC validation.  That way you still need a rather 
complex DNS code, ideally in a library.  And you'll need to query to 
stub for extra records to form the whole chain, so that you even can 
validate.  Overall I don't advise splitting DNSSEC validation away from 
the other stub work - cache in particular.  Also because of the 
mechanisms that you want to happen in case validation fails.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .alt filtering in recursive servers

[Vladimír Čunát]

On 08/11/2022 11.33, Mark Andrews wrote:

Filtering .alt in recursive servers should be a MUST NOT.
[...]


It would be nice to define this *in RFCs* somewhat uniformly for *all* 
the different special-use names.


There's this unfortunate conflict between blocking and not blocking: 
total prevention of leaks, providing DNSSEC proofs, and simplicity (as 
"knowing whole root" can be a non-trivial implementation change).


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

[DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex

[Vladimír Čunát]

Hello.

It's not a major thing in your design, but I see a risk that DNSKEYs at 
non-apex might have trouble validating, so at some point I'd expect your 
proposal to choose a different approach (e.g. allocate a new identical 
RR type) or at least confirm that it won't be a major problem.


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Vladimír Čunát]

Hello.

I don't know... my opinions often differ from recommendations of this 
draft, but ultimately it's subjective to some degree.  As feedback was 
requested on IETF 115, let me highlight more significant differences in 
this e-mail, though I dislike arguing about (mostly) opinions.




Nit: the following part doesn't make sense to me, as signature validity 
period is normally way over the TTL anyway (and it's really a bug if it 
got shorter):


Section 8.1 of [RFC4033 
] 
mention the ability by the resolver to set the upper bound of the TTL 
to the remaining signature validity period. This would at least reduce 
inconsistencies during regular KSK roll over.


Perhaps I'm really misunderstanding the other parts of the 
recommendation that follows afterwards.  (Also, operator RFC seems a 
weird place to define new algorithms for TTL handling.)  I thought the 
usual issues from bad rollovers aren't about records using bad (initial) 
TTL values but rather doing some steps too fast (or other mistakes).  
Though yes, reduction of TTLs will reduce duration of transient 
mistakes.  And my understanding is that the referred-to (unfinished) 
revalidation draft won't change anything during key rollovers (e.g. 
clear cached records), even though key rollovers seem to be the focus in 
this section.





*  A DRO MUST be able to flush the cached data associated to a DNSKEY
From practical implementation perspective, I'd rather recommend 
flushing a subtree than additionally tracking which sets got validated 
by which keys.  (Or maybe that's considered to also satisfy the 
bullet?)  It's a nit basically, but let me post it, as the rule is with 
MUST in here.  Note that the rogue DNSKEY could sign delegations or 
other DNSKEYs, thereby in both cases populating (parts of) that subtree 
with data signed by *other* DNSKEYs.




Section 11. (Cryptography Deprecation Recommendations) seems to imply 
that *validator operator* would manage the set of supported DNSSEC 
algorithms.  I don't think that would be good advice.


RFC 6975 and the associated bullet serve as a red herring here - it's 
standardized but I haven't heard of anyone using it in practice, as it's 
just more convenient on signer side to use one good algorithm than to 
somehow serve different things to different resolvers (and I'm not even 
starting on multiple layers of DNS servers/caches).  RFC 8624 is the 
(missing) reference there, but I believe it's more for the IETF to 
choose/update and for vendors to implement.  Validator operators should 
just update their SW to get future updates of that, though this can be 
expected not to change for years.  We recently saw that the set of 
supported algorithms often isn't easy to configure and we reiterated 
other down-sides, when Red Hat tried hard to avoid SHA-1.



Nit: I wouldn't recommend RFC 5011, as I think it's more trouble than 
worth in practice.  Similarly with some of (root) TA bootstrapping 
mechanisms, but this draft is vague about recommending those anyway.



--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Vladimír Čunát]

OK, thanks.  The changes are certainly improvements, in my eyes.  Below 
I'll further clarify what I meant.



4033 indicates it does not make much sense to keep a RRSIG whose 
validity period has expired ( TTL > Validity period).


Yes, I should stress that I do agree with trimming TTL of whole RRset by 
expiration of RRSIG that's used to validate it, and there are good 
reasons for that.  I even had implemented that some time ago for Knot 
Resolver.


As I wrote (perhaps unclearly), I was puzzled mainly by the 
recommendation that followed.  I'm failing to really understand what it 
meant exactly, and by what mechanism it's meant to ensure coherence (in 
some cases?).  And perhaps, how a validator operator could enforce such 
conditions without forking their validator. The line:


RRsets TTL SHOULD NOT exceed the DS, KSK or ZSK initial TTL value, 
that TTL SHOULD trigger delegation revalidation as described in 
{{!I-D.ietf-dnsop-ns-revalidation}}.





I agree we need to ensure good practice with 8624.
I do agree this might not be very very useful today, but the reason we 
recommended this is also to ease communication between the resolvers 
and authorities. My impression is that it is hard to change the 
signature scheme on the authoritative side as we do not know what 
resolver will support it.
Recommendations for authoritatives are a bit tangential here.  I believe 
that RFCs (8624 or others) currently don't give a good idea about 
internet-wide support of resolvers for the algorithms, but you can find 
good measurements if you pay attention around IETF, OARC, etc.  Alg. 13 
is widely used for some time, even on TLDs, but 15 seems unfortunately 
still rather "risky" (or recently was): 
https://www.potaroo.net/ispcol/2021-06/eddi.html




The question seems whether we should use such recommendations to 
improve communication between authoritative and resolvers or favor a 
more centralized approach where all software is more sticking to one 
document 8624. That latter approach seems to me to have too long 
cycles and I wished that we could benefit from new crypto ed25519 
earlier than when all resolvers are updated.
Well yes, I'm in favor of keeping the supported-algorithm set 
centralized internet-wide, instead of trying to start deploying a 
decentralized mechanism.


Validators don't need to talk to *authoritative* servers.  I believe 
it's quite common to have more than one layer of resolvers/caches, in 
which case an EDNS0 signal is just a bad mechanism, even if we somehow 
managed to deploy it widely.  (which wouldn't be easy, kinda similarly 
to widely deploying EdDSA validation)


I mainly wanted to dissuade from early algorithm deprecation on 
validator side.  Validator operators might not understand that instead 
of validating a zone with a (supposedly) weak algorithm, they won't 
validate it at all.  So the only improvement is the AD=1 bit which gets 
stricter by that, but most use cases don't even look at that bit and 
only rely on the protection by SERVFAILs.





I am surprised  you would not recommend RFC 5011


5011 needs persistent state, a thing that resolvers/validators often 
don't need at all otherwise (cache is safe to delete).  5011 doesn't 
always work, so you need to combine with some fallback mechanism(s) 
anyway - for new installations and for stale ones (missed rotation).  
Root rollover has happened only once in history, non-root TAs aren't 
that common, and 5011 algorithm isn't very simple, so the code can 
easily get some bugs without anyone noticing until it's too late.


Lots of down-sides, so I rather put the TAs into SW updates, for the 
root TA case at least.  I'd recommend trying to avoid non-root TAs, but 
if I had to choose, I'd put them into configuration. Again a thing that 
I have to provision *anyway*, so I get the occasional TA updates 
basically for free, without needing to worry about those 5011 
disadvantages.  (occasional = 5011 defaults to requiring 30 days of overlap)



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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Vladimír Čunát]

On 25/11/2022 18.26, Daniel Migault wrote:
So let me know how we came to this lines and I suspect we do share 
some similar concerns. A recurrent question and reticence we receive 
from MNO and ISPs regarding DNSSEC is that they are really scared 
about having the cache with incoherent RRsets in their cache that 
causes the validation to fail and in many cases they imagine a 
mechanism to prevent and address such incoherent data in the cache.
One of the intentions of this draft is to prevent such mechanisms to 
be implemented - mostly as it is likely to generate errors that DNSSEC 
experts would not be able to catch or understand - as generated by the 
home made solutions.  As a result we wanted  to minimize the change to 
the DNSSEC mechanic and only rely on very simple and standard  
mechanisms. 4033 provided one way to limit some incoherencies, and we 
also thought of a similar mechanism that was   like the one described 
in I-D.ietf-dnsop-ns-revalidation which as we saw it ensures 
something like a mechanism that refreshes the chain of trust.


I get that in countries with low validation rates [1] it may be 
difficult to explain to resolver operators that it should be only the 
authoritative side who worries that they "do DNSSEC wrong". Maybe I'm 
also personally biased against putting much work to work around mistakes 
done on the other side of the protocol.


[1] https://stats.labs.apnic.net/dnssec


What we expect is that the validator proposes this option and as such 
the DRO selects that option in the validator if present.


Well, OK.




Well yes, I'm in favor of keeping the supported-algorithm set
centralized internet-wide, instead of trying to start deploying a
decentralized mechanism.
[...]

I mainly wanted to dissuade from early algorithm deprecation on
validator side. [...]

I got your point and agree it might be counter productive to encourage 
a mechanism that is not reliable. I propose to remove the text below:

[...]


OK.

I don't see the part about extended errors as problematic (RFC 8914).  
It really seems to be getting into (open-source) implementations and it 
can help with debugging in some cases, though deploying it is probably 
not very important either.




Oh! sure for the TA. My understanding of the text is that it 
recommends 5011 for running instances, but that new instances are 
configured with up-to-date TA that in most cases are updated by 
software update. So yes I agree and will check this appears clearly.


I don't think 5011 is worth doing at all.  Maybe in some exceptional use 
cases.  Well, I haven't heard much about deployment experience with 
non-root TAs, so perhaps I just don't know those well.


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

Re: [DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex

[Vladimír Čunát]

I didn't explain why, so let me add just a short pointer.  No need to go 
deeper here at this point of the draft, I think.


On 28/11/2022 19.26, Peter Thomassen wrote:
As such, I don't see any risk that would not be exposed immediately 
during implementation/testing, and the fix is also trivial. 


Triviality of a fully correct fix may depend on the particular 
implementation.  Note the implications for caching, etc.  These DNSKEYs 
will be DNSSEC-validated but must not be used for validation of other 
signatures.


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

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

[Vladimír Čunát]

On 15/12/2022 01.59, Martin Schanzenbach wrote:

If there is an obvious way to do it, the draft could give an example. Whatever 
you
mean by "go to a regulated space" should be given with clear example.


You can simply register a DNS name and use that sub-tree in non-DNS 
context (as well).  That also comes with other advantages, depending on 
your use case, in particular the ability to "do something" also in case 
a user falls through to normal DNS.


I don't think this RFC really needs to explicitly mention such 
alternative approaches, but I wouldn't mind.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Vladimír Čunát]

On 15/12/2022 14.45, Peter Thomassen wrote:
In what sense is this document "informational" when it is called 
"validator requirements", or, conversely, in what sense does it spell 
out "requirements" when it is only "informational" and not "standards 
track"? 


The current *title* says "Recommendations".  I don't think the draft 
name matters much, especially after it becomes an RFC.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Vladimír Čunát]

On 15/12/2022 23.36, Daniel Migault wrote:


I don't see the part about extended errors as problematic (RFC
8914).  It really seems to be getting into (open-source)
implementations and it can help with debugging in some cases,
though deploying it is probably not very important either.

So I think what you're suggesting is that  8914 will be implemented, 
without even the choice being left to the operator. If that the case, 
would you like the text instead of SHOULD say something like MAY if 
not supported by default by the implementation ?


For Knot Resolver we implemented EDE in responses and so far there's 
been no motivation to offer opt-out.  (It's just a few bytes, and 
unknown EDNS should be ignored.)


I don't have strong feelings about the text; "SHOULD implement RFC 8914" 
sounds OK.  It's certainly nice to implement at least some basic 
distinction, e.g. signalling that SERVFAIL comes from a DNSSEC error.  
Further details could help with debugging various issues.




Oh! sure for the TA. My understanding of the text is that it
recommends 5011 for running instances, but that new instances are
configured with up-to-date TA that in most cases are updated by
software update. So yes I agree and will check this appears clearly.


I don't think 5011 is worth doing at all.  Maybe in some
exceptional use cases.  Well, I haven't heard much about
deployment experience with non-root TAs, so perhaps I just don't
know those well.

I need to take the time to reconsider that. I am a bit overloaded but 
expect to come back to this point more specifically. I got your point 
in any case and the scenario we have  is a zone that does not want to 
rely on the parent zones in case something goes wrong in these parent 
zones. The other aspect is also that we did ot want to give the 
impression DNSSEC only works with the root KSK as a TA. But as ai 
mentioned I will come back with that.


OK.  In my opinion you depend on parent's health a lot anyway 
(unavoidably), though yes - DNSSEC can be the most fragile part.


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

[DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: Knot Resolver + Knot DNS

[Vladimír Čunát]

With Knot Resolver + Knot DNS the fragmentation issues are currently 
being addressed quite simply:


 * IP_PMTUDISC_OMIT to avoid spoofed MTU
 * UDP size limit, 1232 by default (and of course honoring if the other
   side wants lower, etc.)

Other points from the draft, perhaps less important:

 * fragments are ignored if they arrive over an XDP interface (XDP
   usage is not typical)
 * TCP is attempted after repeated UDP timeouts
 * minimal responses: yes (not configurable)
 * smaller signatures: yes, ecdsap256sha256 by default


I also believe that the MTU spoofing should be reflected in this draft's 
recommendations.  With the current list I _suspect_ attackers could 
relatively easily force all 512B+ answers to TC=1 + TCP (if on IPv4).



1232: I haven't gone in detail over the relevant measurements so I'm not 
even 100% sure they're conclusive, but it might really will be better to 
increase that default.  I don't expect any other changes related to this 
draft for future.



Use 'minimal-responses' configuration: Some implementations have a 
'minimal responses' configuration that causes DNS servers to make 
response packets smaller, containing only mandatory and required data


Nit: this formulation makes me wonder what this recommends for SVCB-like 
records.  Strictly taken I'd say it clashes with some SHOULDs from the 
soon-to-be RFC.  Either way, SVCB-like queries could be prone to 
generating large answers (if this SHOULD is followed).



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

Re: [DNSOP] Updated: Compact Denial of Existence

[Vladimír Čunát]

On 06/03/2023 03.35, Shumon Huque wrote:
I suspect that unilaterally putting NXDOMAIN into the rcode field will 
break a lot of validator code. They are likely to use the rcode to 
advise them on what type of proof to look for in the message body, and 
they won't find a traditional NXDOMAIN proof.


My understanding of RFCs is that NXDOMAIN or NOERROR are a mandatory 
part of what needs to be proven by the records inside. If the proof 
doesn't match the RCODE, surely validators should SERVFAIL.  I don't 
think you can salvage this by a simple new EDNS option; it's the signed 
records where you need to prove the result you want.


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-alt-tld-22

[Vladimír Čunát]

On 07/04/2023 06.12, Linda Dunbar via Datatracker wrote:

Question: Are the .local and  .onion part of the Special-use domain names
registered in IANA?


They do appear in the registry:
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Coming soon: WG interim meeting on the definition of "lame delegation"

[Vladimír Čunát]

On 19/06/2023 17.00, Masataka Ohta wrote:

I can't see any problem with "lame" delegation than a "secondary"
or "slave" server, because of the history of racial discrimination
in US. 


Honestly, I'm personally still failing understand the problem of using 
slightly offending word when referring to a machine (e.g. "slave" or 
"lame").


I'll try to keep myself very short, also trying to avoid posting 
followup reactions.  But perhaps some of you could point me to a 
reference that might help me understand better, as this is recurring in 
the recent years (also outside DNS).


Of course I respect that if a *significant* fraction of people does see 
a problem, I can also move on to another set of terms, but I feel like 
I'm missing substance and often the renames come with nontrivial costs.  
Why would a person take offense when those words are *clearly* about a 
machine?  In reality we treat these machines worse than human slaves 
were treated.


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

Re: [DNSOP] Working Group Last Call for Negative Caching of DNS Resolution Failures

[Vladimír Čunát]

On 26/06/2023 16:47, Peter van Dijk via Datatracker via dnsdir wrote:

The document has not seen a lot of WG discussion; I hope
this means people have read it and generally agree.


Yes, I've read through the document now again and I generally agree with it.

(But I'm afraid I can't think about this in depth now, certainly not 
before last call ends.)


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Followup One Week Working Group Last Call for draft-ietf-dnsop-avoid-fragmentation

[Vladimír Čunát]

I see nothing wrong with the current version (-15), and as I posted 
before, I consider it a nice reference for DNS fragmentation.


(I'm a bit late, but at least for the record.)

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

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

[Vladimír Čunát]

On 22/10/2023 13.18, Mirja Kühlewind via Datatracker wrote:
3) In R8 you mention a timeout. Is it already anywhere specified how 
to set such a time for DNS retransmissions? If so, I think a reference 
would be useful. If not, more guidance is need to avoid network overload.


No, I don't think so.

Retransmissions tend to become complex alchemy, exactly because too many 
things could go wrong with the request, and different remedies work well 
for different causes.  I believe this was among the motivations in both 
of https://www.dnsflagday.net occurrences (EDNS handling and default UDP 
size limits), so it's at least somewhat better recently - but as a 
resolver vendor I don't consider these parameters suitable for tinkering 
by users. (though some other vendors/people surely might have a 
different opinion)


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DELEG and parent only resolution

[Vladimír Čunát]

On 30/01/2024 07.55, Kazunori Fujiwara wrote:

It proposes new name resolution using only information on the parent side.


Let me just point out a key distinction: the typical use case of DELEG 
should be kind-of child centric.  Most people will only use a simple 
alias-mode DELEG at the parent, pointing somewhere into their DNS 
hoster's namespace.  That's practically important, because all the 
information can then be managed by that entity without touching the 
parent (e.g. on KSK rollovers).


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DELEG and parent only resolution

[Vladimír Čunát]

On 31/01/2024 09.16, Joe Abley wrote:

It seems important to be prepared for a long transition phase [...]


Yes, that's been well known since the very beginning of the discussions 
at IETF 118.  Support in resolvers will also take years to deploy 
widely, even for relatively simple changes.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP]Re: Our reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.

[Vladimír Čunát]

On 14/05/2024 22.57, Warren Kumari wrote:
This means that we should actually have a column per type (i.e 
“Operators” and “Implementers”) crossed with a column per DNSSEC usage 
type (“Signing” and “Validation”), such that for the “Domain Name 
System Security (DNSSEC) Algorithm Numbers” table we would be adding 
FOUR columns:


I'm not happy about splitting it for validation.  I'd rather strive 
towards a shared global expectation on which algorithms get supported by 
validators, instead of standardizing that individual operators can tweak 
this.  (I hope this can be just about SHA1 at this point.)



The arguments have been posted in the recent weeks.  AFAIK validator 
implementations tend to have only two states for algorithms: supported 
and unsupported, as that's what all the DNSSEC RFCs define.  Downgrading 
will make (some) security properties worse than keeping to validate with 
a weak-ish algorithm.  A current example is Fedora/RHEL for SHA1 stuff.


While I recognize that it's not easy for everyone to agree on support 
status (of SHA1) in validators, not agreeing seems worse than either 
result.  In the current RFC 8624, SHA1 signing is "NOT RECOMMENDED".  
With that it seems rather harsh to officially allow some validators to 
downgrade these to insecure.  I'd imagine that first we should 
standardize some stronger discouragement of SHA1 in zones and keep that 
for some time.



I can imagine the signing side split.  For example, saying now that it's 
not that bad for implementations to still allow to be configured with 
SHA1, but strongly discourage zone operators from utilizing that.  Or 
encouraging SW to be able to sign with ed25519, but stating that (a few 
years ago) the support in deployed validators didn't look too great, so 
zone operators should be more careful.


--Vladimir | knot-resolver.cz___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: New draft on collision free key tags in DNSSEC

[Vladimír Čunát]

I believe that such a draft is NOT worth all the implied human effort, 
I'm afraid.  The idea isn't new, but let me reiterate my points below.


Even if we forbid all keytag collisions, there will be many more ways 
how attackers may attempt to generate lots of work for validating 
resolvers.  (many RRSIGs, combination with CNAME chains, etc.)  I don't 
think such piecemeal approaches will really help, especially if they'd 
take many years to actually restrict the attacks.


I'm aware that this is close to a "slippery slope" fallacy, but all 
things considered, completely eliminating keytag collisions doesn't seem 
worth the effort to me.  On the other hand, note that bigger collisions 
are extremely unlikely (e.g. four keys, all with the same tag).  You 
want to minimize the DNSKEY set sizes anyway, due to space restrictions, 
so you can't really have dozens at once legitimately.


Strictly enforcing collision avoidance might complicate some less 
centralized use cases.  So such an RFC certainly isn't close to free or 
without risks.


--Vladimir | knot-resolver.cz
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: New draft on collision free key tags in DNSSEC

[Vladimír Čunát]

On 30/07/2024 09.41, libor.peltan wrote:
Anyway, it can realistically take decades before any new algorithms 
seize some good portion of DNSSEC. In other words, that flag day has 
already silently passed.


I don't think that's a helpful point in time.  I assume the main target 
of this RFC is defending against intentional DoS attacks, and the 
attackers will choose what's best for them.  That is, the usefulness 
horizon here would be when all other algorithms can be reasonably marked 
as unsupported by validators, so that's even further in future.  (but 
the achievable length is hard to predict, depends on motivation of 
various parties)


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

[DNSOP] Re: New draft on collision free key tags in DNSSEC

[Vladimír Čunát]

On 31/07/2024 15.29, Petr Špaček wrote:
Per-zone limit does not defend against resource exhaustion because an 
attacker can construct chain of delegations a.b.c.d.e.. and max 
out limit on each level. Then you instantly get about 126*(per-zone 
limit on validations) just for this particular attack vector. 


That's part of why I think the implementations need a different approach 
(than this RFC, too).  Attackers can combine.  Do these long delegation 
chains, and jump through several of them by CNAMEs, and put max. number 
of RRSIGs everywhere in a way that many fail, etc.


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

[DNSOP] Re: Light weight encrypted DNS proposal

[Vladimír Čunát]

Hello.
I think dprive fits the encryption topic better than dnsop?  Anyway, 
some quick thoughts below.


On 15/08/2024 00.06, Vint Joseph wrote:

using UDP and only one or two packets


I suspect that larger answers will be... a complication.

You could rely on UDP fragmentation, but in that case the amplification 
is unpleasant, as I don't expect a way of validating the client's IP.  
And fragmented UDP often can't pass through anyway IIRC, especially on 
IPv6.  (replay-ability might be OK)  Or would there be fallback on 
another encrypted protocol?



Crypto-agility: you assume that the client knows a public key, i.e. that 
implies the algorithm already.  In that case, you'd have a key that's 
hardcoded in configuration and basically never rotated?  Or you'd use 
some different transport to get the key by name?  (e.g. unencrypted DNS 
with DNSSEC validation, but such bootstrapping isn't very simple)  Or a 
more complicated handshake in case the key isn't known?



Overall I fear that a simple solution won't be able to give good 
properties, unless you just don't care about "edge cases".  I wouldn't 
standardize yet another transport unless it can be shown to give some 
"significant advantage".



--Vladimir | knot-resolver.cz
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis

[Vladimír Čunát]

On 7/25/19 7:44 AM, Evan Hunt wrote:
> [... TLD XFR] However, admittedly, one probably
> wouldn't want to do it for large zones, and I don't know of any TLD's that
> allow transfer in the first place, so for the purposes of the current
> discussion, you're right enough.

I know about .se (and .nu) providing AXFR, but I suspect it might not be
worth mirroring continually in this way, even for large Swedish ISPs.  A
related thing in .cz (where to zone is not public by a rule) is that
register-managed instances are running inside ISP networks and routing
ensures they are "separate" from public instances (against attacks), but
I'm digressing...

[.se] https://zonedata.iis.se/

--Vladimir

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

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

[Vladimír Čunát]

On 8/1/19 6:08 PM, Tim Wicinski wrote:
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.

I'm in favor of adoption.


I'm not sure if it's a good idea to suggest content changes in this same
thread already, but I suppose adoption itself will be easy to get
consensus about.
RDoT: I believe the wording should not exclude forwarding between two
resolvers (when neither is really a stub).  That seems actually a
relatively common use case for DoT.

--Vladimir

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

[DNSOP] Special-use TLDs in resolvers

[Vladimír Čunát]

Hello,

I've been wondering what's best to do around these TLDs: invalid, local,
onion, test.  The RFCs say that resolvers SHOULD recognize them as
special and answer NXDOMAIN without any interaction with nameservers (by
default).  What do you think about NOT following this "advice", subject
to some conditions that I explain below?

1. QNAME minimization (in the root at least), so that if e.g.
foo.bar.test. query arrives and the cache is empty, the resolver only
asks the root for test. and the rest does not leak.
2. RFC 8020 -style caching (in the root at least), so that we keep the
goal of reducing load on root servers.  Note that this is subsumed by
aggressive caching (RFC 8198), which should work for the root zone in
some commonly used resolvers for about a year already (I believe:
Unbound, BIND, Knot Resolver).

This pair of conditions seem quite reasonable defaults regardless of
special TLDs, in which case I'd argue it's better not to special-case
these four TLDs.  One advantage is that this allows supplying the
denials with DNSSEC proofs, which e.g. avoids problems in case the
client is missing some of these special cases and wants to validate. 
Well, that's arguably a relatively unlikely combination, but my
motivation is mainly that it feels nicer to remove them :-)

Reference RFCs for these TLDs, respectively: 6761.6.4.4, 6762.22.1.4,
6762.2.4, 6761.6.2.4

--Vladimir

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

Re: [DNSOP] Special-use TLDs in resolvers

[Vladimír Čunát]

On 8/16/19 3:10 PM, Ted Lemon wrote:
> If you look up “onion”, you have revealed that the user is trying to
> use tOR, even if you haven’t revealed where they are going.

Well, in this particular case the tOR client would probably better not
send onion queries to DNS resolver, but generally there would be a leak,
though the TTL is a whole day.  At least unless combined with one of the
"local root" schemes (which are so far not commonly deployed, I think).

> What’s the motivation behind this proposal?

As I wrote, supplying the answer with a DNSSEC proof seems better to
me.  And it makes my camel a tiny bit happier, I guess :-)  At that
moment I didn't realize that if you forward to a resolver that does
respect that SHOULD, you will not be able to obtain the proof in this
way and consequently regress, so the change would be double-edged in
this respect.


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

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

[Vladimír Čunát]

Hello,
authentication of blocking decisions is an interesting idea to consider,
though it's probably beyond the scope of this RFC draft.  Most
interesting cases can be already covered by securing the channels
between the first resolver that does blocking and the final stub.

On 9/4/19 2:31 PM, Vittorio Bertola wrote:
> There was also some discussion on whether these error codes could be 
> accompanied by a URL that the client device can use to display a 
> human-readable explanation to the user, which would be a cleaner solution 
> than the current practice of giving to the client a positive response, but 
> with the IP address of a local web server instead of the original one (a 
> practice that doesn't work well with HTTPS anyway). 

In Knot Resolver we've developed a habit of using additional TXT records
(independently of EDNS), e.g.

; <<>> DiG 9.10.3-P4 <<>> -x 10.1.2.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16584
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;3.2.1.10.in-addr.arpa. IN  PTR

;; AUTHORITY SECTION:
3.2.1.10.in-addr.arpa.  10800   IN  SOA 3.2.1.10.in-addr.arpa. 
nobody.invalid. 1 3600 1200 604800 10800

;; ADDITIONAL SECTION:
explanation.invalid.    10800   IN  TXT "Blocking is mandated by 
standards, see references on 
https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml";

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

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

[Vladimír Čunát]

On 9/12/19 8:10 PM, Viktor Dukhovni wrote:
> SERVFAIL means,  and will continue to mean, I can't help you, better luck next
> time (or elsewhere).
>
> The new EDEs are *diagnostic* detail to aid in troubleshoots, but do not
> override RCODEs.  They are not a more fine-grained RCODE one might "act on".
> If we want more fine-grained *actionable* codes, there's plenty of room for
> more values in the 12-bit EDNS RCODE.
>
> [ I chatted off-list with Wes, the above appears to match his take, with a bit
>   luck also rough WG consensus... ]

My understanding was that it was meant for resolvers to change e.g.
their retrying behavior based on the EDEs in some cases, even after
removing that "Retry flag".  I did consider that a significant part of
the (original) motivation, even we did not implement that in the first
prototype (as only server-side was done).

I certainly agree this issue should better be explicitly stated in the
final text.  At least assuming the WG consensus will be that they don't
want resolvers acting on the EDE codes in any way except for diagnostics
(possibly with RFC2119 qualifier).

--Vladimir

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

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

[Vladimír Čunát]

The following comments are only loosely related to multiple threads
here, so let me post them in a single bunch.

On 9/11/19 8:05 AM, Viktor Dukhovni wrote:
> Section 3.2 (code 2), may warrant more guidance on when this is
> appropriate.  AFAIK, there is nothing wrong with all DNSKEY algorithms
> being unsupported, provided the same holds for the DS RRset.  So,
> while I see a use-case for code 3 (all DS unsupported, perhaps to
> signal why the AD bit is not set, despite the non-empty DS RRset),
> I don't understand when one would use code 2.

I do fail to understand the split codes 1 and 2 for all DS/DNSKEY
algorithms being unsupported, and it actually makes me wonder how to
exactly write the resolver code that would set this pair.  For
validation I need at least one usable DS RR, i.e. one where *both* the
DS and DNSKEY algorithms are supported.  I believe that's the exact
condition to be able to extend the trust chain. (and that's how I
implemented it for Knot Resolver)  It may theoretically even happen that
there is a supported DS algorithm and a supported DNSKEY algorithm but
never paired together in the DS RRset - IIRC it's not perfectly correct
to generate such an RRset but that's probably not something a validator
should care for.


On 9/11/19 8:05 AM, Viktor Dukhovni wrote:
> Section 3.8 [...]
>
>So just *an* expired signature is not really a problem provided
>another signature for the same RRset is not expired.  So I think
>the text could more clearly read "but *all* signatures for an
>RRset in the validation chain expired", or some such.

Nitpick: *if* we were diving into such details... each RRSIG might fail
for a different reason, for example.  That's the general problem with
providing reasons for validation failures: validation is defined in the
sense that you (may) succeed when at least one of various ways
succeeds.  A failure could typically be fixed by multiple different ways
(EDE codes).  Still, I'd hope that in most real-life cases the
implementations can "correctly" guess what's wrong.


On 9/13/19 10:01 PM, Tony Finch wrote:
> 3.5.  Extended DNS Error Code 4 - Forged Answer
> 3.16.  Extended DNS Error Code 15 - Blocked
> 3.17.  Extended DNS Error Code 16 - Censored
> 3.19.  Extended DNS Error Code 18 - Filtered
>
> I don't understand the shades of meaning that these are supposed to
> distinguish.
>
> wrt "filtered", the description implies vaguely RPZ flavoured filtering,
> but it mentions a REFUSED RCODE which isn't what a sensible implementation
> would use for that purpose, so I am more confused.

With the switch to codes not specific to RCODE, I think some more
code-merging would be nice, in particular 3+19: stale (NXDOMAIN)
answer.  Perhaps also drop "4 forged" in favor of the other options?
(blocked, censored, if I understand the definitions)  Or is "forged"
meant for cases like the special top-level invalid. zone?


I think the current -09 "Security considerations" section is a bit
misleading.  It talks about the extended error being unauthenticated in
case of validation failure, but the current SERVFAIL is the very same
and that part is the more important bit (noticed by Paul Hoffman, too). 
With extended errors we only get more information of the same
authenticity.  In general, clients that don't want to validate
themselves can also choose a middle ground where they trust the resolver
and secure their link to it (typically by DoT or DoH).

Also, *if* the EDE codes will only be used for [diagnostics], I don't
really understand why have any "Security considerations" at all. 
Perhaps I'm just confused about the overall intention.
[diagnostics]
https://mailarchive.ietf.org/arch/msg/dnsop/rbkGvMH-vG-P5GHUx06-LRWYRgM


--Vladimir


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

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

[Vladimír Čunát]

On 9/24/19 12:36 PM, Tony Finch wrote:
> Petr Špaček  wrote:
>> IMHO the most useful information is dichotomy:
>>
>> a) the problem is local (= call network admin/ISP/telco)
>>
>> b) the problem is remote (= call your bank because their internetbanking
>> broke and _do not your bother ISP_).
> I think that's helpful.
>
> There's an interesting case wrt blocking / censorship, e.g. "near block"
> => ISP is responsible; "far block" => required by force of law.

And when *forwarder* returns that the domain was blocked (via this RFC)?

If we go this near/far way (and I would like that), I'd suggest that we
additionally try to polish the semantics for forwarding and caching,
i.e. how the errors might best bubble through these layers.  When a
resolver only talks to other resolvers, it currently can't often
determine whether the problem is in them or in authoritative servers -
it gets the same SERVFAIL, but perhaps if all layers support extended
codes and we design them well, it might be possible to "reliably" assign
blame to authoritative side in more cases.

Example: the authoritative servers don't reply at all (to the
forwarder), so possibly after trying a second forwarder with the same
result, we probably want to assign blame to the authoritative servers
and not to the forwarder.  Well, I'm a little sorry for suggesting such
a scope creep, but still...

--Vladimir

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

Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

[Vladimír Čunát]

On 9/26/19 12:30 PM, Jan Včelák wrote:

The current draft attempts to minimize complexity for implementers by offering a fully generic encoding for unknown key 
types.  For example, "alpn=h3" can also be expressed as "key1=h3", and "port=8003" can 
also be expressed as "key2=\031\067".  This encoding may not be convenient, but hopefully it will reduce the 
burden of supporting new parameter types.

I agree we need generic encoding. There is a way to express unknown
record types (https://tools.ietf.org/html/rfc3597#section-5) and the
syntax used there is more compact than what you propose. It uses hex
strings instead of escaped decimal values. However its clumsy to work
with records in that syntax and you proposal is better in that sense.


I'm curious, Is there much motivation for a bit more compactness of the 
*presentation* format?  I consider its design primarily meant for humans.



I think this may become the most complex record type we have in DNS so
far. None of the existing registered record types contain a list of
key-value pairs of arbitrary length. Given that there is also a
registry for key types involved it will be fun to implement the
encoder/decoder. But we will have to deal with it. I'm interested in
what others in this working group think.


I think we should get "implementation experience" from multiple parties 
at least before publishing the RFC (though that's a point far ahead, I 
suppose).


--Vladimir

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

Re: [DNSOP] draft-ietf-dnsop-extended-error status

[Vladimír Čunát]

On 9/30/19 11:47 PM, Warren Kumari wrote:
> On Mon, Sep 30, 2019 at 7:54 AM Tony Finch  wrote:
>> Difficult. In general there will be multiple upstream servers, even in
>> the simplest case of a stub talking to a recursive server talking directly
>> to authoritative servers. So there can be an arbitrary combination of
>> upstream errors, and they might not relate directly to the QNAME, (e.g.
>> problems with a parent zone, problems chasing down nameserver addresses).
> RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) speaketh thusly:
>
> "EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is
> negotiated between each pair of hosts in a DNS resolution process,
> for instance, the stub resolver communicating with the recursive
> resolver or the recursive resolver communicating with an
> authoritative server."
>
> and also sayeth:
> "OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from
> master files."
>
> I *think* that this covers the issue for many cases; EDE is not
> intended to be a silver bullet, more something which provides useful
> information for troubleshooting / debugging.
> We would not (and cannot :-)) preclude other work from further
> defining this, but I think that it's beyond the scope of this document
> / we will better be able to understand things once we've had some
> deployment experience.

My understanding is that the hop-by-hop condition is just the default
and as suggested we could define/allow e.g. that if all upstreams return
"filtered", we send the same downstream.  I expect we could first
publish RFC without propagation of these errors in mind, but there's a
risk that when we later want to add that, we'll need to make too big
changes, e.g. we may miss something like the near/far flag mentioned
earlier.

If we/you don't want to deal with the propagation now, reserving some
bits for future use (MUST zero now) might be a nice compromise, assuming
we at least have some vague idea that a few of them are likely to be
useful in future.  Another plan might be to do nothing now and later we
might: (1) define another EDNS0 extension that will *separately* carry
information in addition to this EDE or (2) define new flags within the
current EDE and utilize the allowance of sending multiple EDEs.  These
options sound a bit messier to me, but they seem doable.

--Vladimir

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

Re: [DNSOP] Call for Adoption: draft-nygren-dnsop-svcb-httpssvc

[Vladimír Čunát]

Hello; I do support adoption.

On 10/7/19 4:52 PM, Stephen Farrell wrote:

The main caveat for me is I don't know if it'd be worth
publishing an RFC if this doesn't end up getting deployed
in browsers. So getting clarity there as early as poss
would be good if we can.


I agree, but I wouldn't block *adoption* on that.  The "browsers" 
(client implementers) may have some comments on the contents of the text 
etc. and it seems much better to have one particular WG (and text) to 
discuss.  My understanding is that the authors had discussed with 
(some?) major implementers and they seemed inclined to like the 
approach.  (I heard that on some recent IETF presentations of HTTPSSVC 
plans, IIRC.)


--Vladimir

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

Re: [DNSOP] [Ext] Re: Working Group Last Call for draft-ietf-dnsop-7706bis

[Vladimír Čunát]

On 11/1/19 1:26 AM, Paul Hoffman wrote:
> On 10/31/19 6:10 PM, A. Schulze wrote:
>> editorial note: Appendix B2 and B4 are mostly the same.
> Mostly, but not exactly. Folks asked us to add B4 because of the new features 
> in BIND 9.14. Is this still what the WG wants?

New features in Unbound 1.9, you mean? (looking at 7706bis-05, B2 and B4)

They don't seem that similar to me, and it's good to have both
*somewhere*.  The new one is significantly simpler, and older Unbound
versions will "keep living" for many years, I'm afraid.  (say, CentOS
8)  Still, I can't see a problem in replacing either or both by a
stable-enough link, especially if that simplifies finding how to do it
in any (future) version.

--Vladimir

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-02.txt

[Vladimír Čunát]

Hello!

On 10/28/19 10:32 PM, Wessels, Duane wrote:
> The one defined hash algorithm SHA384 has been renamed to SHA384-STABLE to 
> reflect that it designed for use on stable (or small) zones where it is not 
> burdensome to recalculate the digest over the entire zone data each time.

Tiny nitpick: calling it "SHA384-STABLE" might be a tiny bit confusing
(to me), as I've seen that word refer to some particular hashing
approaches/properties.  Actually some of the algorithms that efficiently
recompute after small changes in large zones... I'd even tend to call
those digests (more) "stable"/"steady" intuitively, but that might be
personal :-)  I certainly don't have a strong opinion on the naming and
don't want to bike-shed, but I could imagine calling it "simple" or
"flat" or something along those lines.

[example] https://en.wikipedia.org/wiki/Stable_hashing

--Vladimir

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

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Vladimír Čunát]

On 11/14/19 12:05 AM, Viktor Dukhovni wrote:
> It'd be a shame (though admittedly not frequent) to have a resolver
> retry over TCP just to get the same answer with additional information
> it does not need and perhaps does not even understand.

EDE codes themselves take very little space, so truncating just the
textual messages might be a good middle-ground but I certainly
haven't tried thinking of all implications on EDE truncation yet. 
Communicating these through bit(s) in EDE or EDNS flags might be nice,
and clients might even use them to set their preference.

Still, ATM I can't clearly see whether such TC details would be useful
in practice.  I think we're fortunate that most use cases for EDE are
failures... so the answer will probably be tiny.

--Vladimir

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

Re: [DNSOP] On .ZZ

[Vladimír Čunát]

On 11/21/19 8:26 AM, Paul Wouters wrote:
> for example if ICANN delegates .zzz there will be interesting typo attacks 
> possible in this weird private space

In this respect .zz is at least better than .xx which was among the
suggestions.

> Finally, I agree. People want something semantic and more pronounceable.

I don't think it's possible to satisfy completely all potential use
cases with a single name.  Desire for being short was also stated by
multiple people.  For semantic and pronounceable options we already have
myDomain.com - which has additional benefits like being able to work
globally.


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

Re: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback

[Vladimír Čunát]

On 12/6/19 11:43 PM, Eric Orth wrote:
> Section 1.3: Compared to previous drafts, not much value anymore in
> SvcFieldPriority being a first-class field outside SvcFieldValue. [...]

There's still advantage for resolvers implementing the chain-jumping
(Sec. 4); it allows them to avoid looking inside SvcFieldValue.  That
might indirectly help the overall deployment, as that feature seems to
be desired a lot (on this list).

--Vladimir

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

Re: [DNSOP] Last Call: (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice

[Vladimír Čunát]

On 12/16/19 10:39 AM, Stephane Bortzmeyer wrote:
> Do we agree that Knot is wrong and the draft is right? Or is FORMERR
> acceptable?

The discrepancy should disappear eventually:
https://gitlab.labs.nic.cz/knot/knot-dns/commit/2b31ee57a7c

I personally do have occasional issues finding out which RCODE is
appropriate for some error situations.

Thanks
--Vladimir

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

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

[Vladimír Čunát]

On 1/7/20 3:15 AM, Michael StJohns wrote:
>>>
>>> 1) A recommendation for the maximum size of the zone [...]
>> I am reluctant to add this.  As John said, I think it won't age well.
>> [...]
>
> As I suggested in one of my messages, giving an idea of how long it
> takes to digest various sizes of zones given commodity hardware would
> be a good start. [...]

Well, if you include particulars in those performance examples: BIND
9.X, zone size Y, CPU Z.  But to me this doesn't seem very suitable for
a static document like RFC standard, and I'd primarily want to see such
examples in docs of the servers, as there they can be kept up to date. 
Still, I see no real harm in putting some performance example(s) into
RFC appendix, and they may just become irrelevant over time.

--Vladimir

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

Re: [DNSOP] SVCB chain lengths

[Vladimír Čunát]

On 12/23/19 9:22 PM, Eric Orth wrote:
> 2) Any chain limiting enforcement only applies to stubs following
> chains, not recursives.
>
> Recursives are already following CNAMEs without a standardized limit.
> [...]

(I'm a bit late, I'm sorry.)  Recursives *in practice* seem quite
limited.  Unbound has limit of 10, for BIND it's less than 20, I think. 
OK, for SVCB the suggested limits so far were lower than 10 (or
unspecified/unlimited).  This is one of the cases where it seems quite
difficult to agree to standardize a particular number, even though
"unlimited" doesn't make any sense, and we end up in a fuzzy state where
no particular guarantees get standardized (or followed).

--Vladimir

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

Re: [DNSOP] DNS stamps

[Vladimír Čunát]

These stamps do contain interesting ideas, I believe.

On 1/9/20 5:13 PM, Ted Lemon wrote:
> In order for this to actually be useful, two things would be required.
>
> 1. The assertions about resolver behavior (e.g., logging, etc) would
> have to be signed
> [...]

Depends what you'd want from the stamps.  If the main point is to
configure by an URI that's easy to copy&paste, I don't think you really
need these details.  I imagine you'd copy it from an https site of the
operator or got through another trusted (chain of) means.  And I'd
certainly not expect binding such format to some legal mechanisms,
etc... perhaps you could just add policy and some "small print" legalese
to that site as well.

Someone would need to "author" it here.  I don't expect DNSCrypt people
to push it forward within IETF.  I'm not sure what would happen if WG
decides to change the format in an incompatible way, but perhaps that
could be avoided.

BTW, do we want to keep this (whole) thread in *both* mailing-lists at once?

--Vladimir

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

Re: [DNSOP] DNS stamps

[Vladimír Čunát]

On 1/9/20 6:37 PM, Ted Lemon wrote:
> On Jan 9, 2020, at 9:21 AM, Vladimír Čunát  <mailto:vladimir.cunat+i...@nic.cz>> wrote:
>> Depends what you'd want from the stamps.
> If the stamps make assertions about what service is offered, I’d want
> that to be verifiable.  [...]

I'd personally have stamps without these assertions (or without giving
them any weight).

I see a bigger problem that some of desired assertions are in principle
unverifiable, e.g. "no logging".  Of course, we could (optionally)
extend the string by a signature, but I suspect that'd increase the
length a lot without sufficient gain in exchange.


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

Re: [DNSOP] rrserial as a path to fame and fortune (was: Adoption of new EDNS opcode "rrserial")

[Vladimír Čunát]

Hello.

On 1/29/20 11:57 AM, Shane Kerr wrote:
> One possible application of this might be to allow a resolver to
> extend the TTL of an entire zone.

Overall I suspect the TTL-extending use case might be sufficiently
different (and much more complicated) to consider separately/independently.


> As far as the wire format & protocol behavior, I think the changes
> from this draft needed would be:
>
> * Returning the entire signed SOA in the additional section, rather
> than just the serial in an EDNS record (for DNSSEC validation purposes).
> * Including an EDNS option in the response indicating that it is okay
> for a resolver to extend the TTL of other records in the zone

I haven't thought that much about it, but I'm not convinced that
validating the SOA (serial) would really help.  The main related problem
I see is signature validity of the records that get extended, i.e.
all/any of them and not just SOA.

As long as RRSIG of an RRset holds, resolvers can be "spoofed" to serve
that RRset, regardless of original TTL... so why would the attacker
bother to spoof SOA serial instead?  On the other hand if RRSIG expires,
I don't think even validating SOA serial would be enough to keep serving
this RRset, as e.g. downstream couldn't validate it normally.


> Even just using SOA in the response instead of the serial in an EDNS
> record would be enough to allow later work on the TTL-extending
> technique, if we're squeamish about adding to the DNS camel. 😊 

In suitable zones (e.g. root) I can imagine the resolver explicitly
querying for SOA in order to extend all the TTLs (though not beyond
RRSIG validity).  Still, generally there needs to be at least some way
for zones to opt out from any such TTL-extending technique.

Maybe utilizing ZONEMD should be considered instead.

--Vladimir

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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Vladimír Čunát]

On 2/21/20 1:04 PM, Klaus Malorny wrote:
> according to my colleagues, who are in contact with the customers, the
> use case is mostly in the context of CDNs. Some of them maintain a
> larger set of domains with alternate spellings of their product names,
> with different ccTLDs, some for promotions etc. The content for these
> domains are hosted by CDNs and not by us (we are not in that business
> right now). They want their domains to work also without a "www."
> prefix, and for now we use a web redirection service. This has some
> disadvantages, e.g. a "heavy" extra roundtrip to an HTTP server and in
> respect with HTTPS support. So our problem is exactly the "CNAME in
> the apex" problem. HTH. 

To me that sounds exactly like one of the main points addressed by
HTTPSSVC (draft).

--Vladimir

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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Vladimír Čunát]

On 2/21/20 2:23 PM, Klaus Malorny wrote:
> I see a major drawback in comparison to the ANAME draft, namely that
> there seems to be no fallback for old browsers (and robot software
> accessing websites) being defined. Of course, authoritative name
> servers could implement a similar mechanism as specified in the ANAME
> draft. The question would be whether it needs to be addressed in the
> HTTPSSVC/SVCB specification in an appropriate manner.

My understanding of the plan is that for fallbacks we'll have what
people are using now, e.g. that http redirect.  Perhaps you can
elaborate on why that doesn't seem sufficient.


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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Vladimír Čunát]

On 2/21/20 3:01 PM, Klaus Malorny wrote:
> simply that I want to get rid of it. IMHO one aim of a new technology
> should be to make old technology obsolete, esp. such workarounds. If I
> have to keep them (forever?), where is the benefit (for me as a company)? 

I see.  You'd like to deploy something like the apex CNAMEs one-sidedly
without workarounds (just on authoritative DNS servers).  That's
basically what the proprietary flattening schemes do today.

In this case however, I personally believe it's much better design *not*
to put the link-following work on authoritative servers (or their
provisioning) but further down the chain (resolvers and/or clients). 
Well, I suppose I don't really want to open a long thread around this
topic again :-)

Your question: the benefit I see is that you make the processing
"better" for up-to-date clients, if I simplify it.  I think the browser
side will generally be well-incentivized to deploy httpssvc support
relatively widely/quickly (compared to usual DNS pace).

--Vladimir

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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Vladimír Čunát]

On 2/25/20 8:07 PM, Andrew M. Hettinger wrote:
> Frankly, you've got it exactly the wrong way around: even with httpsvc
> speced out completely, it will take time for it to be deployed to
> browsers. That's assuming you can get enough buying from (mostly)
> google to even make it happen at all.

I don't think it's so simple.  The current ANAME draft specifies new
behavior for resolvers, and there I'd expect even slower overall
upgrades/deployment than in browsers.  Also I'm unsure how big a part of
authoritative implementations will want to do ANAME expansion.  (It
seems unlikely for "our" Knot DNS, for example.)

Of course, none of this will really prevent anyone from deploying it,
even though it won't be ideal, e.g. often without more precise answers
due to non-supporting resolvers.  Clearly we do have deployments even
now :-)

--Vladimir

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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Vladimír Čunát]

On 2/26/20 11:28 PM, Andrew M. Hettinger wrote:
> Is there actually a commitment from browser makers to implement it?
> [...]
> But let's be clear, the biggest group that we need buy-in from are the
> chromium devs. Without them, this isn't worth the bits we've sent down
> the wire discussing it.

Sure; this topic recurs once a while.  There were more parties, but I'm
lazy so I'm only sending one reference for Chrome/ium:
https://mailarchive.ietf.org/arch/msg/dnsop/eAyMNJkPMLYrQ--ItMTM9wV94kg/

I really appreciate that the HTTPSSVC authors put effort into working
with multiple client vendors from the very start.


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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Vladimír Čunát]

On 2/27/20 4:51 AM, Lanlan Pan wrote:
> [...]
> Just configure ANAME in the zonefile,  authortitative return response
> is CNAME, no ANAME.
> If enable DNSSEC, this will cause some dynamic signature
> calculation（ECDSA will be better).

I would (generally) NOT recommend sending CNAME in answer in case of a
zone apex.  From my point of view, one of the main reasons for all the
ANAME variants is that *this* is causing problems, although it kind-of
works in many cases.


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

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

[Vladimír Čunát]

On 2/28/20 2:02 PM, Ines Robles via Datatracker wrote:
> 1- Appendix B.5: it seems that the link is not valid: resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc-
>7706>
>
>   This link worked for me:
>   https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html.

Yes, thank you.  We did some restructuring in the documentation that
changed links to the "rolling" versions.  If stability of the links is
preferred to being up to date, it's possible to switch to e.g.
https://knot-resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html
We expect such links to remain alive for veeery long time (unless the
ReadTheDocs service prevents that in future in some way).

--Vladimir

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

Re: [DNSOP] New draft on delegation revalidation

[Vladimír Čunát]

On 4/22/20 9:32 PM, Shumon Huque wrote:
> Since delegation records and glue address records are unsigned, they
> can be spoofed, and DNSSEC should really allow us to detect such
> spoofing once a resolver sees referral data.

I wouldn't put much energy into improving this part in *this* draft. 
Even DNSSEC-validated NSs and IPs aren't sufficient to ensure privacy,
so I'd rather kill this problem by proper encrypted protocol towards
authoritatives (in current dprive charter).

--Vladimir

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

Re: [DNSOP] Privacy and DNSSEC

[Vladimír Čunát]

Original subject: New draft on delegation revalidation

On 4/24/20 4:49 PM, Shumon Huque wrote:
>
> Even DNSSEC-validated NSs and IPs aren't sufficient to ensure privacy,
> so I'd rather kill this problem by proper encrypted protocol towards
> authoritatives (in current dprive charter).
>
>
> DNSSEC of course does not address privacy, that much is clear.
> But I don't think I agree that encrypted transport addresses the
> data authentication issue here. [...]

Of course, I didn't mean to imply it would allow us completely dropping
DNSSEC.  By the way, using DNSSEC to anchor the chain to "DNS privacy"
makes most sense to me (even webPKI don't help you with getting the
"right" hostname/SNI).

Still, note that for some consumers the secure transport may be an
argument to drop validating DNSSEC themselves.  If they choose some DNS
provider that they trust with privacy (it might be their ISP), it seems
not a huge leap to trust them with DNS integrity as well (say, the
provider doing DNSSEC validation).  Especially as today "regular users"
don't get that much benefit from validation, mostly relying on
https/tls.  Some of them also want a variant of DNS filtering, which
still clashes with validation a bit (if done *after* filtering).


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

Re: [DNSOP] Validating responses when following unsigned CNAME chains...

[Vladimír Čunát]

On 4/30/20 2:01 AM, Shumon Huque wrote:
> It definitely can't set the AD bit. So, I suppose your argument is why
> bother authenticating the target. That's a defensible question. [...]

Certainly not defensible.  The AD bit isn't the only part.  What if the
CNAME target is spoofed (BOGUS) or something?  Actually, I believe most
end-clients don't look at AD, so it's just the SERVFAILs that protect
them from using spoofed data.


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

Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt

[Vladimír Čunát]

Hello, I'm still a bit skeptical.

1. Validation without logging.
At the end of 3.1 you claim that mode is still useful.  When I focus on
intentional attacks, signing a malicious DS seems among the easiest
ones, and that can't be detected without the attacked machine doing
logging (the DS might be served to specific targets only).  Consequently
I'm doubtful about implementing and deploying such a "half-secure"
approach in validators, especially as the RFC draft feels very hazy
about the way logging might be done.

2. Amount of logging.
The draft implies it would allow to very significantly decrease the
amount of data that needs to be logged.  Zones without the bit perhaps
won't be logged, but I hope that wasn't a significant point.  The draft
doesn't explicitly say what would be logged; my conclusion for zones
using this bit is that "we" would need basically any authoritative (i.e.
signed) data except for NSEC* records that have DS bit and miss opt-out
bit.  Am I missing something?  As for large TLD zones, even in best
currently practical case the reduction seems by less than a half? 
(missing DS bits in about half delegations) I expect that the whole
trust chains to the logged records are also needed, so that the logger
can prove they haven't forged the records.

--Vladimir

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

Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt

[Vladimír Čunát]

On 5/7/20 6:06 AM, Paul Wouters wrote:
> On Tue, 5 May 2020, Vladimír Čunát wrote:
>> 1. Validation without logging.
>> At the end of 3.1 you claim that mode is still useful.  When I focus on
>> intentional attacks, signing a malicious DS seems among the easiest
>> ones, and that can't be detected without the attacked machine doing
>> logging (the DS might be served to specific targets only).
>
> Serving to specific targets is getting harder and harder, because we
> see more and more people defaulting to not use their DHCP obtained DNS
> server. And when picking another non-local server, DoH or DoT is
> preventing man in the middles from replacing DS records in responses.
>
> So they would either have to publicly replace the DS for everyone, or
> add a DS for everyone. That becomes a very visible event.

If they lie to your resolver, they replace it for everyone sharing the
same cache (for TTL duration).  So you say that people should hope that
someone else will also obtain the same "forged" DS by chance (say,
thanks to caching) and log it?  Perhaps it is an improvement... but in
me personally such a setup would not inspire confidence.

Speaking of non-DHCP DNS servers, if their provider promises to do all
the DELEGATION_ONLY validation *and* logging (and we authenticate their
servers, e.g. via TLS), that mode would actually make sense to me.  It's
a bit similar to trusting your DNS provider with DNSSEC validation and
not repeating it locally (though I personally prefer to do it again when
forwarding), but the tradeoff seems better here: security severity is
lower than bogus records and the logging surely won't be as cheap and
simple to deploy.


>>   Consequently
>> I'm doubtful about implementing and deploying such a "half-secure"
>> approach in validators, especially as the RFC draft feels very hazy
>> about the way logging might be done.
>
> This draft is not trying to specify the DNSSEC logging. But I described
> things in earlier messages already. The way we had our experimental
> logging done with Linus Nordberg, is that we used dnssec-chains (RFC
> 7901) as the record format for the DNS data, wrapped in the regular
> append-only style transparency log using merckle trees.

Perhaps it's just me, but I'd expect the RFC to contain a plan on *what*
would be logged, in connection to the security assurances this should
get us (without most of the technical details on how to do the logging
exactly).  I think you mostly confirmed what would be logged below.


>> 2. Amount of logging.
>> The draft implies it would allow to very significantly decrease the
>> amount of data that needs to be logged.  Zones without the bit perhaps
>> won't be logged, but I hope that wasn't a significant point.
>
> Right. Anything without DNSSEC cannot be helped.

To be clear, I meant the proposed DELEGATION_ONLY flag, but that
sentence doesn't seem important.


>>   The draft
>> doesn't explicitly say what would be logged; my conclusion for zones
>> using this bit is that "we" would need basically any authoritative (i.e.
>> signed) data except for NSEC* records that have DS bit and miss opt-out
>> bit.  Am I missing something?
>
> You would need to log the DS, and possibly log the denial of existence
> of the DS record. If the delegation-only bit it set, you can further log
> anything that should not have been signed but was signed, so any records
> outside of the apex that are signed. But this data is already dropped
> by supporting validators as BOGUS, so those hooks could be used for
> logging it. It should not be common. As soon as you see any of this,
> the zone is basically malicious and a public inquery should be started.
>
> As for opt-out, again zones without DNSSEC cannot be helped. Zones with
> DNSSEC, you log the DS and the denial of existence of DS.
>
> When to log this is a bit similar to the CT gossip protocol that was
> proposed. You log things when you see a modification (no-DS to DS or
> visa versa, or old-DS to new-DS). But that is outside the scope of
> this draft.

OK.  Nit: I'd expect that in practice most breakages would be
unintentional non-malicious errors, but they should still be only a tiny
fraction of all logged data (I hope).


>>   As for large TLD zones, even in best
>> currently practical case the reduction seems by less than a half? 
>
> You are missing the point that currently resolvers cannot determine if
> a TLD is delegation-only. For example, if you assume all TLDs are
> delegation-only, you break things, such as .de where registrations can
> be done without NS record, straight signed by the .de key. The point of
> the DNSKEY DELEGATION_ONLY flag is to indicate that yes

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

[Vladimír Čunát]

On 5/12/20 3:24 AM, John Levine wrote:
> It doesn't seem like a bad idea but I'm wondering who's likely to
> implement it, since that makes it much more interesting.

Knot DNS has an implementation already.  It's not merged and can't
create catalog zones yet, but we expect to support it in future.

I also see three other open-source server vendors among authors, so that
might give you an idea, but I can't speak for them :-)

--Vladimir

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

Re: [DNSOP] DNSSEC actual failures log where?

[Vladimír Čunát]

On 5/14/20 4:50 PM, Bob Harold wrote:
> I am preparing to enable DNSSEC validation, so I am working on alerts
> for failed validations, so I can see whether they are user errors
> (that might need negative trust anchors or other exceptions) or actual
> attacks.
> But it seems that the "dnssec" category logs all sorts of DNSSEC
> issues, even if the response validates correctly.  Is there something
> that I can match on to get just the responses that fail? (user gets
> SERVFAIL instead of an answer) ?

That's a question specifically for BIND 9.11, right?

In any case, there's a module in Knot Resolver just for this:
https://knot-resolver.readthedocs.io/en/stable/modules-bogus_log.html

--Vladimir

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

Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)

[Vladimír Čunát]

Hello.

On 5/28/20 10:00 AM, Shane Kerr wrote:
> As I have mentioned several times on microphone, I think this draft
> has huge potential, potentially cutting the number of queries handled
> by recursive resolvers almost in half - since they could ask for A and
>  records in a single query. 

I'm not sure if it would be a net benefit if we consider the added
complexity (like the few unpleasant corner cases), the need to implement
on both sides, and other ways that are available.  Is saving the number
of IP-layer packets the only significant motivation?

For resolver-to-auth case I do suspect some potential.  Plain UDP will
probably still stay popular there for some time.  Though I'm afraid this
might _sometimes_ push the answer sizes too large to fit into one packet
(in signed zones), which in my eyes slightly reduces attractiveness of
the technique, now that we know that UDP over 1.5 kB is no good.

For non-auth cases, you typically communicate with just one upstream
resolver (or very few), so if the number of packets is a concern, I'd go
for a long-lived TCP or TLS connection (there's e.g. privacy motivation,
too).  That's all standardized already, and it naturally avoids those
extra corner cases.  Sure, it's probably possible to improve
significantly on session timers and resuming, performance, usage of
Nagle's algorithm, etc. but ATM to me that feels a more worthwhile
investment than any of the multi-answer proposals.  One advantage is
that many of the TCP/TLS improvements can be deployed one-sidedly with
some effect but multi-QTYPEs can't.

--Vladimir

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

Re: [DNSOP] DNS RR Type Allocation Request

[Vladimír Čunát]

On 6/16/20 11:05 PM, Brian Dickson wrote:
> Nit: I think this should be "code points" (plural), one for HTTPS and
> one for SVCB, right?

There's even a new registry to be added.  Whole IANA section should get
"executed", I expect.

--Vladimir

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

Re: [DNSOP] Algorithm implementation recommendations in 8624

[Vladimír Čunát]

On 6/17/20 8:30 AM, Mats Dufberg wrote:
>> I wonder if there is a way to extend 
>> https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
>>
>> to add signing/validation recommendations.  This seems "hard" from
>> the world of IANA, but I'm not an expert.
>
> What strikes me is that IANA has no reference to RFC 8624 and that
> IANA still seems to consider SHA-1 and GOST to be algorithms to be used.

According to that last RFC, GOST in particular MAY be supported in
validators, but there are others.  Maybe the "Zone Signing" column in
the registry is not meant to represent whether an algorithm has been
obsoleted but just the purpose?  Or did "we forget" to add IANA section
into that RFC?  (I'm no good around these process-related knowledge.)

In any case, it would be nice from my perspective if the table could
contain... basically the table from the RFC.

--Vladimir

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

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

[Vladimír Čunát]

On 6/18/20 7:22 PM, Ted Lemon wrote:
>> I suspect it will work like every other locally-served domain or
>> every other private namespace that exists today, i.e. just fine with
>> no configuration changes expected or required on dependent
>> (downstream) DNS clients. And if there are new species of resolver
>> that need to be accommodated (e.g. validating, hybrid stub/full
>> service resolvers embedded in applications), whatever configuration
>> or auto-discovery mechanisms are required to support those other
>> locally-served zones can surely be easily extended to these
>> ISO-3166-2 codes if they are used in any particular private network.
>
> What I’m getting at is that the secure denial of existence will mean
> that a DNSSEC-aware resolver, when asked to look up a name under .xa,
> for example, will always return NXDOMAIN.

Yes, but squatting is usually done at root names already, so the issue
isn't new.

Modifying DNS past the last validator is generally troublesome. 
Modifying it inside the last validating resolver can be fine, as the
implementation can "prioritize" the modifications over validation and
aggressive caching (but as an implementor I still find this troublesome).

--Vladimir

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

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

[Vladimír Čunát]

On 6/19/20 6:20 AM, Martin Thomson wrote:
> As long as the space of codepoints isn't too small (2^16 is fine), then I see 
> no reason not to allow external publications request a value as long as they 
> don't abuse the privilege.

The space for DNSKEY and DS algorithms is one octet, so each of the two
registries has remaining space for around 250 algorithms and thus we
can't be "too wasteful".  Still, I wouldn't expect too many to want a
code point, so perhaps it could be optimistically started and only
restricted if getting too much popularity.

Ref. e.g. https://tools.ietf.org/html/rfc4034#section-5.1

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

[DNSOP] draft-ietf-dnsop-delegation-only​: exchanging DS set

[Vladimír Čunát]

Hello dnsop.

Let me start a simple thought experiment - attacking the planned
scheme.  It feels like I'm missing some part of the defense.

A .evil registry is using the DELEGATION_ONLY flag.  They additionally
sign a different victim.evil DS set, say adding hash of a DNSKEY they
generated themselves.  Now they could serve it e.g. to specific targets,
allowing .evil to control contents of the victim.evil subtree as seen by
those targets.  The defense against this will be logging!  So this DS
set along with its proof chain should get logged by some of the targets.

So far it's been clear.  But now... how do we know that this fake
victim.evil DS set was not submitted by the registrant?  I assume every
registrant is supposed to watch the logs from everyone for such fakes? 
Sounds OK-ish, so if they do find an incorrect set, they know that the
registry is "bad" (intentionally or not), but how can they prove *to
anyone else* that they did not submit it to the registry?

Without that ability I'd still feel quite powerless as a registrant, and
I currently can't see a nice way of solving that.  It would be nice if
there was a way we could get the ability in future (for reasonable costs).

- - -
I do support the aims of the draft, but so far the plan doesn't make me
feel safer, and deploying *all* the necessary parts doesn't seem very
easy either.  I'm sorry if I've missed something.  Well, *my* trust
isn't really important here, so if dnsop thinks the approach will
increase trust of some more important parties...

--Vladimir

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

Re: [DNSOP] draft-ietf-dnsop-delegation-only​: exchanging DS set

[Vladimír Čunát]

On 7/31/20 2:34 PM, Paul Wouters wrote:
> The process of a rogue parent is not a purely technical one. It can include a 
> legal system, a payment dispute, and many other things.
>
> Per definition, it will be a manual process to confirm if a “changed child” 
> is a legitimate change or not. Logging helps this process.

Right, I didn't fully realize that it's impossible to achieve that much
by technical means.


>> I do support the aims of the draft, but so far the plan doesn't make me
>> feel safer, and deploying *all* the necessary parts doesn't seem very
>> easy either. 
> All the necessary parts is one bit and a few lines of code and a tool option. 
> It’s not that much. The real work happens by log operators.

I considered logging among those "necessary" parts, which might've been
a bit of black&white point of view.


>> I'm sorry if I've missed something.  Well, *my* trust
>> isn't really important here, so if dnsop thinks the approach will
>> increase trust of some more important parties...
> Forcing parents into mucking with their customer DS records itself is a big 
> win. The parent now has an Enigma Problem and is more or less guaranteed to 
> be found out it’s cheating it’s own published policy.

Thanks, I think I see better now - so these are gradual steps to make
this kind of "attacks" harder but never able to completely eliminate
them (unfortunately).

I agree this RFC (without logging) appears relatively cheap, so if it
can improve trust, I expect the main stumbling point is willingness of
important zones to deploy it (which could include some technical
obstacles) and that should be better explored before publishing as RFC. 
Right now I can't see a better first step towards this draft's goal than
the draft itself.


Detail: removing that exception for the root might be nice.  That sounds
possible if the root KSK lifetime really becomes only a couple years
(which I haven't seen promised yet).  As long as the exception is there,
the paragraph about the root rollover feels weird.

--Vladimir

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

[DNSOP] draft-hoffman-dnssec-iana-cons

[Vladimír Čunát]

Hello.

I didn't speak but I'd still like to indicate my support.  Requiring
"Standards Action" just to allocate algorithm numbers seems quite an
overkill.  I'd find it healthy to split that into an easier step, so
it's also clearly separable from endorsing or even requiring support for
those algorithms (documents like RFC 8624).

Behavior with unsupported algorithms isn't ideal but it's specified and
seems OK to me.  People signing with less supported algorithms will
naturally be put at a disadvantage, but they do know the tradeoff
beforehand.  And... without allocated numbers you don't really want to
deploy the algorithm in validators, so it's a bit chicken-egg situation.

--Vladimir | Knot Resolver dev.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-00.txt

[Vladimír Čunát]

Hello.

I think the draft should also mention glue *addresses*, as that's
another closely related piece that often comes from the parent side (and
is also unavoidable to use in some situations).  Even if that means not
really recommending anything about them, though I'd personally expect
these to be handled similarly to NS records.

I'm not really sure if the whole draft is a good thing, but maybe that's
due to not experiencing the difficulties to update records in a way that
wouldn't need or even benefit from this draft (me being resolver
developer and indirectly operator).  Maybe it would generally be helpful
to expand the motivation section around the topic of why this is so
difficult that it's worth a standards-track RFC.

I'm also a bit puzzled... if the RFC won't make any *hard* requirements,
zone operators still won't be able to rely on the specified behavior
(n/ever perhaps), so can this still help them noticeably?  (I may have
missed this discussion, so point me there.)

--Vladimir | Knot Resolver dev.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-00.txt

[Vladimír Čunát]

I'm sorry for the delay.

On 11/19/20 8:47 AM, P Vixie wrote:
> On Tue, Nov 17, 2020 at 09:32:09AM +0100, Vladim??r ??un??t wrote:
>> I think the draft should also mention glue *addresses* [...]
> do you mean where the NSDNAME is in-zone and there is a non-authoritative
> copy of the  or A RRs held in the parent zone for delegation purposes,
> but which might have a lower TTL than the authoritative in-zone copy of the
> same data? i feel sure that the draft's co-authors would agree that this is
> an omission in the older resimprove draft and should be corrected here. it
> raises a grandparent edge condition (some server is authoritative for both
> the parent and the child) but in this case the revalidation will just fetch
> authoritative (high-TTL) data and be satisfied.
>
> in the more common case where the NSDNAME is in some other zone altogether,
> the only revalidation that could come into play is for that other zone's
> delegation, which might never be learned by a full resolver. what do you
> think is the right way to revalidate that information? (what triggering
> TTL interval would be used? and should missing delegations be discovered
> for this kind of glue so that they can be revalidated as specified?)

If it belongs into another zone, I think it should be "revalidated" in
that other zone (whatever you choose "revalidation" to mean) - I don't
see how it matters that I use the record somewhere else.  Resolvers
should accept parent-side (i.e. unauthoritative) data only if they
belong to bailiwick of the auth which sent the data, so I think in
practice it's just about descendant zones.


>> I'm not really sure if the whole draft is a good thing, but maybe that's
>> due to not experiencing the difficulties to update records in a way that
>> wouldn't need or even benefit from this draft (me being resolver
>> developer and indirectly operator).?? Maybe it would generally be helpful
>> to expand the motivation section around the topic of why this is so
>> difficult that it's worth a standards-track RFC.
> there are two use cases, the first of which is difficult to make compelling
> to a non-security audience. takedown is vital, and must be instant. the
> publishers of malicious DNS information only need a few minutes of uptime to
> complete most crimes, and even intervals less than a minute are adequate for
> some such crimes.
>
> second, when an error of omission occurs during a renumbering or rehoming
> event, and now-stale DNS data is harmful in a way that only time can fix,
> being able to trigger a distributed "rm -rf" of that data using the parent
> delegation is far better for all parties than waiting what may be hours or
> days for the stale data to expire naturally.
>
> i hope that one of the draft's coauthors can simplify that explaination and
> make it clear and compelling.

I assumed the issues around ghost domain names are well known, though
maybe not documented in any RFC.  That's the parts when the child-side
records (and transitive delegations) should not be allowed to live "too
long".

My question was focused on the case why the RFC requests to avoid (the
possibility of) using the *parent*-side data all the time - naturally
just in cases that don't include putting them into resolver answers, but
typically noone asks resolver for nameserver records and addresses. 
Your "second" (paragraph) doesn't seem to explain that either.


>> I'm also a bit puzzled... if the RFC won't make any *hard* requirements,
>> zone operators still won't be able to rely on the specified behavior
>> (n/ever perhaps), so can this still help them noticeably??? (I may have
>> missed this discussion, so point me there.)
> it can say SHOULD but not MUST, because not doing it will never be incorrect,
> owing to the older implementations who don't do it. it's desirable in that
> it will do more good than harm for both the zone and resolver operators,
> but still opportunistic from a protocol correctness point of view.

OK, I guess.  I assume you meant this mainly for the take-down parts
which I wasn't intended to ask about, but...

--Vladimir | knot-resolver.cz

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

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

[Vladimír Čunát]

Hello.

From resolver point of view... this implies that signed *positive* 
wildcard answers will now get cached with this shorter "negative TTL", 
right?  These do need to deny existence of non-wildcard match, so they 
need to contain NSEC*.


Maybe the final text would better explicitly note such implications, but 
that certainly can wait way past WG adoption. Also it might be confusing 
that just by singing a zone the effective TTL of these answers would get 
lower - assuming I got your intention right (if not, perhaps the current 
text wasn't clear enough anyway).


--Vladimir @ Knot Resolver


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

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

[Vladimír Čunát]

On 1/6/21 9:01 PM, Peter van Dijk wrote:

On Sat, 2020-12-12 at 11:46 +0100, Vladimír Čunát wrote:

  From resolver point of view... this implies that signed *positive*
wildcard answers will now get cached with this shorter "negative TTL",
right?  These do need to deny existence of non-wildcard match, so they
need to contain NSEC*.

That depends on whether a resolver caches wildcards with the TTL of the
wildcard RRset, or of the NSECs proving that the wildcard expansion is
valid. My suspicion is that most resolvers today do the former, and
when they grow the 'aggressive NSEC for wildcards' feature, they'll
take MIN(former, latter).


Well, if the client requests the proof (+dnssec), you have to include 
those NSEC*s and I'd consider it incorrect to prolong their TTL.  I'd be 
surprised if someone chose that lack of +dnssec could change this TTL 
behavior, except for implementations without DNSSEC support.  At least 
that's _my_ understanding of the current RFCs (even before 
DNSSEC-aggressive caching).




Maybe the final text would better explicitly note such implications, but
that certainly can wait way past WG adoption. Also it might be confusing
that just by singing a zone the effective TTL of these answers would get
lower - assuming I got your intention right (if not, perhaps the current
text wasn't clear enough anyway).

Whether signing a zone lowers the TTL on an expanded wildcard depends entirely 
on the implementation - basically my previous paragraph in this email. I'd say 
the right approach is the MIN(..) from the previous paragraph.

However, I'm unsure what text the document should have about this. As in my 
response to Matthijs, the problem flows from 8198 but the problem is not in 
8198. That said, we can always put more explanations in this document - perhaps 
even a Background section, and then I can shorten the Introduction section to 
only explain the core of the problem.


I had in mind adding a simple note about this (possible?) consequence, 
as I don't think it's completely obvious and it wasn't happening before 
implementing this RFC.


--Vladimir


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

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

[Vladimír Čunát]

On 1/13/21 10:28 AM, Peter van Dijk wrote:

That all said, I now no longer think we need to do a whole
update/clarification thing on this, but I will add a note to my
document saying that changing the NSEC TTL might affect wildcards, as
you requested earlier.


Sounds good to me.  Thanks.

--Vladimir

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

Re: [DNSOP] NSA says don't use public DNS or DoH servers

[Vladimír Čunát]

On 1/22/21 3:10 AM, Tom Pusateri wrote:

Would it be ok to allow DNSSEC signed responses from any server? If they’re 
signed and verified, does it matter how you got them?


Another missing part is privacy, i.e. even if you get exactly the same 
answers, it doesn't imply you get similar (privacy) properties.


By the way, the add WG is now trying hard to define what it means for 
two resolver services to be "equivalent" - at least for the purpose of 
being OK to switch among them without user's consent.


--Vladimir


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

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-intentionally-temporary-insec-00.txt

[Vladimír Čunát]

Hello.

I'm certainly not fond of trying to call this "best practice".
I'd rather try persuading people to either improve such tooling or 
switch production to another one, but I understand that in real life 
there are cases where the proposed approach may be considered a better 
choice than a proper rollover.


--Vladimir @ knot-resolver.cz


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

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

[Vladimír Čunát]

Hello.

I'm quite surprised that the IANA section of the draft includes that 
registering *flags* is also changed from "Standards Action" to "RFC 
Required".  While the algorithm space is rather large, that certainly 
doesn't apply to the NSEC3 and NSEC3PARAM flags (only 7 remain free).


--Vladimir | knot-resolver.cz

___
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

[Vladimír Čunát]

On 3/11/21 4:38 PM, Paul Hoffman wrote:

I'm quite surprised that the IANA section of the draft includes that registering*flags*  is also 
changed from "Standards Action" to "RFC Required".  While the algorithm space 
is rather large, that certainly doesn't apply to the NSEC3 and NSEC3PARAM flags (only 7 remain 
free).


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".

As I said in the meeting, none of these changes will happen without the WG 
being alerted. Consistency of registration is more important than trying to 
predict rare events in the future.


It's not like I'm necessarily opposed to it.  I was just surprised and 
didn't know how fast our reaction could come.  And so far it doesn't 
seem like we'd need this, but that argument works both ways actually.


--Vladimir

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

Re: [DNSOP] New version of draft-ietf-dnsop-rfc7816bis after WG last call

[Vladimír Čunát]

We're looking for comments before Monday April 26th. 


I'm sorry.  Better slightly late than never, I suppose.  The whole text 
seems good to me, except for a small issue:


In step (6) of the algorithm it might better be noted that in case xNAME 
is in ANSWER, the RCODE is irrelevant.  Now the reading doesn't seem 
right e.g. if it returns a CNAME to an NXDOMAIN.



* we use 1-1-1-3-3-.. label steps, which is not exactly what section 2.3 
describes


I consider that part of the draft as just an example how the number of 
queries could be reduced, so I can't see any problem.


In the stub&forwarding section it might be worth noting the case of 
validating stub or forwarder.  There the final query does not suffice 
regardless of (non-)minimization, so the QNAME minimization approach can 
be "coupled" with a root-to-leaf direction of discovering the trust 
chain.  We've been using one simple approach from this class for years 
(as the only option for forwarding with validation).


--Vladimir | knot-resolver.cz

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

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

[Vladimír Čunát]

On 10. 05. 21 10:19, Petr Špaček wrote:
I think the proper solution should be a real multi-query option, which 
incidentally provides a superset of RRSERIAL capabilities.


If multi-queries require the records being in sync (if from the same 
zone), I really dislike the implications of them being sent to 
resolvers, especially for many questions at once.  Caching, in particular.


--Vladimir | knot-resolver.cz


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

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

[Vladimír Čunát]

I like the document, but the section on validators recommends not to 
follow requirements from RFC 5155, so I don't expect that best-practice 
track is sufficient.  And I do think we need a similar update to 5155, 
be it in this document or a separate one.


I'd also expect something on limits accepted by secondaries.  And some 
details are probably up to further discussion (e.g. particular numbers 
and SERVFAIL), but I don't think such details would block adoption.


--Vladimir | knot-resolver.cz


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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Vladimír Čunát]

On 11. 05. 21 1:59, Brian Dickson wrote:
IMNSHO, it'll be faster to discard any existing parsing code, and 
embrace this as the Zone File format (and wire format) going forward.


I think that would imply burning the currently allocated RRtype code 
pair and requesting a new pair from IANA.  Not unthinkable, but somewhat 
costly; just noting.  I'm not even 100% sure whether we could really 
reuse the allocated "SVCB" and "HTTPS" names if their wire-format changes.



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

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

[Vladimír Čunát]

On 11/05/2021 18.17, Wes Hardaker wrote:

I'd also expect something on limits accepted by secondaries.  And some
details are probably up to further discussion (e.g. particular numbers
and SERVFAIL), but I don't think such details would block adoption.

That's 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"?


I'm not really a good person to ask about these relationships. Anyway, 
if some values were to get standardized to cause SERVFAIL in validators, 
I would expect also secondaries to refuse them, though perhaps that's 
more of an advice or setting expectations (contrary to the validator 
part which I consider an incompatible change in protocol).  Naturally, 
signers should be at least as strict, too, e.g. refuse to go in the 
range that gets standardized to cause a downgrade.



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

Re: [DNSOP] IETF meeting prep and what

[Vladimír Čunát]

On 18/06/2021 19.40, Peter van Dijk wrote:

aname can go; I trust the WG feels SVCB will supersede it.


Yes, please.



I propose replacing rfc5011-security-considerations with a short document 
deprecating 5011 in its entirety. I am happy to write text for that, if there 
is an appetite - when the WG queue is small enough!


I agree that 5011 doesn't seem really useful (anymore).

We have it in Knot Resolver but recommend not to use it, because it's 
just more trouble than worth in practice.  Notably, (all) resolver 
software needs much more frequent updates than the rate of root KSK 
rollovers, so it's easier to distribute root DS within the updates; some 
Linux distros even package these separately and share them among 
different resolver packages.  Even if you're conservative and use BIND 
ESV or similar, I believe it's a better approach than 5011.  For 
non-root keys there doesn't seem much point nowadays, as getting a chain 
from root is better.


(By the way, an "interesting" example: router with DNSSEC validation and 
factory reset / rollback, commonly shelved for a year, unreliable clock, 
etc.)


--Vladimir

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

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

[Vladimír Čunát]

Hello,

I support the draft.  (as I wrote in November)  I re-read the current 
text, though I admit I could miss details relatively easily in process 
matters.


--Vladimir | knot-resolver.cz

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

Re: [DNSOP] NSEC3 Guidance - zone size impact of opt-out

[Vladimír Čunát]

On 03/09/2021 09.32, Paul Wouters wrote:

I guess with aggressive nsec, you might even gain some CPU cycles back
for that extra memory used, and receive less queries too? Saving you
some money? 


I think these savings won't be significant in delegation-centric zones 
that are huge enough to consider opt-out.  (But from TLDs I'd perhaps 
only consider .com to be huge enough.)  For resolvers the memory issue 
is even more significant, because they share it for *all* zones, so you 
can't expect them to keep a significant fraction of huge zones in 
cache.  Without being delegation-centric you could at least noticeably 
utilize one NODATA answer to deny all missing types at the name (A + 
 is a typical queried pair, to be joined by HTTPS).


--Vladimir | knot-resolver.cz

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

Re: [DNSOP] NSEC3 Guidance - zone size impact of opt-out

[Vladimír Čunát]

On 03/09/2021 09.48, Vladimír Čunát wrote:
you can't expect them[resolvers] to keep a significant fraction of 
huge zones in cache


That being said, if a zone with (only) a couple million entries is 
*attacked*, it can be realistically protected by aggressive caching.  A 
cache of a couple GB seems OK for big resolver instances, so even the 
whole NSEC* chain of the attacked zone might fit.  Simple experiments: 
https://indico.dns-oarc.net/event/28/contributions/509/



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

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

[Vladimír Čunát]

For the limit on total number of connections: "Absent any other 
information,

150 is a reasonable value for this limit in most cases."

[...]
Maybe this could use a clarification that 150 is good advice only if 
you _don't_ have any "TCP-only" clients, like e.g. DoT stubs?


I would not be so sure that DoT/DoH are the only cases.  What about busy 
authoritative servers?  You get 150 by default, and then some important 
RRset gets over the UDP limit (say, a DNSKEY rollover) and you get into 
problems due to overzealous connection limits.  IMHO 150 is extremely 
cheap for a (potentially) busy server.


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

[Vladimír Čunát]

On 15/09/2021 16.41, Daniel Migault wrote:
Outside experimentation, especially for national algorithms, this will 
lead to nations having their algorithms qualified as standard while 
other nations having their algorithms qualified as non standard. I 
would like to understand why this cannot be a problem.


I'm sorry, I'm a bit confused about which nations would get standard 
algorithms.  Are P-256 and P-384 considered "national" crypto?  I know 
they're from NIST, but they seem widely popular outside USA.  
Technically we have old GOST algo(s) on standards track, though they are 
already obsolete in its nation, so those? Or some other (planned) 
algorithm I've missed?  Apart from that, I personally think that 
allowing "cheaper" allocations of algorithm numbers *reduces* this 
disparity/problem instead of making it worse, but perhaps I'm missing 
the essence of the issue.


Interoperability could be mentioned for reference, though in practice 
having a standard does not necessarily help that much, e.g. Ed25519 
validation levels are still rather low after four years with standard 
and Ed448 is probably even worse: 
https://www.potaroo.net/ispcol/2021-06/eddi.html


--Vladimir

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

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

[Vladimír Čunát]

On 15/09/2021 23.51, Daniel Migault wrote:
I do not have any specific example in mind and as far as I know GOST 
is standard [1] - This was already the case during the call for 
adoption and I suppose it was mentioned as an example.


To clarify, that DNSSEC-standard GOST only uses crypto that's been 
obsolete for years, I believe.  And renewing this to the new GOST 2012 
versions was the main spark for the iana-cons draft. 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/


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

Re: [DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

[Vladimír Čunát]

On 12/10/2021, Tony Finch wrote:

I view the term "in-bailiwick" as no longer suitable for use in careful
writing because its meaning has become thorougly confused and muddled.


I agree that without further qualification the meaning of "in-bailiwick" 
isn't clear.  And I'm personally not convinced that usage of the word is 
restricted just to NS records returned in referrals.


--Vladimir

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

Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance

[Vladimír Čunát]

On 21/10/2021 13.22, Peter van Dijk wrote:

Editorial nit, already hinted at above: the text currently has "Validating resolvers MAY 
return SERVFAIL when processing NSEC3 records with iterations larger than 500." - I suggest 
changing this to "validating resolvers MAY ignore NSEC3 records with iterations larger than 
500". That way, zones in the middle of a transition from 1000 to 0 iterations do not get 
punished. Zones at 1000, not in a transition, will still get SERVFAIL by virtue of the NSEC3 proof 
missing (because it is ignored).


I'm fine with either.  Ignoring such NSEC3 records seems to be clearly 
the easiest way of achieving "MAY return SERVFAIL".  On the other hand, 
the downgrading can turn out relatively complex and (security-)error-prone.


--Vladimir | knot-resolver.cz

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

Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance

[Vladimír Čunát]

On 21/10/2021 23.20, Viktor Dukhovni wrote:

2. Resolvers could still cope with such numbers pretty confidently.

This is where I'm looking for experienced feedback from resolver
maintainers and operators.


I don't think that NSEC3 hashing could consume significant resources in 
*normal* traffic.  The only real risk I see is that expensive parameters 
might get utilized in some DoS attack, so I'd focus on worst-case scenarios.



Salt length: that's what I'd additionally restrict, because 255 bytes 
make even less sense than high iterations and it's quite expensive - 
salt gets added on every iteration, so the expenses multiply each other.


Example micro-benchmark doing just the NSEC3 hashing shows that even 
quite long 32B salt has little effect but 255B adds a noticeable 
multiplicative factor.  Therefore I'd suggest that NSEC3 records with 
salt > 32B may be ignored or something similar; I don't expect they 
really exist in practice and we still shave some factor from attacks.  
That's all assuming we can't afford pushing the validator limits very 
close to zero iterations.


iter, salt, us / hash

   0,   0,   0.14
   0,  32,   0.16
   0, 255,   0.47

  50,   0,   3.72
  50,  32,   4.66
  50, 255,  21

 150,   0,  10.7
 150,  32,  13.7
 150, 255,  62

(gnutls using SHA extensions on zen1 CPU, but the conclusion was also 
confirmed by Peter van Dijk on a different stack)


--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-hardaker-dnsop-intentionally-temporary-insec-01.txt

[Vladimír Čunát]

On 21/10/2021 18.55, Wes Hardaker wrote:

It adds a new section using multiple authoritative servers  with
different data to get around algorithm roll difficulties.


I'm also not convinced that it's a good recommendation, meaning I can't 
predict if it will behave relatively reliably.  Perhaps if you have just 
two IP addresses in the whole NS set, it seems reasonable that on 
validation error the next one tried will be the other one (though I 
haven't surveyed these strategies).  In general, 50% failure rate 
doesn't sound very nice, e.g. with three attempts you still have failure 
rate over 10%, which doesn't make me happy.  (Real numbers get 
complicated by caching, selection by round-trip time, etc.)


--Vladimir

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