Subject: [dns-privacy] [Fwd: [EXT] New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt]

From: Peter van Dijk <[email-masked]>
Date: Mon, 13 Jul 2020 19:16:34 +0200

Hello,

please find below revision -01 of our proposal for enabling DoT from
resolver to authoritative.

New in this revision:

* a lot of clarifying text without changing the underlying protocol

* the DNSKEY flags field is now specified to be 257 instead of 0. We
know that this goes against the explicit wishes of some of those who
commented on -00, but we argue in the document that because our algo
TBD will have 'Zone Signing=N' in the IANA DNSKEY algo registry, the
flags do not mean 'ZONE' and 'SEP'. The value 257, meanwhile, is
believed to go down with registries much easier.

* we added a 'Design considerations' section that explains how this
protocol came to be, and why we did not go the TLSA route. You can
click through to it directly via 
https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-01#section-9

Furthermore, we have tried to do a review of this protocol against the
requirements of the DPRIVE phase 2 document.  You can find this review
(which might be updated outside of revisions of this draft or the phase
2 draft) via 
https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin/yardsticks

We'll be presenting the draft at the IETF108 dprive session.

Kind regards,
Manu, Robin & Peter

-------- Forwarded Message --------
From: [email-masked]
To: Robin Geuze <[email-masked]>, Peter van Dijk <
[email-masked]>, Emmanuel Bretelle <[email-masked]>
Subject: [EXT] New Version Notification for draft-vandijk-dprive-ds-
dot-signal-and-pin-01.txt
Date: Mon, 13 Jul 2020 01:47:10 -0700

A new version of I-D, draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt
has been successfully submitted by Peter van Dijk and posted to the
IETF repository.

Name:		draft-vandijk-dprive-ds-dot-signal-and-pin
Revision:	01
Title:		Signalling Authoritative DoT support in DS records, with key pinning
Document date:	2020-07-13
Group:		Individual Submission
Pages:		14
URL:            https://www.ietf.org/internet-drafts/draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt
Status:         https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/
Htmlized:       https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vandijk-dprive-ds-dot-signal-and-pin
Diff:           https://www.ietf.org/rfcdiff?url2=draft-vandijk-dprive-ds-dot-signal-and-pin-01

Abstract:
   This document specifies a way to signal the usage of DoT, and the
   pinned keys for that DoT usage, in authoritative servers.  This
   signal lives on the parent side of delegations, in DS records.  To
   ensure easy deployment, the signal is defined in terms of (C)DNSKEY.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 14 Jul 2020 22:13:53 +0000

Hi Peter,

While I remain neutral as to whether or not ds-dot-signal-and-pin is a good idea overall, you can count me as one that thinks flags=257 is a bad idea.  I don't think anything in 403[345] say that flags can be interpreted differently depending on the algorithm or on the value of the Zone Signing column.  

The document uses the phrase "DNSKEY algorithm" very often but I think you really mean DNS Security Algorithm (or just algorithm).  For example, 

   more than one DS record with DNSKEY algorithm TBD

is better as just

   more than one DS record with algorithm TBD

DW

