[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

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

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

[DNSOP] Dnsdir telechat review of draft-ietf-dnsop-avoid-fragmentation-16

[Vladimír Čunát via Datatracker]

Reviewer: Vladimír Čunát
Review result: Ready

Yes.  I like those reformulations in 16 since 15; I think they do make the text
clearer.  So, I still see nothing wrong with the current version and like the
document overall.


___
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

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

[Vladimír Čunát via Datatracker]

Reviewer: Vladimír Čunát
Review result: Ready

I've already posted about -15, though not with dnsdir hat.  So, I see nothing
wrong with the current version. (The complaint about DF=1 in current
implementations has been addressed.)


___
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

[DNSOP] Dnsdir last call review of draft-ietf-dnsop-avoid-fragmentation-13

[Vladimír Čunát via Datatracker]

Reviewer: Vladimír Čunát
Review result: Ready

(assigned review)  I re-read the whole text, and noticed nothing that I'd
consider wrong or missing.  (I didn't review implementation section; except
Knot's is basically my text.)

I think the current text is a quite nice reference for DNS fragmentation; I'm
not aware of anything close.  IIRC I think the text has improved greatly over
the years.

Nit which I've already posted somewhere: I don't expect the double thanks is
intentional?  (not personal, Peter :-)


___
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] 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

[DNSOP] Dnsdir telechat review of draft-ietf-dnsop-alt-tld-23

[Vladimír Čunát via Datatracker]

Reviewer: Vladimír Čunát
Review result: Ready

There've only been nits between -22 and -23; certainly no objections there and
thus nothing new for me to say.


___
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

[DNSOP] Dnsdir last call review of draft-ietf-dnsop-alt-tld-22

[Vladimír Čunát via Datatracker]

Reviewer: Vladimír Čunát
Review result: Ready

It feels a bit weird, but dnsdir assigns reviewers for this alt-tld LC, too.  I
took this as an opportunity to read the current text more carefully and also
read more of the lengthy discussion history.

I'm very happy with how the rules for handling .alt turned out and I have
nothing to suggest there, contrary to issues I see in texts for most
special-use names.

Except a nit: I've never understood why mention null label in non-DNS wire
format; I'd personally stick to a simple formulation, reducing the whole
paragraph to just two lines.  The intention is simple - the draft does not
define anything about how non-DNS protocols handle or represent anything. 
Still, I don't mind the current eloquent formulation.

The major question is the high-level idea of alt-tld itself.  There have been
very many discussions about that, spread over years, and last call would be
quite late to significantly reconsider this anyway, unless something serious
got suddenly discovered.  My takeaway is that - while I can't estimate chances
of .alt ever getting really useful or popular (at least in the relevant
contexts), the costs and risks of this RFC seem pretty low so I'm willing to
give it a shot, perhaps partially as an attempt to deflect future discussions
on DNS-like non-DNS names.

(A couple editorial comments went directly to the GitHub repo.)


___
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

[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] 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

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] 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] 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] 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] 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]

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

[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] .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

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] 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 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] [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] [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] 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] 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] [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] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp

[Vladimír Čunát]

Hello.

This line is misleading, I believe:

- RFC8198 describes how a validating resolver can emit fewer queries 
in signed zones that

use NSEC for negative caching.


That RFC describes aggressive caching also for NSEC3 and (positive) 
wildcards.  (Of course, opt-out NSEC3 records are basically useless, but 
many zones are without opt-out.)


For example, the formulation could be simply truncated as:
> RFC8198 describes how a validating resolver can emit fewer queries in 
signed zones.



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

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

[Vladimír Čunát]

On 02/08/2022 13.53, Martin Schanzenbach wrote:

This is not an oversight (altough I have to admin it did not occur to me
that this a valid DNS TLD at the time of writing).  [...]


Oh, I understood that this DNSOP thread - notably the first post - 
originated as an attempt to reduce collisions between GNS pet names and 
DNS names.  Probably by standardizing .alt (or similar) as special in 
DNS and encouraging that GNS pet names nest under it.


If I got this wrong, I suspect it might be helpful to restate the 
DNSOP-related intentions more clearly.


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

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

[Vladimír Čunát]

