[DNSOP] draft-ietf-dnsop-delegation-only: exchanging DS set
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
[DNSOP] SVCB and HTTPS SvcParam multiple value order on the wire
Hi folks,
I'm working on implementing SVCB and HTTPS in PowerDNS and I have some
questions about the wire-format for the multi-value parameters like
ipv{4,6}hint and alpn.
When there are multiple IP addresses in a hint, in what order should
they be on the wire? I would expect them to be ordered like an A/
RRSet's RDATA to be sorted as specified in 4034 section 6.3 ("… are
sorted by treating the RDATA portion of the canonical form of each RR as a
left-justified unsigned octet sequence in which the absence of an octet
sorts before a zero octet."). The draft says the hints are "an unordered
collection", but it would be great to mandate an on-the-wire ordering
here.
This will only work, of course, if multi-valued SvcParams are a set
(where duplicates are disallowed/ignored), which is also not explicit in
the draft for ipv{4,6}hint and alpn.
For the "mandatory" key, a sensible ordering (ascending) is specified
and it is explicit that a key can only be present once in the set.
Cheers,
Pieter
--
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB and HTTPS SvcParam multiple value order on the wire
> On 31 Jul 2020, at 19:46, Pieter Lexis wrote:
>
> Hi folks,
>
> I'm working on implementing SVCB and HTTPS in PowerDNS and I have some
> questions about the wire-format for the multi-value parameters like
> ipv{4,6}hint and alpn.
>
> When there are multiple IP addresses in a hint, in what order should
> they be on the wire?
As they are entered.
> I would expect them to be ordered like an A/
> RRSet's RDATA to be sorted as specified in 4034 section 6.3 ("… are
> sorted by treating the RDATA portion of the canonical form of each RR as a
> left-justified unsigned octet sequence in which the absence of an octet
> sorts before a zero octet."). The draft says the hints are "an unordered
> collection", but it would be great to mandate an on-the-wire ordering
> here.
RFC 4034 is about validating a RRset. One needs to have a defined order
to DIGEST the RRset. The order of the records on the wire is UNDEFINED.
> This will only work, of course, if multi-valued SvcParams are a set
> (where duplicates are disallowed/ignored), which is also not explicit in
> the draft for ipv{4,6}hint and alpn.
>
> For the "mandatory" key, a sensible ordering (ascending) is specified
> and it is explicit that a key can only be present once in the set.
>
> Cheers,
>
> Pieter
>
> --
> Pieter Lexis
> PowerDNS.COM BV -- https://www.powerdns.com
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-delegation-only: exchanging DS set
On Jul 31, 2020, at 05:06, Vladimír Čunát wrote: > > Hello dnsop. > > 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? A few things could be done. The client could publish a CDS set which would never include the rogue DS. The log could look and explicitly warn for “fast DS changes and undo”, since this would be flipping back and forth. 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. But remember, forcing a rogue parent into this mode is already a win we currently don’t have. > 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). Some DS flip flopping can be detected so a warning can be issued to the registrant or a public entity. So the registrant isn’t entirely powerless. But contacting the registrant is still tricky if you cannot trust the info from the parent (eg whois) > 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'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. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-01.txt
On Fri, 2020-07-31 at 00:23 +0100, Tony Finch wrote: > * should set the DONTFRAG option on responses > > * should listen for ICMP frag needed packets, and react by re-sending the > response (which is embedded in the ICMP packet) with a TC bit set Only part of the response is embedded in the ICMP packet. With some luck, enough of the query is embedded in the ICMP packet (I'm unsure about EDNS). I'm unsure it's even easy for a user space process to get that ICMP packet. That all said, this sounds like a splendid way to allow 'request spoofing' even if everybody does BCP38 (ingress filtering). The ICMP packet could come from any IP (so no spoofing protection), but the ICMP *payload* which you then treat as believable IP headers is not subject to BCP38 checking, as far as I understand. I know we have a state problem in DNS servers forgetting about a query the moment they responded to it, but I don't think scavenging that query from incoming ICMP packets is the solution. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