> On Jul 13, 2020, at 10:16 AM, Peter van Dijk <[email-masked]> wrote:
> 
> Hello,
> 
> https://secure-web.cisco.com/1547Nd7TUhQCx--6BXQ2V7Fe6OsN72FFOIoB6X79e4tCF2s3ZpnvtGzBeZ35b3VZublqmT2QWLNxBE-H4UuDLJnh3itcQpBUb6pvqqG91nLQIfZ6JfJk-0nXyuSFLvD9anUSvqQjNwa7usrKjP9E-9zoOj8_4YAfpeb5yetnz5zz6RafsBHm8OG4n_AdFMl89cKxMT7P4a9IwkKlAutHh5GjZM1CDogcPKO6FLJ6QgiE6IYhafhiHX3qtYL2Z_veABcJwEj5EI9_m4VdsUVb3gfMkZPh0RCerOSzBeJ00Eqk/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin-01%23section-9
> 
> https://secure-web.cisco.com/1A25tPS76irHgdA_csUZGhdQB7R1rIbrOg1TW6d07W694zX71PQw1tAqCq4W-Yy-5i2h9ujLnVA3gCvVmF1AQkb04kNBNapCJrd3AIAma9QbnSKK_h65nrwXbi62Ylrxwjlpuook_wYJpyVmdsE3gvLF0fupzhFzjV6ufEXcxtz5FLv5H7STGDYGhD6pmlkXs4s4Ne03z_NV7Y5lT1r-RooYejeWscUws5c7DkEBTF3L_pTOYu_NRH1SA1SAGABwE_uaOR1fq1Gj1BIsI4yBwQw/https%3A%2F%2Fgithub.com%2FPowerDNS%2Fparent-signals-dot%2Ftree%2Fmaster%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin%2Fyardsticks
> 
> URL:            https://secure-web.cisco.com/1DsK2MVevadXT3GdniFfbtgOI396AfHCVKwwaV2-vAgI7z9Dd0q8NsHHtR5-Yvr8yKxH_PsQUrwCjagVNwgqtbfFNBSLwggZdZvleOtsjhVoeUmEteo8hKdrw77dn5UNKta2PuxqVGaZXwtZvs-4DQaP4xGc7jPUy3_Rl9Vtv_nHj5nYYy0pJo9XXQX5rtZ6xX1eZb29S5H51GbUukAdUD8vkiLEdfM49HeyTI1UBukpyYtaF3GsqY0KDHV7wEEhE_7DCsOfkqajfAZNXedeMR1XYjo04sw1CHYXBLmmkRBg/https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin-01.txt
> Status:         https://secure-web.cisco.com/1lJ9HOKB3lcr0FYkKcTfMImWTawCKcgf31T_3MoPvTc9gMCdIA_ajbmqsJ4rIMbt424s-ph7cAAqmJvl7MVr3ebT547Uz7sP9gA7HUHq-Jx2RjBRUFvf_sL64ZKYdT15vGJxq7MpweDRIPtOdTKsKNv-7NgTI_zAHJaHlrnwE3rB6ex-YZqGLp-UKZEns5N_nBOxy5aA_nGhijjVJn4ekYBrw2ZJ2AYXki5uFYvUSkauqxifxZ84Bd__Ltjygp285gciA0joIcrkb8IFNsx7kzw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin%2F
> Htmlized:       https://secure-web.cisco.com/1cFirxV4x2U2WbrlVzODCuwJ9pifdlZzpYB3Xq4t0hBEgNekIlAEC-Qthjgvz5EUvGHxGpLRuuJ0NL0AmSAMwJnYwkyUtIROhvZOTM45Ze3dx738rFrs2e_k-8D7glvhyQAD7w2Mjr1A3F3l2fjbaOmBsljJ1LJytf57_udaJAPOpJmsI6Ip1FR1kSyJo4jGWKohWGdfySdd04FQyHE_RzAkfHiIej1GUpf0sGSG1N6W1AGS0JqaP3n_z9B-8bpjygQQkaOVIplt3dkiTwRMmifie6zY8oHApoQ6Zt6MnNUs/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin-01
> Htmlized:       https://secure-web.cisco.com/1qb7nne1k8JWZ9GEh-uAWdl-u6Mhi6O8_8Pzl8QXe9Dzj2fke3Yp3Lu3zG4n-UuoqspLdcytKXzf4Oir91tyZjbWWaD-cZsFk3_rIp96C0u0ZHmuKvRpjk_-4bnUomgVl6Qdcq2SIHDRccnLkyPGFTetYLTLPWDtU006kgMiJew7_CgzsFQaZkG2JhrlctuexOkV9g16YgQt1-ZrC5Jyflx8kTXzTP265IEMzVMHLh_zQfudmDvNJs1EN3Vny1D04m6_Np0nUD5OdugJIIAXobQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin
> Diff:           https://secure-web.cisco.com/1GFziADh6Ps303cC7no5h066e5QUtC3w3B9PhlbQogmsIsTEpjHoxBjjV5jI_xo-E7Ouq6_sRJQ3DFzxTfv2gu_gJhENy9HaMRJlTv4ZdjbRml8xqknYL8ikBI4v9cPljlio4g31kh0mowVjkt8OQL1SYALLNcfTUESDQJPW6sDn8xm6yLlq4lN2FZBRrBCWYdy6CfzELZj69Ct4DPKqc37F7qIY3ryJXputr1-Dxq-ZRW-FFbM5q5uNI53j2do3TkuIN-x1Drh_97kESsgmkj9v1JiEoETl1rZsdF_NkL18/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-vandijk-dprive-ds-dot-signal-and-pin-01
> 
> Abstract:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://secure-web.cisco.com/1elCUqFgvC0UgZ2a2VlikLcYh0tCisMp6IB7ahB5AEcXCueMnDkz3rd9BglCkM6x8gnDfs6wyU7CA3FvMFsH2Zx6VxDHYQTdLdov0FYXMKmVyBJbJa8_880H0UV7hUzEfPlk7tyOzvGdyvTD5NmPUXuoCS5kfdkP9JSVfROSk01NwBVn0YAtZTelH75b9bc3HzLhyW3weRLkX7gHuJk-0XBo1b1ZV0gzjjAyd8DA1-j4GfRtdbhABtGh16GSzG_m_gf3ocdjA8ncwIr9kB45GsQVQ_eS73Hss3wAI_M-Emgw/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacy
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Jul 2020 15:29:49 -0400 (EDT)

