DNSOP WG IETF 113, Vienna 2022-03-22 Minutes by Paul Hoffman Text on slides is not reproduced here ~125 people in MeetEcho Administrivia Sent longer note top the mailing list with full status https://mailarchive.ietf.org/arch/msg/dnsop/jZ2OYzwvGaHLD9caC4a4Q_pXRMk Warren Kumari: Would really like something in addition Discussed with the IESG to start up a short WG for DNSSEC-as-BCP, weren't interested Asks WG for a favor to move this to the front of the queue Adjustments for Multi-signer: Ulrich Wisser Request to consider changes to RFC 4034 about requiring signatures for all algorithms Wants more discussion on list Negative Caching of DNS Resolution Failures draft-dwmtwc-dnsop-caching-resolution-failures, Duane Wessels Also presented at the DNS-OARC meeting in 2022-02 Paul Wouters: Why is exponential backoff a must? Duane: Most important is "at least 5 seconds" Would be willing to make this mandatory Ralf Weber: Supports adoption Lars-Johan Liman: Supports adoption Hazel Smith: Good idea What proportion is coming from large public resolvers? Are these restrictions supposed to be across all anycast addresses? Duane: This is per backend server Maybe can be more specific in language Sees thousands of queries per second from each backend server Jim Reid: Strong support Wants the numbers of seconds to wait to be more evidence-based Was the bulk from a small number of resolvers? Duane: Verisign identified some of the sources, including the large recursive resolvers (by address) WG chairs will send out call for adoption soon DNS Referral Glue Requirements draft-ietf-dnsop-glue-is-not-optional, Duane Wessels Ben Schwartz: Terminology is confusing, with conflicting defintions in different RFCs Doesn't think "referral glue" distinction is helpful Should be from parents uniformly Duane: But we have sibling glue different than in-domain glue Important distinction is location Paul Hoffman: Put definition in the terminology document Brett Carr: Put it in the terminology doucment Good for training new staff Keep the terminology document active Ralf: All glue is for referral Not sure if taking out the registry requirement is good If a registry doesn't need to implement this, we are not gaining anything Duane: Take this to the list Different registries have different modes of operation, didn't want to change their models "Host object" use Hazel: Could not find a straight answer whether DS records are glue or not Alexander Mayrhofer: Important to differentiate "registry accepts data", "registry puts data in zone", "auth server sends data" This document focuses on third step Maybe second step could be in REGEXT WG Some things will go back to the list Using Service Bindings with DANE, draft-rebs-dnsop-svcb-dane, Ben Schwartz Wes Hardaker: The reason DANE changes the target is about control of the certificate Doesn't want to chase CDN certs, do the least amount of management Ben: Thinks this pushes the furthest in that direction dry-run DNSSEC draft-yorgos-dnsop-dry-run-dnssec, Willem Toorop Gavin Brown: Useful tool Validate DS algorithms from EPP, check the hash lengths Can't add dry run, would need an EPP extension Shane Kerr: Can this help with a root algorithm rollover? Willem: Useful for any dommain Ralf: Adding complexity to validation code Get clients to implement EDE Should not make resolver more and more complex Willem: Goal is to give operators more confidence Ben: This is a recurring paterm (stuff things into DS types) Should maybe have a general-purpose meta DS type Would we be better off providing some best practice on how to set up a duplicate parallel zone Stateful Hash-Based Signatures for DNSSEC draft-afrvrd-dnsop-stateful-hbs-for-dnssec, Roland van Rijswijk-Deij Stephen Farrell: "Safe" is not the whole thing Roland: Must stop with the finite number of signatures Gavin: How much state needs to be stored, and for how long? Roland: Which key has been used (sequence number) for the lifetime of the key Have a finite time for your key, need to roll before you finish Roland: Depends on parameter choices Should implement but not use? Rolamd: Maybe for the root and TLDs? Would be not be MUST implement, MUST be able to valdidated Paul: Would not want adoption until the implementation aspects doc is published Stephen: Bad idea all arond Never think about stateful signatures for DNSSEC Peter Thomassen: Confused about how it could be not preferred but implemented Roland: Should be implemented but not deployed Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries draft-eastlake-dnsop-expressing-qos-requirements, Donald Eastlake III Ben: This sounds like a job for service bindings Doesn't like the idea of putting this in a label very appealing Use SVBC instead Donald: Requires application know about SVCB, but this could be used without Ulrich: QoS is a property of the network path How would resolver know about the path? Structured Data for Filtered DNS draft-wing-dnsop-structured-dns-error-page, Tirumal Reddy Ralf: Shows good usage of extended errors, has an experimental implementation Tommy Pauly: Supportive of this area, wants adoption Ben: Meant for the client that opens a web page that is selected by the resolver Very different security model than what we have now Wants it to be truly machine-readable, not presented to the user Tiru: Text fields are optional ----- ChatLogs ``` [08:58:57] https://klok.sidnlabs.nl:8123/ :wink: [09:01:54] Ah, that's good. [09:02:07] Looks like a good turnout on-site....hello all! [09:02:50] wrong slide?? [09:02:57] ;-) [09:03:20] Hello ! [09:03:21] @Suzanne: possibly the busiest room so far this week? [09:15:13] Ulrich, where does that discussion start? I see the new thread this Sunday, started by Libor, and I'm wondering what came before. [09:17:14] Remedial Meetecho training for session chairs :slightly_smiling_face: [09:17:35] @all: remote participants in meetecho can join the queue directly, but if you're in jabber (not in meetecho) and have a comment for the mic, please prefix it in the chat with MIC: and I'll read it out for you [09:18:38] @Andrew: there's always a glitch somewhere....good to get it out of the way early ;-) [09:19:33] Fair comment. In truth, the hybrid Meetecho experience has been pretty good so far …… [09:21:42] we're getting foldback from the room. [09:21:50] I'm hearing a slight echo (which I think is Duane's audio being picked up on the room mics, and then rebroadcast [09:21:53] its not yet a feedback loop but I worry it could be [09:23:19] (Just a reminder to remote presenters: the easiest way to talk over the reverb is to mute the room audio using the mute button in the bottom right of Meetecho.) [09:23:37] the speakers (er not the people, the black boxes on stilts) in the room could be turned down which would make my ears happier and reduce echo/feedback [09:24:53] fanf: going to do that right niw [09:24:56] *now [09:27:17] Ironically for those of us in the room it’s hardest to hear in-room mic comments - the remote speakers are very clear [09:28:31] I'm fully in favor of these requirements, but do wonder what practical effect it will have in the wondrous Internet of Things. Better to state it, of course, so at least small implementations have a better chance of doing the right thing. [09:29:17] Strongly support (Brian Dickson of GoDaddy). Fine with tweaking after adoption. [09:29:20] Scale the cache duration based on RTT :-) [09:29:35] (Yes, what Jim is saying re which implementations are most implicated.) [09:29:42] Strong support for this from me. Something we should of probably done quite some time ago (benefit of hindsight of course) [09:29:52] The question is - will an RFC change obviously demented misbehaviour? The answer is no! Unfortunately, [09:30:51] Mmm, it is most likely to have an effect if it turns out BIND or Unbound or Google or Umbrella was somehow a big part of the problem. Maybe even dnsmasq. Not so much Joe's Special IoT DNS. [09:31:01] (Sorry Joe) [09:31:30] I think its custom resolvers running in large resolver farms with loose orchestration - way outside conventional RFC space [09:31:33] David: I don't think too many IoT devices are trying to resolve facebook.com in full-recursive mode. [09:31:49] https://blog.verisign.com/security/facebook-dns-outage/ [09:32:18] I believe that is the post Duane was referring to [09:33:04] Right, fair point about IoT specifically. [09:33:38] I for one would have preferred glue to be narrow in definition [09:33:57] I think term misappropriation is a huge problem in IETF. we do it all the time, hijacking somebody else's core concept [09:33:58] agree. using referral glue to be specific seems prudent [09:34:11] +1 [09:34:29] glue is about data origin, so "referral glue" sounds a bit weird (denoting the _use_ of glue) [09:34:58] I don't get "referral glue". Of course all glue is for referral, including the various things contemplated in DPRIVE. [09:35:03] referrals could also be filled by auth data, which is not glue at all [09:35:12] I think a reference to what we mean by "glue" is very useful for this document; be it in this draft or in another (published and referenced) document [09:35:19] less concerned with exact term than that we have a specific term for A/AAAA glue only [09:35:47] I would like to see the definitions put in the terminology RFC. The huge amount of terminology in DNS is often a barrier when trying to train new staff in ops. I'd like to move towards a single place for terminology. [09:35:56] and +1 on definition in doc [09:36:00] "nameserver glue"? But I also agree with the criticism of co-opting a well known term to mean something new and larger in scope. [09:36:04] I am stodgy old school on this. Glue is only the records you *need* to have in the answer because otherwise you're self-referrential and can't make any progress on the query. The other junk is just additional data. [09:36:13] +1 to definitions to terminology doc [09:36:42] imho as long as the terminology doc can be referenced from this document, sure! [09:36:49] "more work for Paul Hoffman HA HA AHAHAHAHAH!!!" [09:37:01] maybe "delegation glue"? [09:37:53] problem with Ben's "treat it all the same" makes definition creep a real problem [09:38:01] shameless plug [09:38:09] https://datatracker.ietf.org/doc/html/draft-koch-dns-glue-clarifications-05 [09:38:15] "sibling glue" just isn't a thing that currently exists in my brain. i'd prefer to not see it start to exist. [09:39:09] I would have thought that draft you plugged was worth referencing in this document Peter [09:40:33] sibling glue (from my pov) is something that exists more strongly in EPP than DNS - registries often require nameserver addresses for any names under their TLD, not just nameservers inside the registrant's domain [09:41:14] I'm hearing crazy distortion [09:41:18] same [09:41:19] yep [09:41:19] +1 [09:41:33] Reconnect audio stream? Maybe a bit got flipped [09:41:48] almost sounds like something is resting on the mic diaphram [09:41:50] Sibling glue is also explicitly included in RFC 1034/1035 although it did not have a separate name. [09:43:05] Checking audio [09:43:19] Audio seems fine here, was it a remote speaker? [09:43:33] yea, it was the remote speaker; seems it is all cleared up now [09:45:16] Alexander +1. Besides that, the problem with some registries is with SIBLING glues. The in-domain are covered in all cases. [09:50:42] Is chat still up? Seems weird I haven't had a new message in over 5 minutes. [09:50:54] yes [09:50:57] yes [09:51:51] do you want me to set up a bot to "yes" every 4 minutes and 50 seconds to reassure you? :-) [09:53:05] I'll just accept the warm glow of your earlier reassurance. [09:53:28] fair enough! :-) [09:53:55] i was moaning silently to myself and failing to turn that into any coherent words to put here [09:54:47] Perhaps we need a chat equivalent of background music to avoid awkward silences? :-) [09:55:04] Why would you want different keys for different transports? What am I missing here? [09:56:53] He seems to be hanging from the ceiling [09:56:56] Is he in Autralia? :-) [09:57:42] Calling from the bat cave? [09:57:43] I was wondering why every other video was upside down [09:59:24] You couldn't hear anything, right? [09:59:31] @Sam correct [09:59:37] it's a long story about the camera mount I'm using and keeping it out of field of view by mounting the camera upside down and then video flipping it. But I failed to turn on flipping. [10:00:09] That wasn’t a very long story after all [10:00:17] I could make it longer. [10:00:24] that was the tLDR [10:01:10] funny that they do dry runs for EVA in a swimming pool [10:01:16] Or given the camera reference, a tSLR? [10:01:30] :perfect: [10:01:47] argh, technology. Reiterating Wes's comments, I'm also concerned about adding needed operational synchronizations, e.g. with a CDN. It reminds me of one of the flaws in rfc2535 DNSSEC, where when a parent rolled its keys (think, in this case, CDN), it had to get every child to update their zone (think, in this case, customers of the CDN). [10:02:08] Sam: Yep, this is all about avoiding that [10:03:05] @fanf, if the astronauts get wet in the swimming pool, there's a much more serious problem to fix. [10:03:29] @Wes: I'm very confused/curious what kind of camera mount you're using that it would be in the field of view... Personally, I use a DSLR on a quick release plate, on a manfrotto ball head, on a hague camera supports angle bracket bolted to a Manfrotto Super Clamp, which is clamped to a Lindy 70cm desk clamped monitor mounting pole... which works really well to hold a 1DX2 above my VC monitor [10:05:54] Do these camera things support DNSSEC? :-) [10:06:18] Great question... it has a gigabit ethernet port, but I've not observed its DNS behaviour [10:06:34] Does it produce signed video? [10:07:06] that sounds like that would be a question for MOQ WG maybe? [10:07:14] ;) [10:07:49] I think signing on a per-video-frame basis might be too much overhead [10:09:36] jokes aside, that sounds like an application for stream ciphers. [10:09:44] @hazel: so I recently bought a mount to move the simple web camera off the top of my monitor to be closer to me, since the field was too wide (and zooming causes drop in quality). But the mount attaches to the bottom of the webcam, and the flexible mount's arm causes a drop into the field of the monitor's view. So by flipping the mount upside down, the arc of the flexible mount goes *up* allowing me to put the camera at the right spot out of the way of the monitor. If I was doing professional video zooming then I'd certainly sacrifice my monitor view for recording. But for my 4-6 hours of daily meetings, I'm lazy and haven't bought anything better. So the hack is to flip the video of an upside down camera instead (trivial in zoom, requires a fake virtual device for anything else). [10:10:15] ahhh [10:10:48] I should just start over with a new camera :-) [10:11:56] I am in favor of signing media so that you at least know the origin device as a way of dealing with deep fakes. [10:12:10] (I feed my video out of the camera as HDMI, and then through a HDMI distribution amplifier, so I get a copy for the confidence monitor plus a copy for each VC machine. The Google Meet box and the Intel NUC I use for Meetecho and Zoom each have a Magewell USB Capture HDMI Gen 2 device that takes the HDMI video and pretends to be a webcam to the OS :)) [10:18:10] Andrew: See talk #2 in https://datatracker.ietf.org/doc/agenda-113-hrpc/ [10:21:20] ha ha; @ben: didn't you push back on that for people that disliked the digest type hack you originally wrote? [10:22:09] INORITE! I said last time, let's please have a general purpose record to stop doing that, and got told it'll never happen. [10:22:48] Is Roland's audio clipping harshly for others too? [10:23:01] There's a difference here between "define a new META digest type" and "define a new NOTDS RR type" [10:23:02] Checking [10:23:10] he sounds fine in the room [10:23:11] I'm hearing echo again too [10:23:17] No clipping here [10:23:33] yeah, the clipping/crackling stopped the moment I asked, haha. [10:23:35] since he has headphones, it cannot be foldback his side [10:23:39] No echo or clipping in the room [10:23:56] and, I have been hearing quiet echos of every speaker so far, I assumed it was the room microphones picking up the room speakers [10:24:16] Is one of the chairs mic live? [10:24:29] Hazel: yes, that's what usually happens but we've been working to tweak this and minimize the impact [10:24:35] Noema <3 [10:24:36] ie benno/suz/tim [10:24:38] hash based sigs for DNSSEC seems like a bad idea to me - why not wait for a new signature algorithm from NIST that is not stateful? [10:24:46] DNSOP is in oneof the largest rooms, so physics don't help :) [10:24:48] I think the dog has a live mic [10:24:55] remider: stateful implies a finite number of signing operations before the private key leaks [10:24:57] Dog is in favour of PQC [10:25:01] BIFF. somebody somewhere has mail [10:25:39] stateful sigs != safe [10:25:59] https://www.amazon.com/How-Teach-Quantum-Physics-Your/dp/1416572295 [10:26:13] sftcd-x: That seems fairly manageable in DNSSEC. You update your zone as needed, and BIND rotates the keys as needed. [10:26:15] @Meetecho: ack. (I use a Biamp TesiraForte audio interface which does a pretty good job of hardware AEC (Acoustic Echo Cancellation) and has 12 mic inputs and 8 outputs, might be worth considering using something like that if you aren't already) [10:27:16] The audio is WebRTC based so there's an echo canceller involved too, plus we play with gains and mixer settings: looking into some hardware might be helpful in the future! [10:27:58] @ben: whether manageable or not, better to wait for something without that problem [10:28:08] qirg meets in the next session for those QC-curious [10:29:19] the break here is leaking the private key [10:30:44] The multi-tree model handles distributed signing and scalability though is more complex [10:31:04] @ben: also in terms of "manageable" - if the root zone is signed using classical crypto then use of PQC algs lower down isn't compelling, but stateful sigs at the root seems like a horrible thought [10:31:46] eddsa doesn't have the stateful unsafety problem [10:31:48] Needs a bit of explanation of how it would work for root. [10:32:38] The only special consideration for the root is that you need to give yourself enough margin to do a root rollover before you run out of signatures. [10:32:47] The draft of implementation considerations would discuss the issues. [10:33:00] on average how many signings per key are being made at present in the root? [10:33:14] if we understand the bounds as limits, we can say if the risk of those bounds is real. [10:34:29] Some configurations support 2^60 one time signing keys. [10:34:41] Not likely to run out. [10:35:07] Need to set tree sizes based on expected number of signings. [10:35:19] but all the code for handling the 2nd last signature operation is still needed (for no good reason) [10:35:50] With several orders of magnitude to deal with fudge factor. [10:37:00] We pulled implementation consideration out as it is quite a robust topic. [10:37:16] Signatures for SPHINCS+ are much larger [10:38:59] Also, we want a more considered discussion of implementation issues. It takes a bit of time to understand it. [10:39:58] If your machine turns off before having committed the sequence number to disk you have to rotate your keys [10:40:35] I think I unintentionally may have found a bug :-) [10:40:46] @Thom: silly question maybe, but... couldn't you just bump the number first, write it to disk, *then* use it? [10:41:29] (It was a fat finger though) [10:43:22] You can allocate enough OTS keys that you can checkpoint in batches. If doing in memory, just skip to the next batch if you go down. [10:45:01] sounds similar to implementations of "sequence" types in RDBMSes. (where you are much more worried about using a number twice than you are about skipping a number, and taking a batch of numbers in advance saves you from having to fsync for every one) [10:46:17] maybe this is a failure of imagination, ,but what is this draft FOR? what/who needs this QoS data? [10:46:31] on post-quantum stuff more generally: the *real* problem is the threat to confidentiality, even there, it's IMO still to early to standardise anything (we need more experience with newer algs 1st), for things like DNSSEC it makes no sense at all to try "get ahead of the game" esp if that'd involve figuring out how to avoid all the pitfalls of stateful sigs [10:46:56] nothing about DNSSEC is about confidentiality [10:47:04] its about trust in the label and RRSet. [10:47:17] all that is required is that you cannot forge its state [10:47:23] exactly - so let those with confidentiality problems figure out the PQ stuff first [10:48:05] it must be driven by belief use of flawed PQ algs means people CAN forge state [10:48:18] I don't think I really grok you here. I mean, I totally get the DNSSEC-is-not-about-confidentiality part. I don't get why we'd be unconcerned with the thread to authenticity. [10:48:21] algs, subsequently flawed by shors alg [10:48:45] if there is a belief continued use of RSA poses a risk to authenticity, then PQ is needed [10:48:50] @tale: because there's a lot of "figuring out" to be done before deployment of PQ stuff will be ready for primetime [10:49:11] Confidentiality requires solving the problem now. Authenticity requires solving the problem eventually. [10:49:22] there are two observations I'd like to make regarding that: PQC schemes are split into KEM/Key Exchange and Signature schemes, so letting the confidentiality people figure things out might not work. Second, as soon as PQC schemes are standardised, there will be pressure to support them, and I think it's good to start preparing for that now. [10:49:35] Okay, that part I'm fine with. I thought an argument was being made that somehow the authenticity part wasn't somehow relevant. [10:49:57] @roland: in this case, I think that's not "preparing" but rather "succumbing" and to what's (for now) a fashion choide [10:50:09] at this point this feels like a fully academic endeavour, so perhaps best addressed in that real rather than in the iEtf [10:50:23] Will the server return QoS info for the resolver or the end client> [10:50:53] @Joao: IRTF? [10:50:55] (I was referring to the PQC item) [10:50:59] Vicky: Yeah, I don't understand exactly. I can sort of imagine a response that says "BTW, this server is ~~XX ms away from you" [10:51:09] IRTF would be a lot more appropriate, yes [10:51:21] btw, if people start working on some kind of PQ-DNSSEC, it's 100% for sure that people will propose ways of signing with >1 alg (a mix of classical and new PQ algs), so if dnsop goes there, dealing with that'll be part of the price to pay [10:52:09] @sftcd-x: the point of this draft is not to succumb to any fashions ;-), HBS-es are _old_ and proven, hence our idea to standardise a failsafe. Happy to receive feedback or pushback on that from the WG. [10:52:15] is JSON capable of surviving DNS string compression? [10:52:38] agreed. so let's not have dnsop take it until a) there is a reasonable need and b) it has been figured out elsewhere [10:52:53] George: Compression would not be applied here, so there's no worry there [10:53:10] and @sftcd-x: yes, when talking PQC, multi-algorithm signing is just around the corner, that is a valid concern (with all the pain it brings) [10:53:13] @roland: yes the idea of HBS is old, and can be secure but afaik basically *nobody* has experience in using any of the RFCs on those topics so I really can't see that as in any way "safe" [10:53:44] The stateful HBS algorithms have been specified for message signing in two RFCs [10:54:16] @sftcd-x is your concern mostly operational? There is ample cryptoanalytic research supporting the security of HBS schemes. [10:54:16] Thanks Ben. I had memory (wrong I guess) that payload was compressed, but if not, then no worries! [10:54:33] @roland: I have >1 concern (sorry;-) [10:55:14] but yes, the utter lack of experience in real use of HBS means, for me, they can't be a current failsafe [10:55:19] +1 to proceeding with this draft (ie Structured Data for Filtered DNS) in order to improve transparency [10:55:21] The stareful HBS algorithms are also NIST specified in NIS SP 800-208 [10:55:31] Ben's comments are echoes of comments made when Tiramul first presented on this [10:55:41] The client behavior of actually using the page can be worked out [10:56:52] Hazel Smith_web_993 re: hbs: getting that assurance from the file system is not trivial with all the weird layers of caching… [10:57:49] Thanks everyone!! [10:58:00] Thanks! Hybrid was smooth! [10:58:05] Compliments to the chairs! [10:58:12] +1 [10:58:25] thanks Roland! Also shout-out to @meetecho for the new features. [10:58:28] Yep, +1, hybrid with MeetEcho and the mobile line joining thing seemed to work well [10:59:00] Glad to be of help! ```