- Wednesday, January 27, 2021

dprive@jabber.ietf.org

Wednesday, January 27, 2021< ^ >

Brian Haberman has set the subject to: DPRIVE - IETF 108

Room Configuration

Room Occupants

GMT+0
[01:07:10] zyxbac joins the room
[01:07:10] halfshot joins the room
[16:20:03] ChrisBox joins the room
[16:21:36] ChrisBox leaves the room
[16:28:53] ChrisBox joins the room
[16:34:20] ChrisBox leaves the room
[16:37:31] ChrisBox joins the room
[16:37:57] ChrisBox leaves the room
[16:38:37] ChrisBox joins the room
[16:39:38] ChrisBox leaves the room
[16:48:51] ChrisBox joins the room
[16:54:16] ChrisBox leaves the room
[17:17:40] ChrisBox joins the room
[17:28:17] vladimir.cunat joins the room
[17:29:29] andrew_campling joins the room
[17:30:44] Yoshiro Yoneya joins the room
[17:30:44] ChrisBox leaves the room
[17:57:51] Eric Vyncke joins the room
[17:58:52] Ben Schwartz joins the room
[17:58:53] sftcd joins the room
[18:03:07] mcr joins the room
[18:03:20] <mcr> hi.
[18:03:25] <mcr> death by secure DNS.
[18:03:46] <andrew_campling> https://codimd.ietf.org/notes-ietf-interim-2021-dprive-01-dprive?edit
[18:04:01] Vittorio Bertola joins the room
[18:04:10] <mcr> Thank you Andrew.
[18:04:17] <mcr> Would be great if that link was in the agenda.
[18:06:57] <Eric Vyncke> @mcr: it is also https://datatracker.ietf.org/meeting/upcoming ;-)
[18:13:56] <mcr> "move of a lover than a friend"....
[18:17:10] <vladimir.cunat> I thought the problem with authentication wasn't in (not) considering it useful but in (agreeing on) how exactly to do it.
[18:18:03] <sftcd> better to discourage self-signed from the start even if not verifying - for easier upgrade path later
[18:18:23] <sftcd> if self-signed's get deployed many will have expiry in 2038 and will be hard to replace
[18:19:39] <vladimir.cunat> The draft already has text around this.
[18:19:57] <vladimir.cunat> > authoritative servers SHOULD use TLS certificates that can be used in authenticated TLS authentication
[18:20:08] <sftcd> good stuff
[18:20:50] <vladimir.cunat> Though maybe it's a little weird without saying how the authentication might be done.  (say, what root of trust, etc.)
[18:32:18] <Ben Schwartz> I disagree ... I think we should encourage the use of self-signed certificates to avoid ambiguity
[18:33:05] <Ben Schwartz> Authenticated encryption will have to be an "explicit opt-in" from the server side within the DNS content layer, so there's no risk of confusion.
[18:39:44] <sftcd> @ben: encouraging self-signed will likely make the transition to authenticated take longer I'd say and even if you only enourage self-signed, it's not a good signal for what you want
[18:40:24] <Ben Schwartz> Personally I expect an authentication mechanism involving DANE, which can authenticate self-signed certificates.
[18:40:45] <vladimir.cunat> +1
[18:42:25] <sftcd> @ben: that confuses me  as use of DANE with self-signed would mean self-signed is even less of a signal for oppo (I also like DANE+self-signed or raw public keys)
[18:44:33] <vladimir.cunat> The ability to do opportunistic approach doesn't seem to clash with the ability to do authenticated.
[18:44:53] <Ben Schwartz> The most obvious alternative to self-signed is that ns.foo.example has a certificate that says "ns.foo.example" and chains up to the WebPKI.  That might be compatible with whatever authentication mechanism we eventually settle on, but it's actually not sufficient for "authenticated ADoT".  I think it's more of a confusing middle ground.
[18:45:16] <sftcd> I agree its insufficient, I don't agree it's confusing
[19:05:33] <sftcd> +1 for adoption btw, either now or after a rev (I'm assuming it'll evolve a lot based on experience)
[19:08:35] <mcr> remember: Paul is ALWAYS watching :-)
[19:09:00] <mcr> Paul's point is very good though.
[19:11:28] Ben Schwartz leaves the room
[19:11:59] sftcd leaves the room
[19:13:19] Yoshiro Yoneya leaves the room
[19:24:35] vladimir.cunat leaves the room
[19:26:23] Eric Vyncke leaves the room

Powered by ejabberd - robust, scalable and extensible XMPP server