> resolver to authoritative.

DoT can be enabled regardless. This draft is not about enabling DoT.
It is about saving a few roundtrips getting the right keys in a trusted
method. With some caveats that go along with it.

> The value 257, meanwhile, is believed to go down with registries much easier.

What is that believe based on?

> https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-01#section-9

It's not a good summary of the list discussion. I guess a draft isn't a
good place for that, but I don't see the concerns of me and Viktor
listed here at all.

    The biggest downside to this DS-based protocol is that a change in
    TLS keys on an auth may require DS updates for thousands or even
    hundreds of thousands of domains.  This issue is partially mitigated
    by allowing backup keys to be part of those DS sets.

I don't see how backup keys help here? If you have thousands of domains,
and one of them is unresponsble to DS updates, the auth server cannot
retire its key. With thousands of domains the change of that happening
very quickly goes to 100%. If you tell all of them to pre-publish a
backup (or really, new) key, then you are just postponing the problem
by one interation.

This solution simply cannot work at scale. At operating without scale
defeats the whole purpose of anonimity.

A much better solution is simply to use TLSA records at the nameservers.
Sure, your first domain incurs an extra RTT but that one RTT is made
back over all the domains hosted by that auth server. It leaves control
of the TLSA record where it belongs - at the owner of the Dot keypair.

A DS record can still be used to allow the child zone to make it
mandatory to use DoT or hardfail. But it does not (and should not)
have a public key embedded in it to do this.

A number of other items from our previous discussion I don't see back
here either, such as the discussion around CDS so that the client can
prevent a TLD scale size MITM DoT redirect from overruling its own
policy by the abusive parent playing its own DS DoT records against
the child's wishes. (And if I recall, you don't want to do this because
you are concerned about RTTs)

Paul

> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 20 Jul 2020 20:45:11 +0200

Hi Duane,

> While I remain neutral as to whether or not ds-dot-signal-and-pin is a good idea overall, you can count me as one that thinks flags=257 is a bad idea.  I don't think anything in 403[345] say that f…

