IETF
add
add@jabber.ietf.org
Tuesday, November 8, 2022< ^ >
Meetecho has set the subject to: DPRIVE-ADD (IETF 113)
Room Configuration
Room Occupants

GMT+0
[08:36:49] cabo joins the room
[08:59:50] cabo leaves the room
[09:29:33] cabo joins the room
[09:52:11] cabo joins the room
[09:52:21] cabo leaves the room
[09:53:09] cabo joins the room
[10:05:21] cabo leaves the room
[10:26:43] cabo joins the room
[10:26:52] cabo leaves the room
[10:39:26] cabo joins the room
[10:51:26] cabo leaves the room
[12:07:08] cabo leaves the room
[12:34:48] cabo joins the room
[12:52:17] <zulipbot> (Éric Vyncke) we hear
[12:52:19] cabo leaves the room
[13:05:18] <zulipbot> (Andrew Campling) AD to send chairs on remedial Meetecho training? ;-)
[13:05:31] <zulipbot> (Éric Vyncke) Good idea !
[13:05:44] <zulipbot> (Éric Vyncke) ;-)
[13:08:50] <zulipbot> (Peter van Dijk) PowerDNS, as mentioned in our blog post about the implementation, also is more to the spirit than to the letter of the draft
[13:10:38] <zulipbot> (Tim Wicinski) thanks Peter
[13:11:26] <zulipbot> (Peter van Dijk) ( https://blog.powerdns.com/2022/06/13/probing-dot-support-of-authoritative-servers-just-try-it/ )
[13:32:37] <zulipbot> (Tommy Pauly) Why is doh-sydney a DoT server? =)
[13:32:50] <zulipbot> (Éric Vyncke) I was wondering the same ;-)
[13:33:03] <zulipbot> (Chris Box) I'm more wondering why the server feels so sure about the geolocation of the client
[13:33:16] <zulipbot> (David Lawrence) :)
[13:35:50] <zulipbot> (Ray Bellis) .arpa is signed - doesn't this need an unsigned delegation to a name one level below resolver.arpa?
[13:37:05] <zulipbot> (Hazel Smith) Ben Schwartz - your audio is better now, but was *very* loud at first, and is still occasionally clipping a little
[13:37:31] <zulipbot> (Vicky Risk) Maybe it was intentional that the DOT server in Sydney is redirected to a DOH server in Paris????
[13:37:57] <zulipbot> (Vicky Risk) oh forget it, looks like a typo
[13:38:28] <zulipbot> (Jim Reid) Or a test to see who's paying attention. :-)
[13:41:12] <zulipbot> (Vicky Risk) presumably it is clear in the actual draft
[13:42:51] <zulipbot> (Benjamin Schwartz) Unstable meetecho connection :(
[13:43:56] <zulipbot> (Ray Bellis) w.r.t. .arpa, I'd also like to remind people of draft-jabley-sink-arpa and draft-bellis-dns-recursive-discovery, both from 2009.    I'd rather see an unsigned delegation to a subdomain of .arpa (with a registry of the entries therein) than a proliferation of "special" entries directly inside .arpa
[13:44:23] <zulipbot> (David Lawrence) Load shedding was the other example given. That's a server decision
[13:48:55] <zulipbot> (Ted Hardie) @David  agree with load shedding as a different reason, but a message from the server to re-seek accomplishes the same thing if there an alternate, without the same control surface.  Think Go_Away or enhance your calm.
[13:49:13] <zulipbot> (Benjamin Schwartz) +1 to Tommy Pauly
[13:49:53] <zulipbot> (Benjamin Schwartz) The difference is that it doesn't change the TLS SNI
[13:50:39] <zulipbot> (David Lawrence) What would trigger a new lookup?
[13:51:21] <zulipbot> (David Lawrence) Oh I see, nm
[13:51:34] <zulipbot> (Ray Bellis) ok, I see the draft does actually specify _dns.resolver.arpa, per the DDR spec.
[13:52:25] <zulipbot> (Vicky Risk) I think John is addressing what I was wondering about - whether the filtering policy of the new server might be different
[13:52:38] <zulipbot> (Andrew Campling) Good point from Vittorio about needing to consider whether the query is being moved outside of the client's jurisdiction
[13:53:36] <zulipbot> (Ted Hardie) I'll also point out that if you just message to the client to re-run their config process, that they are not going to have any risk of looping.
[13:54:11] <zulipbot> (Jim Reid) Redirection would be for the resolving server. Which might well be in a very different location from the originating stub resolver.
[13:56:41] <zulipbot> (Erik Nygren) Different SVCB-based drafts handling SNI and TLS certs/validation differently is going to be an interesting challenge to keep an eye on, especially in libraries for SVCB.
[13:56:41] <zulipbot> (Peter Lowe) Are there going to be different types of redirects? Like with HTTP redirects, where there's 301 and 302? Are permanent redirects going to be used for decommissioned servers, that sort of thing?
[13:57:51] <zulipbot> (Erik Nygren) (Although I think we have that, being different SNI/cert usage, already for some other SVBC cases.)
[13:59:01] <zulipbot> (Chris Box) Agree with Ben we should document bootstrap
[13:59:14] <zulipbot> (Tommy Pauly) + 1 to Ben on insecure
[13:59:27] <zulipbot> (Tommy Pauly) Also +1 that we should talk about bootstrap
[13:59:40] <zulipbot> (Chris Box) In a secure way, of course
[14:00:06] <zulipbot> (David Lawrence) That message is encrypted tho, right?
[14:02:39] <zulipbot> (Daniel Migault) This is my impression and I also have the impression doh-sydney is trusted.
[14:03:51] <zulipbot> (Benjamin Schwartz) @Tommy Jensen: The difference is that in DDR Section 5, the attacker can't change the validation name, so TLS still defeats the attack.
[14:06:19] <zulipbot> (Daniel Migault) @ben Th edifference I see is that with DDR we do have an untrusted DNS exchange, but in Toiommy's case the server is trusted as per DDR's procedure. Am I missing anything ?
[14:06:32] <zulipbot> (David Schinazi) Can someone post the draft name for this presentation please?
[14:06:45] <zulipbot> (Benjamin Schwartz) It's at the bottom of the slide...
[14:06:58] <zulipbot> (David Schinazi) That's not visible in the room
[14:07:11] <zulipbot> (Anthony Somerset) draft-wing-opsawg-authenticating-network-01
[14:07:24] <zulipbot> (David Schinazi) Thank you!
[14:07:39] <zulipbot> (Tommy Jensen) That's fair, Ben. So then this really turns into "enabling multi-name redirection" versus "must stay on same name for security" trade-off. Would love more server operators to weigh in on that as they're the ones who have to deploy the many-to-many name claims for that to work.
[14:09:01] <zulipbot> (Benjamin Schwartz) Tommy: There are a lot of "names" involved here though.  You can use lots of DNS names to hold various RRsets, but changing the authentication name used for TLS is a different story.
[14:09:14] <zulipbot> (Tommy Jensen) David, yes this only ever starts from an existing encrypted DNS connection, so a transient attack is far less common than in the plain-text bootstrap case DDR tackles. I think Erik pointed out (or someone else) that this makes it comparable to HTTPS redirects and could learn from them
[14:10:29] <zulipbot> (Daniel Migault) agree with the similarity of HTTPS redirect.
[14:11:11] <zulipbot> (Ted Hardie) unless my memory fails me that actual ssid is 2-32 characters long, so you'd have to link the SSID to the local network name to try to match it to the SAN.
[14:11:26] <zulipbot> (Tommy Jensen) Ben, I think there's a different of POV here. The auth name used for TLS isn't changing for the destination server. Remember: this isn't intended to be a black-box-identical replacement for a server, it's a disclosed redirection _to another server_ much like HTTPS redirection. Checking for anything other than the name of the destination seems weird to me.
[14:11:27] <zulipbot> (Ted Hardie) (Slide 7)
[14:13:23] <zulipbot> (Benjamin Schwartz) Tommy: A disclosed redirect is definitely a different story ... but I'm not excited about writing the UI to notify the user whether about a suggested change to the DNS server.  (Change the what?)
[14:14:48] <zulipbot> (Tommy Jensen) I'm not either, but I think if we don't allow that we rule out any case for redirection from one server to another hosted on different infra. Again, that's where we need operators to say whether that's a real challenge or not (my understanding is that it is).
[14:16:28] <zulipbot> (David Schinazi) I disagree that experimental RFCs cost nothing, as our esteemed and honored IESG members only have so much time to review our illustrious documents :-)
[14:16:41] <zulipbot> (Éric Vyncke) +1
[14:16:56] <zulipbot> (Tommy Jensen) +1 to David, gaining a lot of appreciation for that trying to publish DDR/DNR
[14:17:10] <zulipbot> (Tommy Jensen) that = IESG support
[14:17:23] <zulipbot> (David Schinazi) Yeah I learned it the hard way, repeatedly :-)
[14:17:49] <zulipbot> (Andrew Campling) @David It does avoid boredom, keep them out of mischief :-)
[14:18:05] <zulipbot> (Éric Vyncke) thanks to the chairs and everyone for participating !
[14:18:19] <zulipbot> (Éric Vyncke) @andrew -1 ;-)
[14:19:01] <zulipbot> (Hazel Smith) Do remote attendees need to do anything special to have our attendance counted?
[14:19:14] <zulipbot> (Hazel Smith) or is being in this Meetecho call enough?
[14:19:27] <zulipbot> (Chris Box) It's enough. You're counted.
[14:19:27] <zulipbot> (Hazel Smith) Super, thanks! :)
[14:19:40] <zulipbot> (Jim Reid) No Hazel. Being in meetecho is all you have to do.
[14:19:53] <zulipbot> (Hazel Smith) Great, thanks, I just wasn't sure if I'd missed something
[14:33:14] cabo leaves the room
[15:01:11] cabo joins the room
[16:08:52] cabo leaves the room
[16:32:02] cabo joins the room
[16:42:44] cabo joins the room
[16:42:53] cabo leaves the room
[16:59:13] cabo joins the room
[16:59:55] cabo leaves the room
[17:00:04] cabo joins the room
[17:12:26] cabo leaves the room
[17:43:57] cabo leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!