it's up goer 5 in the background! https://xkcd.com/1133/
", "time": "2024-03-21T05:39:04Z"}, {"author": "Mike Ounsworth", "text": "By the way, Randall has a whole book like that. If you have a semi-nerdy 5 - 10 year old in your life, it's a great gift!
\nhttps://xkcd.com/thing-explainer/
that is one of my favorite books, and i'm more than 5-10 years old
", "time": "2024-03-21T05:46:20Z"}, {"author": "Tim Hollebeek", "text": "This is extraordinarily wonky, but 3647 is informational ... if the definition of 'renewal' is used in a requirement in a normative way, that may or may not be a problem. I'm not sure.
", "time": "2024-03-21T05:46:37Z"}, {"author": "Daniel Gillmor", "text": "downrefs aren't showstoppers. if it's reasonable to have the downref normatively referenced, that's still ok
", "time": "2024-03-21T05:47:22Z"}, {"author": "Daniel Gillmor", "text": "as an example, RFC 8032 is informational, but it is normatively referenced in non-informational drafts that use EdDSA.
", "time": "2024-03-21T05:48:12Z"}, {"author": "Deb Cooley", "text": "I'm going to bet that RFC 5280 will be the normative one
", "time": "2024-03-21T05:49:32Z"}, {"author": "Deb Cooley", "text": "(for AKID)
", "time": "2024-03-21T05:49:56Z"}, {"author": "Mike Ounsworth", "text": "That sounds like an Informational reference to me (based on Aron's comments at mic)
", "time": "2024-03-21T05:51:58Z"}, {"author": "Mike Ounsworth", "text": "Here is the on-list discussion comparing Brandon's ACME attest draft and draft-ietf-lamps-csr-attestation:
\nhttps://mailarchive.ietf.org/arch/msg/acme/5v422PrkjO340FyOaqiIyEcihdo/
(For what it is worth, Q Misell's pronouns are it/she, not he)
", "time": "2024-03-21T06:07:04Z"}, {"author": "Deb Cooley", "text": "apologies. I've used they in the past. not an excuse, but it is late/early.
", "time": "2024-03-21T06:07:47Z"}, {"author": "Brandon Weeks", "text": "@Mike Ounsworth I wonder if it makes sense to add a section that puts the draft in the context of 'existed before RATS'?
", "time": "2024-03-21T06:11:37Z"}, {"author": "Mike Ounsworth", "text": "Brandon Weeks said:
\n\n\nMike Ounsworth I wonder if it makes sense to add a section that puts the draft in the context of 'existed before RATS'?
\n
Makes sense to me. I would be happy to work with you offline on some text.
", "time": "2024-03-21T06:12:16Z"}, {"author": "Mike Ounsworth", "text": "draft-sweet-iot-acme seems to be proposing to run a self-signed CA within the local home / enterprise network for issuing .local certs, and somehow the browsers will trust that CA?
\nDoesn't that have all the same problems as to why browsers don't want publicly-trusted .local certs in the first place?
how does the client decide when to not trust that CA in the future?
", "time": "2024-03-21T06:15:23Z"}, {"author": "Mike Ounsworth", "text": ".local is subnet-specific. So you would want to trust a .local CA per subnet or per wifi.
\n(it sounds like, from speaker comments, that the draft discusses distrust-on-network-disconnect)
I'd recommend against asking the user, that solution has never worked
", "time": "2024-03-21T06:17:29Z"}, {"author": "Daniel Gillmor", "text": "automated, dynamic updates of the root store gives me the heebie-jeebies
", "time": "2024-03-21T06:18:09Z"}, {"author": "Tadahiko Ito", "text": "do we really need .local? are't there any alternative ? use of site-specific domain sound better for me.
", "time": "2024-03-21T06:19:48Z"}, {"author": "Tim Hollebeek", "text": "+1
", "time": "2024-03-21T06:19:55Z"}, {"author": "Yoav Nir", "text": "Daniel Gillmor said:
\n\n\nautomated, dynamic updates of the root store gives me the heebie-jeebies
\n
Yeah, like the new printer joining the neighbor's network instead of my home network. Or an attacker's device allowed to join, because everyone can join, because we need that for printers.
", "time": "2024-03-21T06:20:15Z"}, {"author": "Tim Hollebeek", "text": "on automated, dynamic root store updates ... most browsers do it these days. It's poorly managed dynamic updates that scare me ...
", "time": "2024-03-21T06:20:25Z"}, {"author": "Daniel Gillmor", "text": "@tim, that's fair, i just presume most major browsers have some pretty serious guardrails there.
", "time": "2024-03-21T06:21:44Z"}, {"author": "Mike Ounsworth", "text": "For example, you could connect to your local printer UI at
\nprinter1a2b3c4d.printermanufacturer.com\nwhere that is a DNS allias (inside the network) for 192.168.1.101, but on the public internet, the printer manufacturer could do ACME responses for that, and so get a public-trusted cert. I know that @Tirumaleswar Reddy.K is working on something very very similar.
", "time": "2024-03-21T06:22:05Z"}, {"author": "Andrew Fregly", "text": "Have you looked at the work the DANCE WG produced.
", "time": "2024-03-21T06:22:52Z"}, {"author": "Mike Ounsworth", "text": "Tim Hollebeek said:
\n\n\non automated, dynamic root store updates ... most browsers do it these days. It's poorly managed dynamic updates that scare me ...
\n
There's a difference between \"Google pushed new roots\" and \"Ask the local router for a set of roots\".
", "time": "2024-03-21T06:23:16Z"}, {"author": "Tim Hollebeek", "text": "well, except the local router being authoritative for .local, might actually make sense. I'm not sure.
", "time": "2024-03-21T06:23:52Z"}, {"author": "Tim Hollebeek", "text": "If it is authoritative, then having it manage a list of trust roots ... makes sense?
", "time": "2024-03-21T06:24:25Z"}, {"author": "Tim Hollebeek", "text": "but is .local really intended to be managed in that way? I'm not sure.
", "time": "2024-03-21T06:24:39Z"}, {"author": "Mike Ounsworth", "text": "I don't disagree with Tim, but having the browser dynamically add new subnet-specific roots is :octopus:
", "time": "2024-03-21T06:26:12Z"}, {"author": "Tim Hollebeek", "text": "yep, not arguing that. The can of worms is fully open.
", "time": "2024-03-21T06:26:31Z"}, {"author": "Daniel Gillmor", "text": "+1 to Aaron -- this draft proposes to touch a lot of things (browsers, root stores, network managers, etc), but it's not touching ACME itself all that much
", "time": "2024-03-21T06:26:41Z"}, {"author": "David Benjamin", "text": "The subnet-specific parts is particularly goofy because the point of certificates in the web is not just to show a little icon in the corner. It's the thing that authenticates origins, the security principal used across the web. E.g. JS state is partitioned by that, etc. I don't think something like this could work without, at minimum, extending how origins work, which is a very big web-platform-level change.
", "time": "2024-03-21T06:28:24Z"}, {"author": "Mike Ounsworth", "text": "This draft is dealing with the same problem as Tiru's presentation from earlier this week:
\nhttps://datatracker.ietf.org/meeting/119/materials/slides-119-add-why-host-encrypted-dns-forwarders-on-managed-cpes-00
E.g. imagine if I do stuff with printer.local on network A. Then I visit my friend and visit printer.local on network B. That is a different printer.local and cannot have the same bucket of state.
", "time": "2024-03-21T06:29:16Z"}, {"author": "Tim Hollebeek", "text": "yeah, Dave's comment is the same. We need to figure out what to authenticate and how, instead of figuring out how to avoid authenticating.
", "time": "2024-03-21T06:29:45Z"}, {"author": "Daniel Gillmor", "text": "@David, you don't want to send the second half of your print job to the new printer? :P
", "time": "2024-03-21T06:30:09Z"}, {"author": "Mike Ounsworth", "text": "David Benjamin said:
\n\n\nThe subnet-specific parts is particularly goofy because the point of certificates in the web is not just to show a little icon in the corner. It's the thing that authenticates origins, the security principal used across the web. E.g. JS state is partitioned by that, etc. I don't think something like this could work without, at minimum, extending how origins work, which is a very big web-platform-level change.
\n
I guess the core question here is: would you trust your local gateway / DHCP server to act as a CA for .local ?
\nIt gives me the :octopus: , but as Tim says, it might not be wrong.
And the answer to that is no, because there is only one .local right now. Unless you can extend the notion of origin so that the different local gateways are different .locals.
@Mike, David is saying it is wrong, unless you expect that state to be shared across same-named devices on other networks, at layers like the browser's local storage
", "time": "2024-03-21T06:32:11Z"}, {"author": "A.J. Stein", "text": "Daniel Gillmor said:
\n\n\n@David, you don't want to send the second half of your print job to the new printer? :P
\n
You joke and I am not saying it was a feature, but in a former life I administered print queue software for private universities with payment cards and for the college student doing the ill-advised (and often unaurhorized) printing of a whole medical textbook (more than once), that would have been a desirable feature.
\nThis software was awful and I won't impune it's good name, but you may be onto something, dkg.
\n/endtangent
", "time": "2024-03-21T06:32:42Z"}, {"author": "Tim Hollebeek", "text": "yeah, if the security context of .local changes when your network swaps, that breaks a whole host of security assumptions
", "time": "2024-03-21T06:32:50Z"}, {"author": "Mike Ounsworth", "text": "I see.
\nNow an origin needs to be defined as the tuple (scheme, host, port, subnet).
imagine refreshing your browser or a background webservice retry that sends the same request in a different security context because .local changed in the background
", "time": "2024-03-21T06:33:52Z"}, {"author": "David Benjamin", "text": "Oh whoops yeah, I should have probably added myself to the queue. Thanks, Aaron! :-D
", "time": "2024-03-21T06:36:25Z"}, {"author": "Tadahiko Ito", "text": "If .local was used for other purpose, and if this .local ca were compromise, then, that other service would influence by that attack? I believe it is not good.
", "time": "2024-03-21T06:36:55Z"}, {"author": "Aaron Gable", "text": "Thanks for pointing it out, @davidben! Sometimes I miss working on a browser, sometimes I don't :D
", "time": "2024-03-21T06:37:28Z"}, {"author": "Mike Ounsworth", "text": "Sorry for the queue-jump.
\nI think there is a very real problem here that local devices with UIs don't play well with browser cert errors. So while I don't think this draft is the answer, I do think there is a very real problem that the IETF should work on.
in addition to DANCE, there was also HOMENET which I only payed a teeny bit of attention to, but IIRC was the same problem
", "time": "2024-03-21T06:39:16Z"}, {"author": "Deb Cooley", "text": "@Mike what working group was Tiru working on
", "time": "2024-03-21T06:40:20Z"}, {"author": "Daniel Gillmor", "text": "if we're just going to say \".local has different security properties\" and convince everyone who consumes domain names to treat them differently, then it seems like there might be some simpler paths to get there. but it's still a huge lift
", "time": "2024-03-21T06:40:36Z"}, {"author": "Daniel Gillmor", "text": "@Deb i think Tiru was presenting in ADD
", "time": "2024-03-21T06:41:10Z"}, {"author": "Deb Cooley", "text": "TY
", "time": "2024-03-21T06:41:20Z"}, {"author": "Daniel Gillmor", "text": "", "time": "2024-03-21T06:42:06Z"}, {"author": "Aaron Gable", "text": "My gut feeling is that a) the second draft is talking about a problem that needs to be solved, but also b) I believe it can be solved entirely with mechanisms that already exist within ACME and may not need a full document (or maybe just an informational document describing how best to use those existing mechanisms)
", "time": "2024-03-21T06:59:10Z"}, {"author": "David Benjamin", "text": "Was ACME designed assuming that the same ACME account key would be reused across multiple accounts? I'm not familiar enough with the details to know if there is a problem, but it's pretty easy for protocols to not survive such things. E.g. if a signature for account under CA1 can be used to spoof the account under CA2.
", "time": "2024-03-21T07:00:26Z"}, {"author": "Mike Ounsworth", "text": "Aaron Gable said:
\n\n\nMy gut feeling is that a) the second draft is talking about a problem that needs to be solved, but also b) I believe it can be solved entirely with mechanisms that already exist within ACME and may not need a full document (or maybe just an informational document describing how best to use those existing mechanisms)
\n
Thanks Aaron!
\nWould you be willing to have a chat with me offline after 119?
I.e. unless all the signatures include sufficient context, it's probably not safe to do as the presentation seems to suggest.
", "time": "2024-03-21T07:00:59Z"}]