I agree, there is no 'legal' basis there, and our document aims to
avoid needing any new legal basis (or, rephrased, we aim to avoid
updating any existing RFCs if we can). I wanted to put 257 in -01
exactly to get some more feedback on the choices we have there. An
informal small scale survey around a few registrars with extensive
experience in a lot of TLDs suggested that 0 would not go over well,
but we don't actually have a lot of data. (We are collecting data at 
https://github.com/PowerDNS/parent-signals-dot/issues/22 if anybody
wants to chime in with more facts).

I would also much prefer flags=0.

>    more than one DS record with algorithm TBD

Thanks! We've noted this at 
https://github.com/PowerDNS/parent-signals-dot/issues/37 and will
improve the wording for -02.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 20 Jul 2020 21:12:22 +0200

Hello Paul,

> DoT can be enabled regardless. This draft is not about enabling DoT.

I see my wording was inaccurate. Our proposal is an enabler technology
for DoT, but it is of course entirely possible to do DoT without this
document, or another document with a TLSA focus. Resolvers could even
probe (although, as I said before, as a resolver developer, and on
behalf of the operators running our software, I don't like that).

> method.

This is a misrepresentation that somehow won't go away. 'No additional
roundtrips' is a benefit that fell out of the protocol tree by
accident. Of course we like it, but it was never, and still is not, a
requirement.

> With some caveats that go along with it.
> 
> 

Very little data, see my reply to Duane a few minutes ago for more
words.

> It's not a good summary of the list discussion.

It was not intended to be :)

> I guess a draft isn't a good place for that, but I don't see the concerns of me and Viktor
> listed here at all.

(context: 
https://mailarchive.ietf.org/arch/msg/dns-privacy/ynMI5b-UOj-jE36drrmUQGFKZxg/
)

Isn't the first sentence of this paragraph you quoted a decent summary
of your concerns? :

> retire its key.

, without impacting that zone. That's a choice an operator can make.

> With thousands of domains the change of that happening

Correct. That's why we clearly point out this problem, and say that
backup keys only 'partially mitigate' it. I do not consider this
problem solved and I don't think it can be solved in scope of -this-
draft. It can be solved by doing something entirely different instead
(as you have been proposing in broad strokes), or it can be solved by
closer operator/registry relations (as noted in that section of -01). I
consider both of those options out of scope for our document.

> defeats the whole purpose of anonimity.

I agree that operating at scale is important for privacy purposes. But
I am more optimistic than you about this solution working at scale.

> A much better solution is simply to use TLSA records at the nameservers.

As I've said a few times before, I look forward to reading a draft that
specifies this clearly. If it was 'simple', I figure we'd be doing it
already!

> back over all the domains hosted by that auth server.

Definitely!

> It leaves control of the TLSA record where it belongs - at the owner of the Dot keypair.

Assuming that whoever signs the zone also operates the authoritatives,
but that's no worse (just different) than the assumptions our document
is making about the various parties involved with a zone.

> mandatory to use DoT or hardfail.

I just want to say that if our draft ends up being nothing more than
the inspiration for this aspect of a document that makes it to
deployment, I will still be very happy with how things turned out :-)

> But it does not (and should not) have a public key embedded in it to do this.

Depending on how you structure the TLSA proposal, you may need the DS
records to signal the names of the name servers that have TLSA, as has
come up in the -00 thread a few times.

> the child's wishes.

(context: 
https://mailarchive.ietf.org/arch/msg/dns-privacy/v8qUTMNVW_9W25GUXVStr2_Jk-A/
)

Either I don't understand the subtleties, or I'm not seeing the threat
model you are seeing. I've said before that I'm open to this if it
prevents a threat that is realistic.

(There is also, I feel, room for a variant where presence of the CDS is
mandatory but checking the CDS is up to the resolver operator,
perhaps?)

> (And if I recall, you don't want to do this because

I do care about RTTs, but I'll never say that we should strictly
optimise for RTTs at the cost of security - but that does not mean that
any security risk that can be imagined is serious enough to add
roundtrips to a protocol.

Kind regards,