Interesting bit: the current -gns draft even uses the .pet TLD in an 
example, which is a TLD that actually exists in the official global DNS.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-09.txt

[Vladimír Čunát]

The long addition in "Flags" section broke the sentence into which it 
was inserted (by mistake?).  I also can't see that change in the newest 
git.


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

Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)

[Vladimír Čunát]

On 10/05/2022 21.55, Murray Kucherawy via Datatracker wrote:

Regarding the SHOULD in Section 3.2, what other action might a resolver
legitimately return, and why?


Extended errors (RFC8914) generally aren't "mandatory", so they may 
return none.  In practice I also see quite some leeway in which EDE(s) 
to return, because there are more complex cases than matching a single 
one and implementing everything precisely might be very difficult.  (For 
example, one error got encountered and then the resolver retried against 
with a different RRSIG record or asked a different server and got a 
different error or none.)




Same question for the SHOULD in Section 4.


Here it's a tradeoff, and not all operators/vendors will have exactly 
the same view.  Some are very sensitive about producing "unnecessary" 
resolution errors (SERVFAILs in this case) and are willing to pay by 
(possibly) doing more CPU work, etc.



--Vladimir | knot-resolver.cz

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

Re: [DNSOP] [Ext] More private algorithms for DNSSEC

[Vladimír Čunát]

On 22/03/2022 09.56, Nils Wisiol wrote:

There was some internal discussion about using 17 vs 253, with the main
argument for 253 being that this is the intended use case for 253 and
the main argument for 17 being that worry that some resolver
implementations could have special treatment for private algorithm
numbers.


17 seems a little risky in the sense that it might get officially 
allocated in the next couple of years, even if you don't care about 
colliding with other experiments.


Knot Resolver does not have any special-casing here, I believe. Anything 
above 16 should always be unsupported algorithm, so downgraded to 
insecure (if no other supported combination is in the DS set).


--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-nsec3-guidance-02.txt

[Vladimír Čunát]

On 07/03/2022 19.06, Wes Hardaker wrote:

The -05 version sounds clearer here than -04 ("not respond" above) or
-03.  Thanks.

You should check -06 too -- I restructured it to read better (IMHO)


Right, I agree that -06 is better.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Vladimír Čunát]

On 26/02/2022 00.30, Wes Hardaker wrote:

Validating resolvers MAY choose to not respond to NSEC3 records with
iterations larger than 0.


The -05 version sounds clearer here than -04 ("not respond" above) or 
-03.  Thanks.


--Vladimir

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Vladimír Čunát]

On 22/02/2022 20.02, Geoff Huston wrote:

I’m not sure I follow that latter comment relating to "a validating resolver 
returning an insecure response" - Do you mean:

a) - a DNSSEC-validation capable resolver responding to a query that had the CD 
bit set?

b) - a DNSSEC-validation capable resolver responding to a query that had no 
EDNS(0) extensions at all?

c) - a DNSSEC-validation capable resolver responding to a query that received 
an NSEC record signed with an algorithm, that was not recognised by the 
resolver?


Oh, I'm sorry, I thought it would be perfectly clear in the context of 
this previous e-mails in this thread and the draft's paragraphs directly 
preceding the diff I posted.


Anyway, let me explain why our current code would violate the text but 
not the intent (or security properties).  It's about the "may SERVFAIL" 
case, defined as
> Validating resolvers MAY also return SERVFAIL when processing NSEC3 
records with iterations larger than 0.


I believe that the cleanest and least bug-prone way to implement this 
sub-case is to simply ignore any NSEC3 records with iterations over the 
limit.  You do not need to check any kind of signatures or any further 
properties, as it's just trading one SERVFAIL for another SERVFAIL.  
(OK, maybe the EDE code or similar diagnostics could suffer a little, 
but I'm not convinced the complications are worth it.)  Now, this 
implementation approach would get into conflict with that sentence:

> Note that a validating resolver MUST still validate the signature

so I was trying to suggest a simple way of patch it up to avoid 
colliding with the implementation approach that I find useful.  I don't 
really care about particular formulation, but I'd find it a bit 
unfortunate if I had to choose between not strictly following the RFC or 
complicating the implementation (unnecessarily in my view).


I hope I've stated my argument clearly now.  Thanks for bearing with me.
--Vladimir
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Vladimír Čunát]

