[{"author": "Donald Eastlake", "text": "sound level seems very low to me
", "time": "2022-03-22T09:01:42Z"}, {"author": "Donald Eastlake", "text": "Ah, that's good.
", "time": "2022-03-22T09:01:55Z"}, {"author": "Suzanne Woolf", "text": "Looks like a good turnout on-site....hello all!
", "time": "2022-03-22T09:02:08Z"}, {"author": "MarcoSIDN@MacPro", "text": "Remote participants are loud and clear, chairs not so much
", "time": "2022-03-22T09:02:14Z"}, {"author": "Antoin Verschuren", "text": "internal room sound a bit low indeed....
", "time": "2022-03-22T09:02:35Z"}, {"author": "Brian Dickson", "text": "wrong slide??
", "time": "2022-03-22T09:02:51Z"}, {"author": "MarcoSIDN@MacPro", "text": ";-)
", "time": "2022-03-22T09:02:58Z"}, {"author": "Tim Wicinski", "text": "Hello !
", "time": "2022-03-22T09:03:21Z"}, {"author": "Andrew Campling", "text": "@Suzanne: possibly the busiest room so far this week?
", "time": "2022-03-22T09:03:22Z"}, {"author": "Samuel Weiler", "text": "Ulrich, where does that discussion start? I see the new thread this Sunday, started by Libor, and I'm wondering what came before.
", "time": "2022-03-22T09:15:14Z"}, {"author": "Andrew Campling", "text": "Remedial Meetecho training for session chairs :slightly_smiling_face:
", "time": "2022-03-22T09:17:15Z"}, {"author": "Suzanne Woolf", "text": "@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
", "time": "2022-03-22T09:17:36Z"}, {"author": "Suzanne Woolf", "text": "@Andrew: there's always a glitch somewhere....good to get it out of the way early ;-)
", "time": "2022-03-22T09:18:39Z"}, {"author": "Andrew Campling", "text": "Fair comment. In truth, the hybrid Meetecho experience has been pretty good so far \u2026\u2026
", "time": "2022-03-22T09:19:34Z"}, {"author": "George Michaelson", "text": "we're getting foldback from the room.
", "time": "2022-03-22T09:21:43Z"}, {"author": "Jonathan Reed", "text": "I'm hearing a slight echo (which I think is Duane's audio being picked up on the room mics, and then rebroadcast
", "time": "2022-03-22T09:21:51Z"}, {"author": "George Michaelson", "text": "its not yet a feedback loop but I worry it could be
", "time": "2022-03-22T09:21:54Z"}, {"author": "Benjamin Schwartz", "text": "(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.)
", "time": "2022-03-22T09:23:20Z"}, {"author": "fanf", "text": "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
", "time": "2022-03-22T09:23:38Z"}, {"author": "Meetecho", "text": "fanf: going to do that right niw
", "time": "2022-03-22T09:24:54Z"}, {"author": "Meetecho", "text": "*now
", "time": "2022-03-22T09:24:57Z"}, {"author": "Andrew Campling", "text": "Ironically for those of us in the room it\u2019s hardest to hear in-room mic comments - the remote speakers are very clear
", "time": "2022-03-22T09:27:18Z"}, {"author": "David Lawrence", "text": "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.
", "time": "2022-03-22T09:28:32Z"}, {"author": "Brian Dickson", "text": "Strongly support (Brian Dickson of GoDaddy). Fine with tweaking after adoption.
", "time": "2022-03-22T09:29:18Z"}, {"author": "Benjamin Schwartz", "text": "Scale the cache duration based on RTT :-)
", "time": "2022-03-22T09:29:21Z"}, {"author": "David Lawrence", "text": "(Yes, what Jim is saying re which implementations are most implicated.)
", "time": "2022-03-22T09:29:36Z"}, {"author": "Brett Carr", "text": "Strong support for this from me. Something we should of probably done quite some time ago (benefit of hindsight of course)
", "time": "2022-03-22T09:29:43Z"}, {"author": "Geoff Huston", "text": "The question is - will an RFC change obviously demented misbehaviour? The answer is no! Unfortunately,
", "time": "2022-03-22T09:29:53Z"}, {"author": "David Lawrence", "text": "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.
", "time": "2022-03-22T09:30:52Z"}, {"author": "David Lawrence", "text": "(Sorry Joe)
", "time": "2022-03-22T09:31:02Z"}, {"author": "Geoff Huston", "text": "I think its custom resolvers running in large resolver farms with loose orchestration - way outside conventional RFC space
", "time": "2022-03-22T09:31:31Z"}, {"author": "Benjamin Schwartz", "text": "David: I don't think too many IoT devices are trying to resolve facebook.com in full-recursive mode.
", "time": "2022-03-22T09:31:34Z"}, {"author": "Tim Wicinski", "text": "https://blog.verisign.com/security/facebook-dns-outage/
", "time": "2022-03-22T09:31:50Z"}, {"author": "Tim Wicinski", "text": "I believe that is the post Duane was referring to
", "time": "2022-03-22T09:32:19Z"}, {"author": "David Lawrence", "text": "Right, fair point about IoT specifically.
", "time": "2022-03-22T09:33:05Z"}, {"author": "George Michaelson", "text": "I for one would have preferred glue to be narrow in definition
", "time": "2022-03-22T09:33:39Z"}, {"author": "George Michaelson", "text": "I think term misappropriation is a huge problem in IETF. we do it all the time, hijacking somebody else's core concept
", "time": "2022-03-22T09:33:58Z"}, {"author": "PE", "text": "agree. using referral glue to be specific seems prudent
", "time": "2022-03-22T09:33:59Z"}, {"author": "fanf", "text": "+1
", "time": "2022-03-22T09:34:12Z"}, {"author": "Peter Koch", "text": "glue is about data origin, so \"referral glue\" sounds a bit weird (denoting the _use_ of glue)
", "time": "2022-03-22T09:34:30Z"}, {"author": "Benjamin Schwartz", "text": "I don't get \"referral glue\". Of course all glue is for referral, including the various things contemplated in DPRIVE.
", "time": "2022-03-22T09:34:59Z"}, {"author": "Peter Koch", "text": "referrals could also be filled by auth data, which is not glue at all
", "time": "2022-03-22T09:35:04Z"}, {"author": "Peter Hessler", "text": "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
", "time": "2022-03-22T09:35:13Z"}, {"author": "PE", "text": "less concerned with exact term than that we have a specific term for A/AAAA glue only
", "time": "2022-03-22T09:35:20Z"}, {"author": "Brett Carr", "text": "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.
", "time": "2022-03-22T09:35:48Z"}, {"author": "PE", "text": "and +1 on definition in doc
", "time": "2022-03-22T09:35:57Z"}, {"author": "Shumon Huque", "text": "\"nameserver glue\"? But I also agree with the criticism of co-opting a well known term to mean something new and larger in scope.
", "time": "2022-03-22T09:36:01Z"}, {"author": "David Lawrence", "text": "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.
", "time": "2022-03-22T09:36:05Z"}, {"author": "George Michaelson", "text": "+1 to definitions to terminology doc
", "time": "2022-03-22T09:36:14Z"}, {"author": "Peter Hessler", "text": "imho as long as the terminology doc can be referenced from this document, sure!
", "time": "2022-03-22T09:36:43Z"}, {"author": "George Michaelson", "text": "\"more work for Paul Hoffman HA HA AHAHAHAHAH!!!\"
", "time": "2022-03-22T09:36:50Z"}, {"author": "PE", "text": "maybe \"delegation glue\"?
", "time": "2022-03-22T09:37:02Z"}, {"author": "PE", "text": "problem with Ben's \"treat it all the same\" makes definition creep a real problem
", "time": "2022-03-22T09:37:54Z"}, {"author": "Peter Koch", "text": "shameless plug <https://datatracker.ietf.org/doc/html/draft-koch-dns-glue-clarifications-05>
", "time": "2022-03-22T09:38:02Z"}, {"author": "Peter Koch", "text": "https://datatracker.ietf.org/doc/html/draft-koch-dns-glue-clarifications-05
", "time": "2022-03-22T09:38:10Z"}, {"author": "David Lawrence", "text": "\"sibling glue\" just isn't a thing that currently exists in my brain. i'd prefer to not see it start to exist.
", "time": "2022-03-22T09:38:16Z"}, {"author": "George Michaelson", "text": "I would have thought that draft you plugged was worth referencing in this document Peter
", "time": "2022-03-22T09:39:10Z"}, {"author": "fanf", "text": "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
", "time": "2022-03-22T09:40:34Z"}, {"author": "Benjamin Schwartz", "text": "I'm hearing crazy distortion
", "time": "2022-03-22T09:41:15Z"}, {"author": "Jonathan Reed", "text": "same
", "time": "2022-03-22T09:41:19Z"}, {"author": "Wes Hardaker", "text": "yep
", "time": "2022-03-22T09:41:20Z"}, {"author": "Samuel Weiler", "text": "+1
", "time": "2022-03-22T09:41:20Z"}, {"author": "Dan McArdle", "text": "Reconnect audio stream? Maybe a bit got flipped
", "time": "2022-03-22T09:41:34Z"}, {"author": "Peter Hessler", "text": "almost sounds like something is resting on the mic diaphram
", "time": "2022-03-22T09:41:49Z"}, {"author": "Shumon Huque", "text": "Sibling glue is also explicitly included in RFC 1034/1035 although it did not have a separate name.
", "time": "2022-03-22T09:41:51Z"}, {"author": "Meetecho", "text": "Checking audio
", "time": "2022-03-22T09:43:06Z"}, {"author": "Meetecho", "text": "Audio seems fine here, was it a remote speaker?
", "time": "2022-03-22T09:43:20Z"}, {"author": "Peter Hessler", "text": "yea, it was the remote speaker; seems it is all cleared up now
", "time": "2022-03-22T09:43:34Z"}, {"author": "Hugo Salgado", "text": "Alexander +1. Besides that, the problem with some registries is with SIBLING glues. The in-domain are covered in all cases.
", "time": "2022-03-22T09:45:17Z"}, {"author": "David Lawrence", "text": "Is chat still up? Seems weird I haven't had a new message in over 5 minutes.
", "time": "2022-03-22T09:50:43Z"}, {"author": "Brian Dickson", "text": "yes
", "time": "2022-03-22T09:50:55Z"}, {"author": "Geoff Huston", "text": "yes
", "time": "2022-03-22T09:50:58Z"}, {"author": "Geoff Huston", "text": "do you want me to set up a bot to \"yes\" every 4 minutes and 50 seconds to reassure you? :-)
", "time": "2022-03-22T09:51:52Z"}, {"author": "David Lawrence", "text": "I'll just accept the warm glow of your earlier reassurance.
", "time": "2022-03-22T09:53:06Z"}, {"author": "Geoff Huston", "text": "fair enough! :-)
", "time": "2022-03-22T09:53:29Z"}, {"author": "fanf", "text": "i was moaning silently to myself and failing to turn that into any coherent words to put here
", "time": "2022-03-22T09:53:56Z"}, {"author": "Andrew Campling", "text": "Perhaps we need a chat equivalent of background music to avoid awkward silences? :-)
", "time": "2022-03-22T09:54:48Z"}, {"author": "Geoff Huston", "text": "Why would you want different keys for different transports? What am I missing here?
", "time": "2022-03-22T09:55:05Z"}, {"author": "Andrew Fregly", "text": "He seems to be hanging from the ceiling
", "time": "2022-03-22T09:56:54Z"}, {"author": "Donald Eastlake", "text": "Is he in Autralia? :-)
", "time": "2022-03-22T09:56:57Z"}, {"author": "Andrew Campling", "text": "Calling from the bat cave?
", "time": "2022-03-22T09:57:43Z"}, {"author": "Geoff Huston", "text": "I was wondering why every other video was upside down
", "time": "2022-03-22T09:57:44Z"}, {"author": "Samuel Weiler", "text": "You couldn't hear anything, right?
", "time": "2022-03-22T09:59:25Z"}, {"author": "Suzanne Woolf", "text": "@Sam correct
", "time": "2022-03-22T09:59:32Z"}, {"author": "Wes Hardaker", "text": "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.
", "time": "2022-03-22T09:59:38Z"}, {"author": "Thom", "text": "That wasn\u2019t a very long story after all
", "time": "2022-03-22T10:00:10Z"}, {"author": "Wes Hardaker", "text": "I could make it longer.
", "time": "2022-03-22T10:00:18Z"}, {"author": "Wes Hardaker", "text": "that was the tLDR
", "time": "2022-03-22T10:00:25Z"}, {"author": "fanf", "text": "funny that they do dry runs for EVA in a swimming pool
", "time": "2022-03-22T10:01:11Z"}, {"author": "Brian Dickson", "text": "Or given the camera reference, a tSLR?
", "time": "2022-03-22T10:01:17Z"}, {"author": "Wes Hardaker", "text": ":perfect:
", "time": "2022-03-22T10:01:31Z"}, {"author": "Samuel Weiler", "text": "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).
", "time": "2022-03-22T10:01:48Z"}, {"author": "Benjamin Schwartz", "text": "Sam: Yep, this is all about avoiding that
", "time": "2022-03-22T10:02:09Z"}, {"author": "Jim Reid", "text": "@fanf, if the astronauts get wet in the swimming pool, there's a much more serious problem to fix.
", "time": "2022-03-22T10:03:06Z"}, {"author": "Hazel Smith", "text": "@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
", "time": "2022-03-22T10:03:30Z"}, {"author": "Jim Reid", "text": "Do these camera things support DNSSEC? :-)
", "time": "2022-03-22T10:05:55Z"}, {"author": "Hazel Smith", "text": "Great question... it has a gigabit ethernet port, but I've not observed its DNS behaviour
", "time": "2022-03-22T10:06:19Z"}, {"author": "Andrew Fregly", "text": "Does it produce signed video?
", "time": "2022-03-22T10:06:35Z"}, {"author": "Hazel Smith", "text": "that sounds like that would be a question for MOQ WG maybe?
", "time": "2022-03-22T10:07:07Z"}, {"author": "Hazel Smith", "text": ";)
", "time": "2022-03-22T10:07:15Z"}, {"author": "Andrew Fregly", "text": "I think signing on a per-video-frame basis might be too much overhead
", "time": "2022-03-22T10:07:50Z"}, {"author": "Hazel Smith", "text": "jokes aside, that sounds like an application for stream ciphers.
", "time": "2022-03-22T10:09:37Z"}, {"author": "Wes Hardaker", "text": "@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).
", "time": "2022-03-22T10:09:45Z"}, {"author": "Hazel Smith", "text": "ahhh
", "time": "2022-03-22T10:10:16Z"}, {"author": "Wes Hardaker", "text": "I should just start over with a new camera :-)
", "time": "2022-03-22T10:10:49Z"}, {"author": "Andrew Fregly", "text": "I am in favor of signing media so that you at least know the origin device as a way of dealing with deep fakes.
", "time": "2022-03-22T10:11:57Z"}, {"author": "Hazel Smith", "text": "(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 :))
", "time": "2022-03-22T10:12:11Z"}, {"author": "Benjamin Schwartz", "text": "Andrew: See talk #2 in https://datatracker.ietf.org/doc/agenda-113-hrpc/
", "time": "2022-03-22T10:18:11Z"}, {"author": "Wes Hardaker", "text": "ha ha; @ben: didn't you push back on that for people that disliked the digest type hack you originally wrote?
", "time": "2022-03-22T10:21:21Z"}, {"author": "Jonathan Reed", "text": "INORITE! I said last time, let's please have a general purpose record to stop doing that, and got told it'll never happen.
", "time": "2022-03-22T10:22:10Z"}, {"author": "Hazel Smith", "text": "Is Roland's audio clipping harshly for others too?
", "time": "2022-03-22T10:22:49Z"}, {"author": "Benjamin Schwartz", "text": "There's a difference here between \"define a new META digest type\" and \"define a new NOTDS RR type\"
", "time": "2022-03-22T10:23:02Z"}, {"author": "Meetecho", "text": "Checking
", "time": "2022-03-22T10:23:03Z"}, {"author": "Joao Damas", "text": "he sounds fine in the room
", "time": "2022-03-22T10:23:11Z"}, {"author": "Suzanne Woolf", "text": "I'm hearing echo again too
", "time": "2022-03-22T10:23:12Z"}, {"author": "Benjamin Schwartz", "text": "No clipping here
", "time": "2022-03-22T10:23:18Z"}, {"author": "Hazel Smith", "text": "yeah, the clipping/crackling stopped the moment I asked, haha.
", "time": "2022-03-22T10:23:34Z"}, {"author": "George Michaelson", "text": "since he has headphones, it cannot be foldback his side
", "time": "2022-03-22T10:23:36Z"}, {"author": "Jim Reid", "text": "No echo or clipping in the room
", "time": "2022-03-22T10:23:40Z"}, {"author": "Hazel Smith", "text": "and, I have been hearing quiet echos of every speaker so far, I assumed it was the room microphones picking up the room speakers
", "time": "2022-03-22T10:23:57Z"}, {"author": "George Michaelson", "text": "Is one of the chairs mic live?
", "time": "2022-03-22T10:24:17Z"}, {"author": "Meetecho", "text": "Hazel: yes, that's what usually happens but we've been working to tweak this and minimize the impact
", "time": "2022-03-22T10:24:30Z"}, {"author": "Tom Carpay", "text": "Noema <3
", "time": "2022-03-22T10:24:36Z"}, {"author": "George Michaelson", "text": "ie benno/suz/tim
", "time": "2022-03-22T10:24:37Z"}, {"author": "sftcd-x", "text": "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?
", "time": "2022-03-22T10:24:39Z"}, {"author": "Meetecho", "text": "DNSOP is in oneof the largest rooms, so physics don't help :)
", "time": "2022-03-22T10:24:47Z"}, {"author": "Geoff Huston", "text": "I think the dog has a live mic
", "time": "2022-03-22T10:24:49Z"}, {"author": "sftcd-x", "text": "remider: stateful implies a finite number of signing operations before the private key leaks
", "time": "2022-03-22T10:24:56Z"}, {"author": "Thom", "text": "Dog is in favour of PQC
", "time": "2022-03-22T10:24:58Z"}, {"author": "George Michaelson", "text": "BIFF. somebody somewhere has mail
", "time": "2022-03-22T10:25:02Z"}, {"author": "sftcd-x", "text": "stateful sigs != safe
", "time": "2022-03-22T10:25:40Z"}, {"author": "Jim Reid", "text": "https://www.amazon.com/How-Teach-Quantum-Physics-Your/dp/1416572295
", "time": "2022-03-22T10:26:00Z"}, {"author": "Benjamin Schwartz", "text": "sftcd-x: That seems fairly manageable in DNSSEC. You update your zone as needed, and BIND rotates the keys as needed.
", "time": "2022-03-22T10:26:14Z"}, {"author": "Hazel Smith", "text": "@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)
", "time": "2022-03-22T10:26:16Z"}, {"author": "Meetecho", "text": "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!
", "time": "2022-03-22T10:27:17Z"}, {"author": "sftcd-x", "text": "@ben: whether manageable or not, better to wait for something without that problem
", "time": "2022-03-22T10:27:59Z"}, {"author": "Suzanne Woolf", "text": "qirg meets in the next session for those QC-curious
", "time": "2022-03-22T10:28:09Z"}, {"author": "sftcd-x", "text": "the break here is leaking the private key
", "time": "2022-03-22T10:29:20Z"}, {"author": "Andrew Fregly", "text": "The multi-tree model handles distributed signing and scalability though is more complex
", "time": "2022-03-22T10:30:45Z"}, {"author": "sftcd-x", "text": "@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
", "time": "2022-03-22T10:31:05Z"}, {"author": "sftcd-x", "text": "eddsa doesn't have the stateful unsafety problem
", "time": "2022-03-22T10:31:47Z"}, {"author": "Andrew Fregly", "text": "Needs a bit of explanation of how it would work for root.
", "time": "2022-03-22T10:31:49Z"}, {"author": "Benjamin Schwartz", "text": "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.
", "time": "2022-03-22T10:32:39Z"}, {"author": "Andrew Fregly", "text": "The draft of implementation considerations would discuss the issues.
", "time": "2022-03-22T10:32:48Z"}, {"author": "George Michaelson", "text": "on average how many signings per key are being made at present in the root?
", "time": "2022-03-22T10:33:01Z"}, {"author": "George Michaelson", "text": "if we understand the bounds as limits, we can say if the risk of those bounds is real.
", "time": "2022-03-22T10:33:15Z"}, {"author": "Andrew Fregly", "text": "Some configurations support 2^60 one time signing keys.
", "time": "2022-03-22T10:34:30Z"}, {"author": "Andrew Fregly", "text": "Not likely to run out.
", "time": "2022-03-22T10:34:42Z"}, {"author": "Andrew Fregly", "text": "Need to set tree sizes based on expected number of signings.
", "time": "2022-03-22T10:35:08Z"}, {"author": "sftcd-x", "text": "but all the code for handling the 2nd last signature operation is still needed (for no good reason)
", "time": "2022-03-22T10:35:20Z"}, {"author": "Andrew Fregly", "text": "With several orders of magnitude to deal with fudge factor.
", "time": "2022-03-22T10:35:51Z"}, {"author": "Andrew Fregly", "text": "We pulled implementation consideration out as it is quite a robust topic.
", "time": "2022-03-22T10:37:01Z"}, {"author": "Andrew Fregly", "text": "Signatures for SPHINCS+ are much larger
", "time": "2022-03-22T10:37:17Z"}, {"author": "Andrew Fregly", "text": "Also, we want a more considered discussion of implementation issues. It takes a bit of time to understand it.
", "time": "2022-03-22T10:39:00Z"}, {"author": "Thom", "text": "If your machine turns off before having committed the sequence number to disk you have to rotate your keys
", "time": "2022-03-22T10:39:59Z"}, {"author": "Maarten Aertsen", "text": "I think I unintentionally may have found a bug :-)
", "time": "2022-03-22T10:40:36Z"}, {"author": "Hazel Smith", "text": "@Thom: silly question maybe, but... couldn't you just bump the number first, write it to disk, *then* use it?
", "time": "2022-03-22T10:40:47Z"}, {"author": "Maarten Aertsen", "text": "(It was a fat finger though)
", "time": "2022-03-22T10:41:30Z"}, {"author": "Andrew Fregly", "text": "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.
", "time": "2022-03-22T10:43:23Z"}, {"author": "Hazel Smith", "text": "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)
", "time": "2022-03-22T10:45:02Z"}, {"author": "Vicky Risk", "text": "maybe this is a failure of imagination, ,but what is this draft FOR? what/who needs this QoS data?
", "time": "2022-03-22T10:46:18Z"}, {"author": "sftcd-x", "text": "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
", "time": "2022-03-22T10:46:32Z"}, {"author": "George Michaelson", "text": "nothing about DNSSEC is about confidentiality
", "time": "2022-03-22T10:46:57Z"}, {"author": "George Michaelson", "text": "its about trust in the label and RRSet.
", "time": "2022-03-22T10:47:05Z"}, {"author": "George Michaelson", "text": "all that is required is that you cannot forge its state
", "time": "2022-03-22T10:47:18Z"}, {"author": "sftcd-x", "text": "exactly - so let those with confidentiality problems figure out the PQ stuff first
", "time": "2022-03-22T10:47:24Z"}, {"author": "George Michaelson", "text": "it must be driven by belief use of flawed PQ algs means people CAN forge state
", "time": "2022-03-22T10:48:06Z"}, {"author": "David Lawrence", "text": "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.
", "time": "2022-03-22T10:48:19Z"}, {"author": "George Michaelson", "text": "algs, subsequently flawed by shors alg
", "time": "2022-03-22T10:48:22Z"}, {"author": "George Michaelson", "text": "if there is a belief continued use of RSA poses a risk to authenticity, then PQ is needed
", "time": "2022-03-22T10:48:46Z"}, {"author": "sftcd-x", "text": "@tale: because there's a lot of \"figuring out\" to be done before deployment of PQ stuff will be ready for primetime
", "time": "2022-03-22T10:48:51Z"}, {"author": "Benjamin Schwartz", "text": "Confidentiality requires solving the problem now. Authenticity requires solving the problem eventually.
", "time": "2022-03-22T10:49:12Z"}, {"author": "Roland van Rijswijk-Deij", "text": "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.
", "time": "2022-03-22T10:49:23Z"}, {"author": "David Lawrence", "text": "Okay, that part I'm fine with. I thought an argument was being made that somehow the authenticity part wasn't somehow relevant.
", "time": "2022-03-22T10:49:36Z"}, {"author": "sftcd-x", "text": "@roland: in this case, I think that's not \"preparing\" but rather \"succumbing\" and to what's (for now) a fashion choide
", "time": "2022-03-22T10:49:58Z"}, {"author": "Joao Damas", "text": "at this point this feels like a fully academic endeavour, so perhaps best addressed in that real rather than in the iEtf
", "time": "2022-03-22T10:50:10Z"}, {"author": "Jim Reid", "text": "Will the server return QoS info for the resolver or the end client>
", "time": "2022-03-22T10:50:24Z"}, {"author": "Andrew Campling", "text": "@Joao: IRTF?
", "time": "2022-03-22T10:50:54Z"}, {"author": "Joao Damas", "text": "(I was referring to the PQC item)
", "time": "2022-03-22T10:50:56Z"}, {"author": "Benjamin Schwartz", "text": "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\"
", "time": "2022-03-22T10:51:00Z"}, {"author": "Joao Damas", "text": "IRTF would be a lot more appropriate, yes
", "time": "2022-03-22T10:51:10Z"}, {"author": "sftcd-x", "text": "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
", "time": "2022-03-22T10:51:22Z"}, {"author": "Roland van Rijswijk-Deij", "text": "@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.
", "time": "2022-03-22T10:52:10Z"}, {"author": "George Michaelson", "text": "is JSON capable of surviving DNS string compression?
", "time": "2022-03-22T10:52:16Z"}, {"author": "Joao Damas", "text": "agreed. so let's not have dnsop take it until a) there is a reasonable need and b) it has been figured out elsewhere
", "time": "2022-03-22T10:52:39Z"}, {"author": "Benjamin Schwartz", "text": "George: Compression would not be applied here, so there's no worry there
", "time": "2022-03-22T10:52:54Z"}, {"author": "Roland van Rijswijk-Deij", "text": "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)
", "time": "2022-03-22T10:53:11Z"}, {"author": "sftcd-x", "text": "@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\"
", "time": "2022-03-22T10:53:14Z"}, {"author": "Andrew Fregly", "text": "The stateful HBS algorithms have been specified for message signing in two RFCs
", "time": "2022-03-22T10:53:45Z"}, {"author": "Roland van Rijswijk-Deij", "text": "@sftcd-x is your concern mostly operational? There is ample cryptoanalytic research supporting the security of HBS schemes.
", "time": "2022-03-22T10:54:17Z"}, {"author": "George Michaelson", "text": "Thanks Ben. I had memory (wrong I guess) that payload was compressed, but if not, then no worries!
", "time": "2022-03-22T10:54:17Z"}, {"author": "sftcd-x", "text": "@roland: I have >1 concern (sorry;-)
", "time": "2022-03-22T10:54:34Z"}, {"author": "sftcd-x", "text": "but yes, the utter lack of experience in real use of HBS means, for me, they can't be a current failsafe
", "time": "2022-03-22T10:55:15Z"}, {"author": "Andrew Campling", "text": "+1 to proceeding with this draft (ie Structured Data for Filtered DNS) in order to improve transparency
", "time": "2022-03-22T10:55:20Z"}, {"author": "Andrew Fregly", "text": "The stareful HBS algorithms are also NIST specified in NIS SP 800-208
", "time": "2022-03-22T10:55:22Z"}, {"author": "George Michaelson", "text": "Ben's comments are echoes of comments made when Tiramul first presented on this
", "time": "2022-03-22T10:55:32Z"}, {"author": "Tommy Pauly", "text": "The client behavior of actually using the page can be worked out
", "time": "2022-03-22T10:55:42Z"}, {"author": "Thom", "text": "Hazel Smith_web_993 re: hbs: getting that assurance from the file system is not trivial with all the weird layers of caching\u2026
", "time": "2022-03-22T10:56:53Z"}, {"author": "Suzanne Woolf", "text": "Thanks everyone!!
", "time": "2022-03-22T10:57:50Z"}, {"author": "Roland van Rijswijk-Deij", "text": "Thanks! Hybrid was smooth!
", "time": "2022-03-22T10:58:01Z"}, {"author": "Roland van Rijswijk-Deij", "text": "Compliments to the chairs!
", "time": "2022-03-22T10:58:06Z"}, {"author": "Brian Dickson", "text": "+1
", "time": "2022-03-22T10:58:13Z"}, {"author": "Suzanne Woolf", "text": "thanks Roland! Also shout-out to @meetecho for the new features.
", "time": "2022-03-22T10:58:26Z"}, {"author": "Hazel Smith", "text": "Yep, +1, hybrid with MeetEcho and the mobile line joining thing seemed to work well
", "time": "2022-03-22T10:58:29Z"}, {"author": "Meetecho", "text": "Glad to be of help!
", "time": "2022-03-22T10:59:01Z"}]