\"redesignation\"
", "time": "2024-03-21T05:45:36Z"}, {"author": "Benjamin Schwartz", "text": "\"Extending DDR for Selecting Resolvers\"
", "time": "2024-03-21T05:50:34Z"}, {"author": "Benjamin Schwartz", "text": "A fun wrinkle: if a resolver has N IPs in its certificate, it has no way to know which one a client might be relying on, so it can only \"redirect\" to another server whose certificate covers _all_ of them.
", "time": "2024-03-21T05:58:24Z"}, {"author": "\u00c9ric Vyncke", "text": "A formal call for adoption MUST indeed be done.
", "time": "2024-03-21T05:59:36Z"}, {"author": "Kazunori Fujiwara", "text": "Does the CPE decrypt \"encrypted DNS\" message from clients ?
", "time": "2024-03-21T06:03:27Z"}, {"author": "David Lawrence", "text": "Name constraints is RFC 5280 btw. And yes, CA Browser Forum not form
", "time": "2024-03-21T06:06:09Z"}, {"author": "Chris Box", "text": "Yes, that is the idea, so that the CPE can provide answers from local names, can cache, provide malware control, MUD enforcement, etc.
", "time": "2024-03-21T06:06:11Z"}, {"author": "Shumon Huque", "text": "Shoud that slide have said RFC 5280 (Name Constraints) and not RFC 8280 - the latter is about human rights and protocols.
", "time": "2024-03-21T06:06:21Z"}, {"author": "Chris Box", "text": "(I was answering Kazunori above)
", "time": "2024-03-21T06:06:29Z"}, {"author": "Shumon Huque", "text": "Oh, sorry, I just saw Tale's note :)
", "time": "2024-03-21T06:06:32Z"}, {"author": "Benjamin Schwartz", "text": "mic: It seems that a large part of the motivation for this work was the lack of client support for Opportunistic DDR. If anyone has insights into why that is not as widely implemented or was not reliable in practice, I would like to hear about that.
", "time": "2024-03-21T06:07:13Z"}, {"author": "Tommy Jensen", "text": "Would you, though?
", "time": "2024-03-21T06:09:41Z"}, {"author": "Benjamin Schwartz", "text": "I'm looking at you Tommy
", "time": "2024-03-21T06:09:56Z"}, {"author": "Tommy Jensen", "text": "(that was a fun topic back in the day)
", "time": "2024-03-21T06:09:56Z"}, {"author": "Tommy Jensen", "text": "I'll look at your handle in return since you're not here :(
", "time": "2024-03-21T06:10:26Z"}, {"author": "Benjamin Schwartz", "text": "*Tommys
", "time": "2024-03-21T06:10:33Z"}, {"author": "Mike Bishop", "text": "Was not expecting to walk into a homenet meeting....
", "time": "2024-03-21T06:11:14Z"}, {"author": "Jim Reid", "text": "+1 Mike
", "time": "2024-03-21T06:12:05Z"}, {"author": "Benjamin Schwartz", "text": "Right now, AFAIK the most common DDR implementations are Windows and iOS/macOS. Do they do opportunistic? Do they do it in a way that somehow failed interop in Tiru's use case?
", "time": "2024-03-21T06:13:27Z"}, {"author": "\u00c9ric Vyncke", "text": "NO NO no more homenet
", "time": "2024-03-21T06:13:30Z"}, {"author": "Mike Bishop", "text": "I think that's where we are. Securely connecting to local devices seems outside the scope of ADD, at the least.
", "time": "2024-03-21T06:15:22Z"}, {"author": "Benjamin Schwartz", "text": "@Tommy: Wait, you require it to have a valid certificate even though you have no name anchor to validate against?
", "time": "2024-03-21T06:15:48Z"}, {"author": "\u00c9ric Vyncke", "text": "@Mike: my feeling as well. EXCEPT if there is a specific problem for ADD
", "time": "2024-03-21T06:15:51Z"}, {"author": "Mohamed Boucadair", "text": "An approach would be to document the problem + list potential solutions without making any reco
", "time": "2024-03-21T06:15:53Z"}, {"author": "Tommy Jensen", "text": "\n", "time": "2024-03-21T06:16:06Z"}, {"author": "Tommy Jensen", "text": "@Tommy: Wait, you require it to have a valid certificate even though you have no name anchor to validate against?
\n
^+1 what does that mean, other Tommy?
", "time": "2024-03-21T06:16:15Z"}, {"author": "\u00c9ric Vyncke", "text": "@Med could be an approach indeed for a next step.
", "time": "2024-03-21T06:16:16Z"}, {"author": "Benjamin Schwartz", "text": "Other Tommy
", "time": "2024-03-21T06:16:22Z"}, {"author": "Tommy Jensen", "text": "He's the one saying there's some other check to do. From my side, opportunistic means \"whatever the cert is it's fine\" which we don't support yet AFAIK.
", "time": "2024-03-21T06:17:22Z"}, {"author": "Tommy Pauly", "text": "We validate that it is a trusted non-expired cert
", "time": "2024-03-21T06:17:25Z"}, {"author": "Tommy Pauly", "text": "We just don't care about the name
", "time": "2024-03-21T06:17:30Z"}, {"author": "Tommy Jensen", "text": "Trusted as in signed by something in your root store?
", "time": "2024-03-21T06:17:42Z"}, {"author": "Tommy Pauly", "text": "Yes
", "time": "2024-03-21T06:17:45Z"}, {"author": "Benjamin Schwartz", "text": "Why?
", "time": "2024-03-21T06:17:52Z"}, {"author": "David Lawrence", "text": "DANE enters the chat
", "time": "2024-03-21T06:17:55Z"}, {"author": "Tommy Jensen", "text": "I mean... kinda makes it less than opportunistic
", "time": "2024-03-21T06:18:01Z"}, {"author": "Benjamin Schwartz", "text": "This doesn't accomplish any security goal that I can see.
", "time": "2024-03-21T06:18:12Z"}, {"author": "Tommy Pauly", "text": "\"however, even if clients choose to perform some certificate validation checks, they will not be able to validate the names presented in the SubjectAltName (SAN) field of the certificate for private and local IP addresses.\"
\nFrom DDR. That's the \"some certificate validation checks\"
", "time": "2024-03-21T06:18:58Z"}, {"author": "Benjamin Schwartz", "text": "Yes, it's permitted, but it's not a good idea.
", "time": "2024-03-21T06:19:21Z"}, {"author": "Tommy Jensen", "text": "I mean, yes, you can choose to, I'm just surprised that you did.
", "time": "2024-03-21T06:19:24Z"}, {"author": "Tommy Pauly", "text": "We only do it if the resolved address is a private use address
", "time": "2024-03-21T06:19:40Z"}, {"author": "Jim Reid", "text": "Med, \"document the problem + list potential solutions\" seems like a cop-out. Explaining why the potential solutions are unlilkely to work would be a better outcome IMO. So would saying \"this problem is intractable. we give up\".
", "time": "2024-03-21T06:19:50Z"}, {"author": "Tommy Pauly", "text": "But I don't see why would arbitrarily allow expired certs, etc.
", "time": "2024-03-21T06:19:58Z"}, {"author": "Tommy Jensen", "text": "I would need to think through some edge cases, but I clearly remember agreeing to this text thinking \"well, if we're on an L3 attack, the verification would fail anyway so whatever\"
", "time": "2024-03-21T06:19:59Z"}, {"author": "Benjamin Schwartz", "text": "If it's a private use address, this check reduces interop (as in this case) without enhancing security in any discernible way.
", "time": "2024-03-21T06:20:22Z"}, {"author": "Tommy Jensen", "text": "Tommy, what about \"I run a pihole with a self signed cert\"?
", "time": "2024-03-21T06:20:33Z"}, {"author": "Tommy Pauly", "text": "If you want to install a root CA to trust your pihole, great
", "time": "2024-03-21T06:20:53Z"}, {"author": "Mohamed Boucadair", "text": "That's might be an outcome indeed, @Jim but we definitely document this
", "time": "2024-03-21T06:20:55Z"}, {"author": "Benjamin Schwartz", "text": "An attacker can acquire a valid certificate so this only breaks this use case without defeating any attacks.
", "time": "2024-03-21T06:21:31Z"}, {"author": "Jim Reid", "text": "I agree 100% on documenting something Med.
", "time": "2024-03-21T06:21:55Z"}, {"author": "Tommy Pauly", "text": "And yet we're arguing it is too hard for CPEs to get this?
", "time": "2024-03-21T06:22:07Z"}, {"author": "Tommy Jensen", "text": "I get not allowing opportunistic (our current position), but requiring parenting makes it seem like we're gatekeeping opportunistic to people who are savvy/capable of getting a CA cert which, without name checks, doesn't mean anything (granted cert for jdfwoiwreo8uwo8.evil.example)
", "time": "2024-03-21T06:22:35Z"}, {"author": "Tommy Pauly", "text": "Yes, the attacker only needs to acquire a valid cert and also be running on the same IP as the original resolver.
", "time": "2024-03-21T06:22:40Z"}, {"author": "Tommy Jensen", "text": "Once it was running on the original resolver, it may as well drop DDR queries and force us into 53 fallback
", "time": "2024-03-21T06:23:05Z"}, {"author": "Benjamin Schwartz", "text": "CPEs could make themselves iOS compatible by acquiring a single cert and replicating the private key across all their devices ... until it leaks and gets revoked, killing the whole fleet.
", "time": "2024-03-21T06:23:44Z"}, {"author": "Tommy Pauly", "text": "Correct, they could do that
", "time": "2024-03-21T06:24:38Z"}, {"author": "Tommy Pauly", "text": "And work with all iOS/macOS
", "time": "2024-03-21T06:24:44Z"}, {"author": "Benjamin Schwartz", "text": "(CAs usually will not let you have an unrevoked certificate with a publicly known private key.)
", "time": "2024-03-21T06:24:46Z"}, {"author": "Tommy Pauly", "text": "Indeed
", "time": "2024-03-21T06:24:58Z"}, {"author": "Benjamin Schwartz", "text": "This strikes me as fairly absurd.
", "time": "2024-03-21T06:25:07Z"}, {"author": "Tommy Jensen", "text": "ok sorry, I rat holed a lot on Apple's implementation choice (which is RFC sanctioned) -- speaking for myself, we don't intend to support the MAY for opportunistic at scale by default at this time.
", "time": "2024-03-21T06:25:10Z"}, {"author": "Tommy Jensen", "text": "Where's Lorenzo when we need him
", "time": "2024-03-21T06:25:37Z"}, {"author": "David Lawrence", "text": "What strikes you as absured, Ben?
", "time": "2024-03-21T06:25:43Z"}, {"author": "Mike Bishop", "text": "I'm reminded by the Plex model. Each server has a unique ID, and gets a cert issued from their server for .<ID>.plex.direct. Then their DNS server will resolve <IP>..plex.direct to the IP embedded in the hostname. So you wind up with a valid TLS cert for the hostname <IP>.<ID>.plex.direct that can be used for HTTPS.
", "time": "2024-03-21T06:26:11Z"}, {"author": "David Lawrence", "text": "Lorenzo was in the room earlier. Hmm
", "time": "2024-03-21T06:26:11Z"}, {"author": "\u00c9ric Vyncke", "text": "Again repeating what I said this morning: my Fritz!Box CPE has its own LE cert renewed every 3 months or so.
", "time": "2024-03-21T06:26:22Z"}, {"author": "Mike Bishop", "text": "Bah, Meetecho ate the \\*s.
", "time": "2024-03-21T06:26:31Z"}, {"author": "Benjamin Schwartz", "text": "@Tommy Jensen: I'd love to know why on that front too. I think it's unfortunate but it's not as bewildering.
", "time": "2024-03-21T06:26:32Z"}, {"author": "Tommy Jensen", "text": "(1) it's a MAY, (2) DNR is a better option, (3) I'm worried DNR adoption will be chilled if opportunistic DDR is a crutch to lean on
", "time": "2024-03-21T06:27:32Z"}, {"author": "Mike Bishop", "text": "And the Plex certs are issued by LE, presumably on the basis of DNS control.
", "time": "2024-03-21T06:27:34Z"}, {"author": "Tommy Jensen", "text": "(yes, I know DNR leads up back here, but still, better than no verification)
", "time": "2024-03-21T06:29:13Z"}, {"author": "Chris Box", "text": "DNR clearly a better solution for home networks than opportunistic DDR. As long as you have the certs.
", "time": "2024-03-21T06:29:37Z"}, {"author": "Eric Rescorla", "text": "One thing that does confuse me is whether you need the CPE to be internet accessible
", "time": "2024-03-21T06:29:37Z"}, {"author": "Tommy Jensen", "text": "So ^ note that I support this work, but I don't have a qualified opinion about how it can be done (bit far from my expertise)
", "time": "2024-03-21T06:29:38Z"}, {"author": "Benjamin Schwartz", "text": "@David: iOS doesn't support opportunistic security in the standard way TLS does this (self-signed certs). Instead, it does this in a way that effectively encourages bad/odd behavior but doesn't improve security.
", "time": "2024-03-21T06:30:20Z"}, {"author": "Tommy Jensen", "text": "\n\nAs long as you have the certs.
\n
Exactly, not saying that's trivial, clearly. But I'd rather work on this than say \"eh, use opportunistic DDR\"
", "time": "2024-03-21T06:30:23Z"}, {"author": "Eric Rescorla", "text": "Like you could presumably demonstrate control of the domain name prior to shipping the CPE and then provision it with the ACME account key and then send it out.
", "time": "2024-03-21T06:30:54Z"}, {"author": "Tommy Jensen", "text": "ekr, I like that. I think Tiru's point (that the room doesn't seem to buy) is that this scales expensively?
", "time": "2024-03-21T06:36:06Z"}, {"author": "Eric Rescorla", "text": "I don't know if e.g., LE re-validates
", "time": "2024-03-21T06:36:26Z"}, {"author": "Andrew Campling", "text": "Security theatre? :-)
", "time": "2024-03-21T06:38:24Z"}, {"author": "Eric Rescorla", "text": "If I understand the design Bishop is proposing, it's a way to allow the manufacturer and the device to jointly establish control of the namespace
", "time": "2024-03-21T06:43:30Z"}, {"author": "Tommy Jensen", "text": "yes, basically
", "time": "2024-03-21T06:43:56Z"}, {"author": "David Lawrence", "text": "Thank you, Meetecho. We're done.
", "time": "2024-03-21T06:43:58Z"}]