On 09/02/2022 22.41, Wes Hardaker wrote:

So I've re-arranged things a bit to hopefully address the flow better.
Let em know if you think further improvements are warranted.


I'd still probably suggest at least a minimalist change like:
-Note that a validating resolver MUST still validate the signature
+Note that a validating resolver returning an insecure response MUST 
still validate the signature


But to me it's certainly not a big deal.  (Though not changing this 
would mean that formally I wouldn't be exactly following the RFC.)


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

Re: [DNSOP] I-D An Extension to DNS64 for Sender Policy Framework SPF Awareness

[Vladimír Čunát]

Hello.

To me, the proposed "MUST rewrite [the SPF record]" certainly feels too 
strong.  I also wonder if there are some other problematic cases, as SPF 
certainly isn't the only common DNS record that can embed IPv4 address(es).


--Vladimir

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

Re: [DNSOP] Neither authenticated nor SERVFAIL

[Vladimír Čunát]

On 09/12/2021 18.16, Mats Dufberg wrote:


If you query for something that matches that wildcard, e.g. 
"x.lindforslaw.se A", then AD is not set, but it is not SERVFAIL.


The wildcard proof involves an opt-out NSEC3 record in this case.  That 
means a delegation might exist instead of the wildcard expansion, but 
that can't be (dis)proven.


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

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

[Vladimír Čunát]

On 01/12/2021 15.49, Mark Andrews wrote:

Black lies is “QNAME NSEC \000.QNAME NSEC RRSIG”.  There is no churn for "black 
lies”.  Black lies turns NXDOMAIN into NODATA.

"DNS Shotgun" can produce churn of NSEC if you ask for a type that is listed as 
existing but it doesn’t actually exist.  The NSEC returned is still valid for DNSSEC 
synthesis.


Oh, I'm sorry; a terminological problem.  I used "black-lies" for the 
overall behavior of Cloudflare auths, as described in that blog 
article.  Maybe we could extend the current terminology draft :-D


(Nit: about random QTYPE attacks, I can't see a point when you leave 
random QNAME attacks undefended.)


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

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

[Vladimír Čunát]

On 01/12/2021 13.43, Mark Andrews wrote:

Accepting 'QNAME NSEC \000.QNAME NSEC RRSIG’ (and other type maps) protects you 
from random QTYPE attacks.  It also makes 'black lies' work as intended.


Black lies got bad caching if Knot Resolver accepted this aggressively.  
Asking two different QTYPEs repeatedly got uncacheable, as those answers 
need different NSEC* record contents (for the same NSEC* owner).  Of 
course, with different caching design this might be different, but it 
just didn't seem worthwhile to me.  If someone cares for good caching, 
they shouldn't use minimal ranges.


--Vladimir

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

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

[Vladimír Čunát]

On 01/12/2021 09.35, Mark Andrews wrote:

Also stop hiding this breakage. Knot and unbound ignore the NSEC records which 
trigger this when synthesising.


Knot Resolver stopped treating minimally-covering NSEC* aggressively, 
but there are *two* different reasons.


1) breakages like this.  We hard-enabled aggressivity for NSEC and NSEC3 
in 2018; at that point we felt very much in minority, and it was hard to 
convince others that it's them who's doing it wrong (say, F5 customers).


2) low benefits of aggressive caching in this case.  When the range 
covers basically a single name, the possible positive effect is very 
limited.  There are negative non-breaking effects as well, e.g. caching 
of approaches like [black-lies].  You also need to weight the 
(negligible) benefits against (small-ish) costs of aggressive 
cache-searching.


[black-lies] https://blog.cloudflare.com/black-lies/

--Vladimir

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

Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Vladimír Čunát]

On 26/11/2021 12.32, Petr Špaček wrote:
You are right right, I did not consider "crack names which do not 
exist yet" scenario and focused only on dictionary reuse across zones.


Do you have specific proposals for draft text? 


No, I don't have any ideas for improvements.  The current salt section 
reads nice to me.


--Vladimir

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Vladimír Čunát]

I like the text and how it's improving.

