[{"author": "Shane Kerr", "text": "

We appreciate you, Suzanne!

", "time": "2024-03-22T05:01:22Z"}, {"author": "Andrew Campling", "text": "

DNSOPs : the cradle to grave wg

", "time": "2024-03-22T05:01:50Z"}, {"author": "Daniel Gillmor", "text": "

circular lifecycle, Andrew: cradle to cradle

", "time": "2024-03-22T05:02:36Z"}, {"author": "Shane Kerr", "text": "

:grinning_face_with_smiling_eyes:

", "time": "2024-03-22T05:02:52Z"}, {"author": "Jim Reid", "text": "

I ID for each hat Wes can wear?

", "time": "2024-03-22T05:04:43Z"}, {"author": "Daniel Gillmor", "text": "

\"and please stick my features into the update too while you're at it\"

", "time": "2024-03-22T05:06:26Z"}, {"author": "George Michaelson", "text": "

yes please do not cause clash between a future DD and DNSOP and REGEXT

", "time": "2024-03-22T05:12:40Z"}, {"author": "George Michaelson", "text": "

Its not a giant bucket for all problems but it is a pretty handy smaller bucket for some problems

", "time": "2024-03-22T05:13:36Z"}, {"author": "Daniel Gillmor", "text": "

+1 to this approach. please adopt.

", "time": "2024-03-22T05:18:45Z"}, {"author": "Tim Wicinski", "text": "

I like this slide on modifications also.
\nThanks for chasing this Wes and Warren

", "time": "2024-03-22T05:21:22Z"}, {"author": "Jim Reid", "text": "

+1 Tim

", "time": "2024-03-22T05:21:35Z"}, {"author": "George Michaelson", "text": "

+1 because the optionality or not in algo has always confused the living heck out of me

", "time": "2024-03-22T05:21:43Z"}, {"author": "Daniel Gillmor", "text": "

if there are 10 changes that need to be made in a year, you can also bundle them into a single RFC

", "time": "2024-03-22T05:22:32Z"}, {"author": "\u00c9ric Vyncke", "text": "

@dkg let's hope ;-)

", "time": "2024-03-22T05:22:58Z"}, {"author": "Daniel Gillmor", "text": "

if this increases the velocity of improvements to these recommendations, that's also a good thing.

", "time": "2024-03-22T05:23:21Z"}, {"author": "Daniel Gillmor", "text": "

Ray: can you point to the housley draft you mentioned?

", "time": "2024-03-22T05:24:06Z"}, {"author": "Kazunori Fujiwara", "text": "

RFC 9157

", "time": "2024-03-22T05:24:09Z"}, {"author": "Rodney Van Meter", "text": "

https://datatracker.ietf.org/doc/draft-crocker-dnsop-dnssec-algorithm-lifecycle/

", "time": "2024-03-22T05:24:49Z"}, {"author": "Rodney Van Meter", "text": "

(I think that's the one.)

", "time": "2024-03-22T05:25:32Z"}, {"author": "Daniel Gillmor", "text": "

thanks, Rodney!

", "time": "2024-03-22T05:25:40Z"}, {"author": "Tim Wicinski", "text": "

\"existential questions\" - pretty much any DNS question

", "time": "2024-03-22T05:27:48Z"}, {"author": "Daniel Gillmor", "text": "

\"ISE perspective\": Eliot means Independent Submission Editor

", "time": "2024-03-22T05:28:30Z"}, {"author": "Daniel Gillmor", "text": "

+1 Eliot

", "time": "2024-03-22T05:29:05Z"}, {"author": "Benjamin Schwartz", "text": "

So any ISE draft can create a MAY, but only DNSOP can change it to MUST NOT? I guess this is fine in practice but the implied state machine here is kind of puzzling. If an ISE draft wants to add something then it must implicitly go through DNSOP review, so is it really ISE?

", "time": "2024-03-22T05:29:51Z"}, {"author": "Kazunori Fujiwara", "text": "

I think that RFC 9157 states the diferences between \"RFC Required\" and \"Standard Action\"

", "time": "2024-03-22T05:31:02Z"}, {"author": "Geoff Huston", "text": "

How do the authors propose to measure \"validators in the field\"?

", "time": "2024-03-22T05:31:19Z"}, {"author": "Geoff Huston", "text": "

From experience its not as simple as the spearker is making it out

", "time": "2024-03-22T05:31:49Z"}, {"author": "Geoff Huston", "text": "

I don't want tyo take up tyhe WG time, but here4 be large dragons!

", "time": "2024-03-22T05:33:16Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

Is there another IANA registry with descriptive information?

", "time": "2024-03-22T05:34:18Z"}, {"author": "Geoff Huston", "text": "

I don't think this (support by validators) is a simple as its being made out to be

", "time": "2024-03-22T05:34:21Z"}, {"author": "Eliot Lear", "text": "

Ben, according to RFC 9157, certain drafts are \"RFC Required\". That means either going through DNSOP or the ISE. In the case of the latter, a table entry is required, and the suggested approach is to set the value to MAY. The only time when the ISE should update that value is if a problem with the algorithm is found, and a separate independent submission wants to LOWER the recommendation to that entry. However, the IETF could do that too.

", "time": "2024-03-22T05:34:26Z"}, {"author": "Eliot Lear", "text": "

And in my view, that corner case WILL happen, just because algorithms have lifetimes.

", "time": "2024-03-22T05:35:00Z"}, {"author": "Eliot Lear", "text": "

(some of them long, some of them short)

", "time": "2024-03-22T05:35:17Z"}, {"author": "Shumon Huque", "text": "

The crocker-housley dnssec alg lifecycle draft also tried to answer this question, and has a phase for \"mainstream\" which if I recall is based on measurement and expert review.

", "time": "2024-03-22T05:36:46Z"}, {"author": "Shumon Huque", "text": "

But Geoff - I agree about \"there be dragons\" here.

", "time": "2024-03-22T05:37:23Z"}, {"author": "Shumon Huque", "text": "

We need to come to agreement on a process to judge the \"universality: of support of an algorithm.

", "time": "2024-03-22T05:37:58Z"}, {"author": "Daniel Gillmor", "text": "

+1 Jim

", "time": "2024-03-22T05:38:09Z"}, {"author": "Geoff Huston", "text": "

I tried to do this twice for ECDSA P-256 and frankly neither study came up with an unambigiuous measurement

", "time": "2024-03-22T05:38:15Z"}, {"author": "Andrew Campling", "text": "

+1 Jim

", "time": "2024-03-22T05:38:20Z"}, {"author": "Benjamin Schwartz", "text": "

@Eliot Lear I'm more puzzling over abuse of process situations. If I register algo XYZ as MAY via ISE, and DNSOP downgrades it to MUST NOT, I can't come back and re-register it as MAY under a new name. But the existence of that potential conflict means that any ISE RFC updating this registry must actually be reviewed by DNSOP, which makes me wonder whether it's actually helpful to do this via ISE.

", "time": "2024-03-22T05:38:24Z"}, {"author": "Eliot Lear", "text": "

@Ben what you are suggesting would be HIGHLY unlikely. Neither I nor my predecessors would EVER have allowed for such a situation, nor would I imagine my successors. The ISE ALWAYS consults with the IETF, and in particular experts in this group before publishing anything.

", "time": "2024-03-22T05:39:53Z"}, {"author": "Eliot Lear", "text": "

(well, anything related to DNS)

", "time": "2024-03-22T05:40:21Z"}, {"author": "George Michaelson", "text": "

my future novel about a malign ISE editor wreaking havoc on the IETF until an AD is tasked to take them down...

", "time": "2024-03-22T05:40:49Z"}, {"author": "George Michaelson", "text": "

Film Rights available

", "time": "2024-03-22T05:41:02Z"}, {"author": "Benjamin Schwartz", "text": "

Yes, I understand. Given the very obvious need for consultation and consent in this case, I'm just wondering if the ISE process is meaningfully distinct from the IESG process, and why it would be preferable.

", "time": "2024-03-22T05:41:16Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

@George Film teaser done by a LLM (Sora?)

", "time": "2024-03-22T05:41:25Z"}, {"author": "Eliot Lear", "text": "

So long as Rick Moranis can play me, I'm good.

", "time": "2024-03-22T05:41:30Z"}, {"author": "Benjamin Schwartz", "text": "

If the draft effectively has to go through a WG consensus call, why not just go through the IESG?

", "time": "2024-03-22T05:42:01Z"}, {"author": "Eliot Lear", "text": "

@Ben that is always a good question when establishing IANA policies.

", "time": "2024-03-22T05:42:04Z"}, {"author": "Eliot Lear", "text": "

But the drafts through the ISE go through what amounts to expert review, not WGLC.

", "time": "2024-03-22T05:43:02Z"}, {"author": "Benjamin Schwartz", "text": "

OK, I can understand that.

", "time": "2024-03-22T05:43:24Z"}, {"author": "George Michaelson", "text": "

if data is configured locally from a file, why is that the lowest priority? in effect it means something I define as input to config cannot be trusted to persist

", "time": "2024-03-22T05:43:58Z"}, {"author": "Daniel Gillmor", "text": "

DNSSEC secure data off the back of a truck

", "time": "2024-03-22T05:44:02Z"}, {"author": "Mark Andrews", "text": "

Verified, not verifiable.

", "time": "2024-03-22T05:44:08Z"}, {"author": "Daniel Gillmor", "text": "

DoBoaT

", "time": "2024-03-22T05:44:11Z"}, {"author": "George Michaelson", "text": "

surely, locally applied, all local config overrides all other things? how else can you do split horizon?

", "time": "2024-03-22T05:44:16Z"}, {"author": "George Michaelson", "text": "

sure, root.hints is bootstrap but I dislike ranking all config and local date to lowest status. \"it depends\"

", "time": "2024-03-22T05:45:26Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

@George Because it can easily be outdated?

", "time": "2024-03-22T05:46:22Z"}, {"author": "George Michaelson", "text": "

if you offer public service you should be offering signed data if you offer internal service your own lies are under your own control my house my rules (the vixie rule?) -maybe this is just me misunderstanding things but

", "time": "2024-03-22T05:47:15Z"}, {"author": "Mark Andrews", "text": "

ZONEMD doesn't change anything.

", "time": "2024-03-22T05:47:38Z"}, {"author": "Daniel Gillmor", "text": "

ha ha i do worry about having an AAA rating for an AAAA record

", "time": "2024-03-22T05:47:45Z"}, {"author": "St\u00e9phane Bortzmeyer", "text": "

@George We need to make a difference between root hints (which are... hints) and hardwired configuration you want to keep, no matter what (for split-horizon, for instance).

", "time": "2024-03-22T05:48:00Z"}, {"author": "George Michaelson", "text": "

I guess if you want fake data you hard deleg authority to a zone you \"own\" locally and thats about it.

", "time": "2024-03-22T05:48:30Z"}, {"author": "George Michaelson", "text": "

+1 ben thank you

", "time": "2024-03-22T05:49:24Z"}, {"author": "Kazunori Fujiwara", "text": "

I think that the ranking is different for each component of DNS (resolver, authoritative, some forwarder)

", "time": "2024-03-22T05:52:38Z"}, {"author": "Benjamin Schwartz", "text": "

Various Split Horizon and Hybrid Resolver situations have complicated hierarchies, for example. Also, parent-centric resolvers believe that glue records have \"higher priority\" than child records during a delegation.

", "time": "2024-03-22T05:54:46Z"}, {"author": "Jim Reid", "text": "

I agree with you Kazunori-san. It'll be very helpful to document this.

", "time": "2024-03-22T05:55:10Z"}, {"author": "Kazunori Fujiwara", "text": "

Split horizen or local-data in Unbound, some resolvers act multiple functions for each zone/ some cuts ( For example, Root is \"local root\", under \".mydomain\" is local zone)

", "time": "2024-03-22T05:57:04Z"}, {"author": "Benjamin Schwartz", "text": "

Nit: s/over TCP/with source IP verification/

", "time": "2024-03-22T05:59:31Z"}, {"author": "Daniel Gillmor", "text": "

the threat model described here is pretty fuzzy. I'm not convinced that there is anyone with on-path active interference that wouldn't be able to just reliably interfere with N requests

", "time": "2024-03-22T06:00:21Z"}, {"author": "Antoin Verschuren", "text": "

This proposal would be a downgrade for childs that know what they are doing. Could one opt-out for this?

", "time": "2024-03-22T06:02:18Z"}, {"author": "Antoin Verschuren", "text": "

Can someone please relay this at the mic?

", "time": "2024-03-22T06:02:48Z"}, {"author": "Mike Bishop", "text": "

So, DoT with a client cert?

", "time": "2024-03-22T06:03:09Z"}, {"author": "Benno Overeinder", "text": "

I can do that @Antoin.

", "time": "2024-03-22T06:03:21Z"}, {"author": "Daniel Gillmor", "text": "

if the parent believes it, then that doesn't defend the child

", "time": "2024-03-22T06:04:50Z"}, {"author": "Daniel Gillmor", "text": "

that is, i don't think @Antoin's question has been answered.

", "time": "2024-03-22T06:05:28Z"}, {"author": "Peter Thomassen", "text": "

Johan's proposal requires the child owner to nod off the received key (or the IP address that sent it), at the first time -- slide 8

", "time": "2024-03-22T06:08:23Z"}, {"author": "Antoin Verschuren", "text": "

Peter: What if an attacker would do this and I'm not aware?

", "time": "2024-03-22T06:09:04Z"}, {"author": "Antoin Verschuren", "text": "

Spoofed traffic unfortunately still exist while BCP38/84 is not universally implemented..

", "time": "2024-03-22T06:10:49Z"}, {"author": "Peter Thomassen", "text": "

My understanding is that the parent would contact the child owner (human) and say \"we've received this key from this IP [via TCP], does it look right to you?\" If that was an attacker, Johan's hope is that you would say \"no\".

\n

I'm not defending the proposal, I'm trying to manage the confusion by adding how I understand it :)

", "time": "2024-03-22T06:10:57Z"}, {"author": "Peter Thomassen", "text": "

(The title of slide 8 is \"In Some Cases Explicit Confirmation Will Be Needed\")

", "time": "2024-03-22T06:11:19Z"}, {"author": "Peter Thomassen", "text": "

of course, that's not automation in the end.

", "time": "2024-03-22T06:11:40Z"}, {"author": "Antoin Verschuren", "text": "

So my question is if I could flag somhow that for my delegation this explicit confirmation is always needed...

", "time": "2024-03-22T06:12:01Z"}, {"author": "Benjamin Schwartz", "text": "

My point is that DoBoaT clients will place a higher level of trust in DNSSEC-signed zones, so allowing DNSSEC signing from an insecure bootstrap could give an attacker more leverage.

", "time": "2024-03-22T06:12:01Z"}, {"author": "Christian Huitema", "text": "

There are ways to do this verification using other channels, for example getting a short hash of a key over the phone.

", "time": "2024-03-22T06:12:25Z"}, {"author": "Benjamin Schwartz", "text": "

It seems like maybe the \"over TCP\" part is a red herring, and the real value here is in in-band \"key proposal\", which is always validated out of band before being used for anything that could amplify an attack.

", "time": "2024-03-22T06:13:34Z"}, {"author": "Daniel Gillmor", "text": "

@Antoin: i think the recommendation would need to tell the parent \"do not enable this by default without confirmation for all child zones\", which maybe reduces the appeal of the draft a bit.

", "time": "2024-03-22T06:14:32Z"}, {"author": "Benjamin Schwartz", "text": "

Multi-Signer!

", "time": "2024-03-22T06:16:02Z"}, {"author": "Mark Andrews", "text": "

broken multi-signer

", "time": "2024-03-22T06:16:22Z"}, {"author": "Benjamin Schwartz", "text": "

That's the same thing

", "time": "2024-03-22T06:16:38Z"}, {"author": "Shumon Huque", "text": "

It appears that the gdomains and wix setup is an incorrect attempt to setup DNSSEC across multiple providers without any key coordination. So it is broken multi-signer, but not RFC 8901 multisigner,

", "time": "2024-03-22T06:20:55Z"}, {"author": "Eliot Lear", "text": "

Thanks everyone! Safe travels back to those who are there.

", "time": "2024-03-22T06:22:35Z"}, {"author": "Andrew Campling", "text": "

Thank you chairs!

", "time": "2024-03-22T06:22:40Z"}, {"author": "Robert Carolina", "text": "

Bye!

", "time": "2024-03-22T06:22:41Z"}, {"author": "Nigel Hickson", "text": "

Thank you for WG Session

", "time": "2024-03-22T06:22:43Z"}, {"author": "Shumon Huque", "text": "

8901 requires cross-importation of CDS/CDNSKEY so that there is common view across all the nameservers.

", "time": "2024-03-22T06:22:44Z"}]