Note that a validating resolver MUST still validate the signature over 
the NSEC3 record to ensure the iteration count was not altered since 
record publication (see {{RFC5155}} section 10.3).


It might be better to clarify that this "MUST" does not really apply to 
the SERVFAIL case.  (The text around has changed recently.)


I think this SERVFAIL will generally be best implemented by simply 
ignoring any NSEC3 above the corresponding limit.  Maybe I'd even 
standardize the case that way, but I don't care really. It's an 
advantage unstated in the draft that this is very easy to do, leaving no 
room for bugs (e.g. unintentional downgrade opportunities).


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

Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Vladimír Čunát]

On 25/11/2021 13.00, Petr Špaček wrote:
IMHO in the context of NSEC3 the salt would make sense _only_ if it 
were rotated faster than attacker was able to walk the zone. Once 
attacker has list of hashes available for offline cracking the salt 
does not do anything useful anymore. 


I disagree; you don't need to rotate so fast.  At a moment when a 
particular salt won't be contained in future answers, there's no point 
in creating a dictionary anymore as it's cheaper to crack the gathered 
hashes individually.  The only value of dictionary is (possibly) 
speeding up attacks on names that will appear in future - and the only 
value in re-salting is in making this technique more expensive.  
Resalting interval is the period when a particular dictionary is useful, 
so basically by halving the interval you double the price of this.  [all 
IMHO]


--Vladimir

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

Re: [DNSOP] Filtering and DNSSEC

[Vladimír Čunát]

Hello,
I realize this is tangential, but I believe it's important over the long 
term.


Any modification of DNS will break *later* DNSSEC validation.  As 
filtering seems almost always done by DNS modification (e.g. NXDOMAIN), 
and I see significant trends in doing filtering as a service, there's a 
problem that DNSSEC gets crippled from the filterer onwards.


I can't realistically see moving *all* filtering use cases into end 
clients, but I'd really hate for DNSSEC to meet the same fate and I 
don't think it's necessary at all.  In other words, we need a model 
where upstream DNS service is trusted with filtering but not with 
DNSSEC.  Now perhaps if validation was done directly in a browser, it 
might choose that only "positive" answers get validated and the rest is 
trusted (encrypted link etc), but generally I wouldn't do that, as it 
would surely create some holes in DANE or elsewhere.


What we already have is SERVFAIL.  That's what validators MUST return 
instead of the forged answer (since the beginning of DNSSEC).  And 
actually it does the filtering job, as the SERVFAILed services won't be 
accessible.


With EDE (RFC 8914) indicating a few kinds of filtering, servers and 
clients now could make some behavior better suited for these cases, 
around fallback to other servers, maybe caching, etc. (Say, only if it 
came over a trusted channel, based on local policy.)  I suspect there's 
currently still lots of room for improvement on implementation side 
here.  And orthogonally, structured-error-page or other mechanism could 
extend the available information in these *SERVFAIL* answers and perhaps 
get utilized in web browsers.


I do realize that SERVFAIL isn't ideal approach to blocking, but I can't 
really see anything better (or similar) that could reconcile DNSSEC with 
some of the common filtering use cases.


--Vladimir | knot-resolver.cz

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

Re: [DNSOP] nsec3-parameters opinions gathered

[Vladimír Čunát]

On 04/11/2021 23.44, Wes Hardaker wrote:

The most important sticking point is there are 4 implementations (thank
you for the links Matthijs) that have implemented 150.  Since DNSOP
strives for implementations of specs, I think this is the number we
should publish*unless the vendors speak up and say they'll drive lower*.


I'm convinced that 150 was just a quick stop-gap compromise and that 
from the start vendors expected that dnsop might set it lower later.  
Therefore I don't think this *argument* for keeping 150 is really valid.


As for Knot Resolver, I see no problem in setting the hard limit lower, 
especially if that gets published in this RFC.  From Viktor I gather 
that 100 shouldn't cause issues even at this moment, especially if it's 
only a limit for downgrading to insecure (which won't be even noticed by 
most DNS consumers).  So personally I expected the draft to lower the 
bound to <=100, though as I said... for us the *overall* performance 
ratio from e.g. 150 -> 50 isn't that large.


I'm not sure how low a "SERVFAIL limit" could go, though.  (And I 
probably won't bring other stuff like salt into this thread.)


--Vladimir

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

Re: [DNSOP] SVCB/HTTPS weasel words are dangerous.

[Vladimír Čunát]

On 01/11/2021 18.29, Michael StJohns wrote:


Section 2 - "their definition should specify..." - this is obviously a 
must and is guidance to the IANA for interpreting registrations.  E.g. 
lack of this data has to result in a rejected registration request.


Section 2.1 - "Key names should contain..."  - drop the should as it 
introduces ambiguity.  The BNF is clear this is a MUST and is normative.


Section 2.1 - "...formats for such keys SHOULD use a comma-separated 
list".  This is a semi-reasonable SHOULD, but begs the question of 
what you do if you don't use a comma separated list and adds to the 
later parser complexity if someone chooses something else in a later 
definition.   Guidance such as "Requests for registration of  lists or 
set SvcParamKeys that propose a different format must justify any 
deviation and are subject to rejection." may be appropriate here.


2.4.1 - "all RRs SHOULD have the same mode" - this is satisfactory as 
the next sentence describes what to do if this is not the case.


I agree with what you write about these occurrences.  Generally I hope 
that it's not too late to make similar changes.



2.4.1 - " ... SHOULD be given preference..." and "SHOULD apply a 
random shuffle" are not satisfactory as they lead to ambiguity between 
the publisher and the client.  There appears to be no good reason not 
to make both of theses MUST.


2.4.2 - "SHOULD only have a single" and "SHOULD pick one at 
random".  The first is satisfactory as it's covered by guidance on the 
following sentence.  The second is not as it leads to ambiguity and 
there appears to be no good reason not to make it a MUST.  Among other 
things, you really don't want someone to come along later and decide 
that because 75% of the clients pick the first one, they can game the 
system by manipulating the RRSet.


In these two points it should (heh) remain clear that there are 
situations where the clients won't exactly do this - e.g. if some 
protocol is not supported by the client or if it can assume that some of 
the RRs probably would not lead to success (based on recent connections 
attempts).  In some later parts there is text for these fallbacks, so it 
probably will remain clear, though I think would be better to reflect it 
in the above formulations *if* they get strengthened to MUST.



2.4.2 "TargetName SHOULD NOT..." - this is unsatisfactory as it 
doesn't explain what a client should do if it receives such a beast.  
This needs client guidance and the client MUST ignore such a record.  
Also are there other pathological cases where you might end up with 
loops indirectly?  If so, guidance for the client on how to detect 
such cases needs to be given.


2.4.2. "...records SHOULD NOT..." is satisfactory as it describes how 
a client resolves receiving such records.



I think I agree with these two points, too.


I don't have a strong opinion on the following comments about section 
3.  I don't feel qualified for such details around HTTPS and similar 
clients.


On the other hand, I carefully re-read all resolver-related bits (mainly 
sections 4.x, 5.2, 13, 14), and there the requirements language seems 
good to me.


Perhaps I'd like to note just this paragraph from 13. security 
considerations:


Clients MUST ensure that their DNS cache is partitioned for each local 
network, or flushed on network changes, to prevent a local adversary 
in one network from implanting a forged DNS record that allows them to 
track users or hinder their connections after they leave that network.
Does this imply that if a DNS *resolver* is running on a device capable 
of "switching networks" (e.g. laptop), it MUST ensure this DNS cache 
handling?  I'm not aware of such standards-track RFC requirements so 
far, and it's reaching a bit further than just these new RR types.  Note 
that the actual client (like web browser) most likely won't be able to 
control this (optional) layer of local DNS cache, though there are 
always options like attempting some DNS bypass (e.g. via DoH, most 
popularly).



--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-dns-error-reporting-00.txt

[Vladimír Čunát]

On 26/10/2021 12.10, Roy Arends wrote:
I have a slide ready to discuss the issue that DNS Query Name 
Minimization brings… A minimised query can’t be distinguished from a 
full query, so it may not be clear what name caused an issue. The 
current thinking (but will be discussed later today) is to start with 
_er as well. That way, the erroneous qname is “encapsulated” by _er 
labels.


I assumed you can distinguish those quite reliably thanks to QTYPE=NULL 
which I haven't heard of for minimization so far.



If, at any point, auth servers offer encrypted transport, a faulty 
query should not be replicated in clear text.


I certainly agree with that, but then the text should be clarified that 
the encryption refers to auth side and not client side.  As it is now, 
it refers to RFC numbers that explicitly consider client side only, so I 
assumed that's what was meant.



To make the error-reporting work, you need noticeable commitment to 
deploy on both sides, because otherwise the perceived benefit from 
deploying might be quite low.  On resolver side, I believe that it 
will be quite rare for operators to tweak such highly technical 
options[*].  So if this MUST be off by default, you at least need 
commitment from some significant operators - say, I'm not even sure 
if Quad9 by themselves would suffice to bootstrap this.


I'm inclined to remove that text alltogether. Resolver implementations 
either do this by default, or not. No need to pedantically require 
config first and default off. Additionally, there is an issue where 
resolvers need to retry without the option when auth servers can’t 
handle the option… I’m inclined, just like Extended DNS errors itself, 
to have authoritative servers just set the option, unsolicited. It 
hasn’t caused any issue for extended DNS errors yet… but lets have 
that discussion this afternoon.


I'm not sure about this reasoning, but anyway - I'd be also inclined to 
remove that paragraph, and we'll see what opinions appear during the 
call and afterwards.


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Vladimír Čunát]

On 26/10/2021 12.02, Petr Špaček wrote:
We need to consider & document interaction between Query Name 
Minimization and NXDOMAIN processing as per RFC 8020. If minimization 
& RFC 8020 are on default then it might very easily happen that most 
of _er subtrees (which are presumably empty) will be cut out by cache 
and nothing will be sent out when an error is detected. 


I believe that's already sufficiently addressed in section 4.1. Managing 
Caching Optimizations



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Vladimír Čunát]

Hello.


DNS Error reporting SHOULD be done using DNS Query Name Minimization
[RFC7816  ] to improve privacy.


It's just a detail and "SHOULD" isn't strong, but I expect it might be 
worth elaborating here.  The name used in the reporting query adds a few 
labels to the failing QNAME and the whole reporting agent domain, so 
together that's lots of labels, and expending a packet for *each* of 
those labels would seem quite wasteful.  Perhaps we could agree on some 
boundary (e.g. around the "_er" label) under which minimization isn't 
recommended anymore, and put that as a suggestion into the text?



The reporting resolver MUST NOT report about queries and responses
from an encrypted channel (such as DNS over TLS [RFC7858  
] and DNS
over HTTPS [RFC8484  ]).


I believe this needs some explanation at least (in the text, ideally).  
The failing query triggering the report is towards an authoritative 
server (i.e. unencrypted), and the reporting queries do not really carry 
more information.  They may travel by a different path, but on the whole 
I can't see significant motivation for the paragraph, especially in 
"MUST NOT" form.



This method MUST NOT
be deployed by default on reporting resolvers and authoritative
servers without requiring an explicit configuration element.


I'm not so sure about forbidding this on resolvers so strongly, but 
certainly OK if the WG prefers it that way.  (On auths it wouldn't make 
sense to enable by default; what agent?)  If the error-reporting is 
meant really seriously, I'd rather improve the mechanism to never induce 
significant overhead and encourage enabling it by default on resolvers 
(at some point).


To make the error-reporting work, you need noticeable commitment to 
deploy on both sides, because otherwise the perceived benefit from 
deploying might be quite low.  On resolver side, I believe that it will 
be quite rare for operators to tweak such highly technical options[*].  
So if this MUST be off by default, you at least need commitment from 
some significant operators - say, I'm not even sure if Quad9 by 
themselves would suffice to bootstrap this.



--Vladimir | knot-resolver.cz

- - -
[*] and I support that.  I'm a big proponent of defaults.  They should 
work as good as possible, and deployments should operate as close to 
defaults as possible.
___
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

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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] [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]

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] 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] 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 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] [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] 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] [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] 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] 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] 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]

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] 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] 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

[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] 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 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-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] [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

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] 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] 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] 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] 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] 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] 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 this zone does
> not do this and THUS you can log t

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] 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] 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] 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] 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] 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] 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/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