5 ms·

> So, you think vendors who have covered 99%+ of their userbase with a solution will generally also implement an alternative that is way more complicated for th

> So, you think vendors who have covered 99%+ of their userbase with a solution will generally also implement an alternative that is way more complicated for the remaining 1%? Not necessarily, but the designer of a standard could take both use cases into account. > No, I favor a solution that does not depend on the global (non-)routability of an address, i.e., a solution that works for 100% of users. What, more precisely? Of course taking into consideration that 100% of users might not even have an internet connection. One thing I'd like is for devices to a their key signature printed on a sticker. Then I can verify the signature, log in and generate a new key and password, generate a certificate that I can install myself or sign up with a service like Let's Encrypt. > But that is still equally misleading. There is nothing "private" about those addresses, and in particular nothing "more private" than globally routable addresses. No, it's not misleading to say that they are allocated for private use. Your ISP drops connections to these addresses because they respect RFC1819 and don't route to the private address ranges. Even if they didn't, these address ranges are still allocated for private use, and your ISP is Wrong. They're only routable in the sense that IP would technically allow it, but the internet is not simply IP but a collection of standards and best practices. And sure, "private" has a very broad meaning. A browser could very well flag a certificate that was distributed from a private address as such and let the user decide whether they trust that source. > Also, just as you can use non-globally routable addresses between networks, you can use globally routable addresses for private networks, and you should if you can (which in practice means when you build an IPv6 network): Even if you build a network that is not intended to be connected to the internet at all, if you do have a globally routable IPv6 prefix allocated for your organization, you should number that network with addresses from that prefix. Sure. But again, "in practice means when you build an IPv6 network", i.e. not a typical consumer, for how long more? In an enterprise there are already many different ways to solve the problem of authentication, certificate signing and encryption. Consider that the average internet user doesn't even have a registered domain name or a static IP allocation. > No, it's actually not. "unsafe" does not mean "you will hurt yourself", it means "it has not been established that you won't hurt yourself". So everything on the web should be flagged by the browser as unsafe? I don't know how the browser can ever safely establish that I won't hurt myself. "Unsafe" and "safe" are two sides of a subjective, blurry line, at best a reasonable assumption and at worst an arbitrary handwave. IMO, the browser is taking what should be exact descriptions of the nature of the connection and water them down to vague, misleadingly simplified concepts. The browser could tell me that my connection to a site is unencrypted, that it is encrypted with an uncertified key, or that it's not encrypted, and when you click them they could show a help text describing what that means exactly, the possible consequences of using the service and details on the key and certificate if applicable. When I click the "Secure" badge in Chrome, I don't even get to see which CA signed it, or a public key. "Secure" and "Insecure" mean just that, rather impossible things for a browser to verify, and something that a user unfamiliar with the underlying technology may interpret as an authoritative rating of the provider of the service as a whole, when in reality there are many more aspects to take into a count in deciding whether a site is secure or insecure. > So, for the question of how to achieve (as close as possible to) an ideal network, it doesn't matter what the ideal network would look like?! Well, it involves IPv6, we can start there. We're talking about a new security policy that a major browser seems to want to implement shortly, definitely much more shortly than full IPv6 rollout. > Or do you think we should just wait until device vendors have screwed up IPv6 before we try to enforce some sensible policy? This is a very loaded question, given that we still disagree on whether a solution that works well both for globally routable and NATed devices is possible. > So ... because noone uses IPv6, you suggested to use ULA as an indicator for security?! I am not sure I follow ... I never said that no one uses IPv6, so I agree that you don't follow. > No, you don't establish "unsafety", that is the default assumption. The only way to establish that something is unsafe is to show after the fact that someone got hurt, which is just completely useless as a security mechanism. Let's say that I see your ladder. It's broken, so I tell you that it's unsafe. Unreasonable assumption? You take it down and bring another ladder. I don't see it, but I tell you it's unsafe. You see it and can clearly say that it isn't. Is it unsafe? Is it reasonable for me to tell you that it is unsafe? "Unsafety" isn't the default assumption that a browser makes (and with regards to plain HTTP in particular still isn't in the version of Chrome I'm using). > Wouldn't a neutral stance be to instead display a security status of "security unknown" (which is obviously equivalent to insecure)? "Not flagging it in any particular way" simply means that the user makes an assumption one way or another, not that the user thinks "it is unknown whether this is secure". Maybe that's actually the better option. But no, "security unknown" in that sense is not equivalent to insecure. As an extreme, I could create a network with an Ethernet cable between two off-grid devices that I control in a faraday cage. On the other end of the extreme, someone could be tapping a cable far away from my computer and figure out what connections I make regardless of encrypted data. Somewhere in between the two extremes, close to the likely, the party that I establish a secure connection too could be sharing our communication with other parties. > Because your browser should help you protect your personal data that you process using your browser? We've already established that the browser can't know it, so is the browser a fundamentally flawed concept? > Well, that would be a pairing mechanism then?! (Which still should not overload global routability with security semantics.) Yes? The only part you seem to disagree with is the possibility of having a router in a local network (and yes, local networks exist) facilitate and streamline the exchange. > If you want to use the LAN as a semi-trusted key exchange mechanism, that probably should happen at the ethernet layer. So again, a perfect application for a router? The router is in a perfect position to verify that I am on its network. > It is mostly an observation of what always happens in such situations. Yes, as evident from the absolute lack of overlapping authentication and encryption standards...

zAy0LfpBZLC8mAC 9y ago
[part 1] > Not necessarily, but the designer of a standard could take both use cases into account. Which doesn't help if it's a separate mechanism. If 1% of the work gets you to the goal in 99% of the cases, that's what vendors will do. Whether that fulfills the requirements of some standard or not does not matter. > What, more precisely? I am not making any suggestions as to the solution. > Of course taking into consideration that 100% of users might not even have an internet connection. So, if the device is one that does not inherently need global internet connectivity to be useful, then, yeah, things should work without global internet connectivity. > One thing I'd like is for devices to a their key signature printed on a sticker. Then I can verify the signature, log in and generate a new key and password, generate a certificate that I can install myself or sign up with a service like Let's Encrypt. Well, a fixed key is a problem, but other than that, yeah, an out-of-band path for key exchange sounds good. > No, it's not misleading to say that they are allocated for private use. Your ISP drops connections to these addresses because they respect RFC1819 and don't route to the private address ranges. Even if they didn't, these address ranges are still allocated for private use, and your ISP is Wrong. They're only routable in the sense that IP would technically allow it, but the internet is not simply IP but a collection of standards and best practices. OK, let's get this straight: What does "private" mean? It's a word with a whole lot of only partially overlapping definitions. For the purposes of this discussion, it is important to distinguish the aspect of "independent from official entities" from the aspect of "not revealed to the public", i.e. "providing privacy". RFC1918 addresses are only private in the former sense: You can allocate and use them without coordinating with RIRs or your ISP. However, they have absolutely nothing to do with the latter sense of providing privacy. That is why it is misleading to call them "private addresses": People understand that to mean that they are defined to provide some sort of secrecy or privacy or protection from the public or something along those lines, which they don't. It's not wrong, because there is a different meaning of "private" that fits exactly what RFC1918 are defined to be used for, but it is misleading because it leads people to assume that it encompasses more than that. Also, whether ISPs do it or not doesn't really matter. What matters is that RFC1918 address space is in fact routed between networks that are not intended to trust each other. And that is perfectly within the uses intended in RFC1918. The RFC isn't concerned with home networks, really, but with "enterprises", and it defines "an enterprise" to be the scope of an RFC1918 allocation. Nowhere does it say that that implies any sort of trust or security relationship between machines within such an allocation. And also, in practice, it is common to link RFC1918 networks of different "enterprises" together, as a sort-of "meta-enterprise", where a trust relationship is even less likely. The only thing that is "private" about RFC1918 addresses is that you can allocate them without coordination with IANA/RIRs/ISPs, and that you cannot expect an ISP to route them for you on the global internet. There is no privacy specified in the RFC. > And sure, "private" has a very broad meaning. A browser could very well flag a certificate that was distributed from a private address as such and let the user decide whether they trust that source. How does it matter for this whether the address is "private" (i.e., allocated without coordination with IANA/RIRs/ISPs)? > Sure. But again, "in practice means when you build an IPv6 network", i.e. not a typical consumer, for how long more? Erm, most IPv6 use is by consumers, with ~ 20% adoption based on google users?! Not sure whether that's quite "typical" yet, but certainly not unusual either. Most user devices support IPv6, and increasingly, ISPs are rolling out IPv6 to their customers with new subscriptions, which tends to come with new routers, which means that at that point their network is using IPv6 for all services that support it. > Well, it involves IPv6, we can start there. We're talking about a new security policy that a major browser seems to want to implement shortly, definitely much more shortly than full IPv6 rollout. Yes, and that is the only way to do it. If you wait until after full IPv6 rollout, you will have to work around assumptions that device vendors by then will have made based on the browser's behaviour, which means it only gets harder to implement. If you want to have any hope of success, you have to act now, when your actions can shape what device vendors will do. > This is a very loaded question, given that we still disagree on whether a solution that works well both for globally routable and NATed devices is possible. You have so far failed to even show a solution that works better for NATed devices than non-NATed ones. > I never said that no one uses IPv6, so I agree that you don't follow. Replace "noone" with "essentially noone" if you want to get my point. > Let's say that I see your ladder. It's broken, so I tell you that it's unsafe. Unreasonable assumption? You take it down and bring another ladder. I don't see it, but I tell you it's unsafe. You see it and can clearly say that it isn't. Is it unsafe? Is it reasonable for me to tell you that it is unsafe? Unsafety is not a(n objective) property of the ladder, it's a (subjective) state of your knowledge. The ladder will only either fail or not (that is an objective fact about the ladder). Even a ladder with partially broken steps might still hold up, and a ladder that is all new and shiny can still have some manufacturing defect that causes it to fail on first use. The former is good to use, the latter is not. But that is a useless concept if your goal is to minimize harm because you only know that after the fact. So, what we use instead is a concept of "unsafety". Statements about unsafety are an expression of our knowledge about something. So, the ladder with broken steps is considered unsafe, because based on what we generally know about the statistical properties of ladders with broken steps, they are known to have an increased failure rate. But then, you might apply load tests to that ladder and establish that it does carry the loads required reliably if you avoid the obviously broken steps, in which case it can be considered not unsafe. Mind you, nothing has changed about the ladder, only our knowledge about it has changed. Similarly for the new and shiny ladder, those are generally considered not unsafe because of what we statistically know about new and shiny ladders, and maybe about how ladders are tested after manufacturing. But then, you could test that as well, and maybe find that it breaks apart under light load, at which point you would change to considering it unsafe. Again, nothing has changed about the ladder, it's all about the knowledge you have about it. And the tests I suggested are not the end of that process of discovering the unsafety of a thing. You might still do other tests yet and come to yet another conclusion (like, I dunno, the testing conditions were unnecessarily harsh, and under more realistic usage conditions the opposite conclusion is appropriate). Now, not knowing anything about the ladder is just another state of knowledge. And if your goal is to minimize harm, then the default is not to assume safety. Again, that is in no way a statement about the ladder. That does not mean the ladder won't hold up. That only means that the ladder is not known (to you!) to hold up. It is always and exclusively a statement about your knowledge about the ladder. This is not about answering the question "will the ladder fail?", this is about answering the question "is it known to the best of our understanding that the ladder will not fail under some generally expected load conditions?". If the answer to that is "no", then that is reason to be cautious, and that is why the browser warns you/is going to warn you. You can of course argue that your goal is not to minimize harm, in which case the default assumption does not apply ... but then the whole discussion is pointless, as you are then essentially just saying "if you don't care about minimizing harm, there is no problem with trusting unencrypted connections (of some sort or another)". True, but not my goal, and obviously also not the goal of those people implementing the change. > Maybe that's actually the better option. But no, "security unknown" in that sense is not equivalent to insecure. As an extreme, I could create a network with an Ethernet cable between two off-grid devices that I control in a faraday cage. Yes, you could. But the browser doesn't know that. Therefore, its subjective determination is "this is not known to me to protect your private data", and that is what it is telling you. If you know better, that's fine, but the browser doesn't, so it warns you. If you don't know better, you better should listen to what your browser is telling you if your goal is to minimize harm. If you do know better, why do you care that your browser warns you based on its incomplete knowledge about the world?

zAy0LfpBZLC8mAC 9y ago

[part 1] > Not necessarily, but the designer of a standard could take both use cases into account. Which doesn't help if it's a separate mechanism. If 1% of the work gets you to the goal in 99% of the cases, that's what vendors will do. Whether that fulfills the requirements of some standard or not does not matter. > What, more precisely? I am not making any suggestions as to the solution. > Of course taking into consideration that 100% of users might not even have an internet connection. So, if the device is one that does not inherently need global internet connectivity to be useful, then, yeah, things should work without global internet connectivity. > One thing I'd like is for devices to a their key signature printed on a sticker. Then I can verify the signature, log in and generate a new key and password, generate a certificate that I can install myself or sign up with a service like Let's Encrypt. Well, a fixed key is a problem, but other than that, yeah, an out-of-band path for key exchange sounds good. > No, it's not misleading to say that they are allocated for private use. Your ISP drops connections to these addresses because they respect RFC1819 and don't route to the private address ranges. Even if they didn't, these address ranges are still allocated for private use, and your ISP is Wrong. They're only routable in the sense that IP would technically allow it, but the internet is not simply IP but a collection of standards and best practices. OK, let's get this straight: What does "private" mean? It's a word with a whole lot of only partially overlapping definitions. For the purposes of this discussion, it is important to distinguish the aspect of "independent from official entities" from the aspect of "not revealed to the public", i.e. "providing privacy". RFC1918 addresses are only private in the former sense: You can allocate and use them without coordinating with RIRs or your ISP. However, they have absolutely nothing to do with the latter sense of providing privacy. That is why it is misleading to call them "private addresses": People understand that to mean that they are defined to provide some sort of secrecy or privacy or protection from the public or something along those lines, which they don't. It's not wrong, because there is a different meaning of "private" that fits exactly what RFC1918 are defined to be used for, but it is misleading because it leads people to assume that it encompasses more than that. Also, whether ISPs do it or not doesn't really matter. What matters is that RFC1918 address space is in fact routed between networks that are not intended to trust each other. And that is perfectly within the uses intended in RFC1918. The RFC isn't concerned with home networks, really, but with "enterprises", and it defines "an enterprise" to be the scope of an RFC1918 allocation. Nowhere does it say that that implies any sort of trust or security relationship between machines within such an allocation. And also, in practice, it is common to link RFC1918 networks of different "enterprises" together, as a sort-of "meta-enterprise", where a trust relationship is even less likely. The only thing that is "private" about RFC1918 addresses is that you can allocate them without coordination with IANA/RIRs/ISPs, and that you cannot expect an ISP to route them for you on the global internet. There is no privacy specified in the RFC. > And sure, "private" has a very broad meaning. A browser could very well flag a certificate that was distributed from a private address as such and let the user decide whether they trust that source. How does it matter for this whether the address is "private" (i.e., allocated without coordination with IANA/RIRs/ISPs)? > Sure. But again, "in practice means when you build an IPv6 network", i.e. not a typical consumer, for how long more? Erm, most IPv6 use is by consumers, with ~ 20% adoption based on google users?! Not sure whether that's quite "typical" yet, but certainly not unusual either. Most user devices support IPv6, and increasingly, ISPs are rolling out IPv6 to their customers with new subscriptions, which tends to come with new routers, which means that at that point their network is using IPv6 for all services that support it. > Well, it involves IPv6, we can start there. We're talking about a new security policy that a major browser seems to want to implement shortly, definitely much more shortly than full IPv6 rollout. Yes, and that is the only way to do it. If you wait until after full IPv6 rollout, you will have to work around assumptions that device vendors by then will have made based on the browser's behaviour, which means it only gets harder to implement. If you want to have any hope of success, you have to act now, when your actions can shape what device vendors will do. > This is a very loaded question, given that we still disagree on whether a solution that works well both for globally routable and NATed devices is possible. You have so far failed to even show a solution that works better for NATed devices than non-NATed ones. > I never said that no one uses IPv6, so I agree that you don't follow. Replace "noone" with "essentially noone" if you want to get my point. > Let's say that I see your ladder. It's broken, so I tell you that it's unsafe. Unreasonable assumption? You take it down and bring another ladder. I don't see it, but I tell you it's unsafe. You see it and can clearly say that it isn't. Is it unsafe? Is it reasonable for me to tell you that it is unsafe? Unsafety is not a(n objective) property of the ladder, it's a (subjective) state of your knowledge. The ladder will only either fail or not (that is an objective fact about the ladder). Even a ladder with partially broken steps might still hold up, and a ladder that is all new and shiny can still have some manufacturing defect that causes it to fail on first use. The former is good to use, the latter is not. But that is a useless concept if your goal is to minimize harm because you only know that after the fact. So, what we use instead is a concept of "unsafety". Statements about unsafety are an expression of our knowledge about something. So, the ladder with broken steps is considered unsafe, because based on what we generally know about the statistical properties of ladders with broken steps, they are known to have an increased failure rate. But then, you might apply load tests to that ladder and establish that it does carry the loads required reliably if you avoid the obviously broken steps, in which case it can be considered not unsafe. Mind you, nothing has changed about the ladder, only our knowledge about it has changed. Similarly for the new and shiny ladder, those are generally considered not unsafe because of what we statistically know about new and shiny ladders, and maybe about how ladders are tested after manufacturing. But then, you could test that as well, and maybe find that it breaks apart under light load, at which point you would change to considering it unsafe. Again, nothing has changed about the ladder, it's all about the knowledge you have about it. And the tests I suggested are not the end of that process of discovering the unsafety of a thing. You might still do other tests yet and come to yet another conclusion (like, I dunno, the testing conditions were unnecessarily harsh, and under more realistic usage conditions the opposite conclusion is appropriate). Now, not knowing anything about the ladder is just another state of knowledge. And if your goal is to minimize harm, then the default is not to assume safety. Again, that is in no way a statement about the ladder. That does not mean the ladder won't hold up. That only means that the ladder is not known (to you!) to hold up. It is always and exclusively a statement about your knowledge about the ladder. This is not about answering the question "will the ladder fail?", this is about answering the question "is it known to the best of our understanding that the ladder will not fail under some generally expected load conditions?". If the answer to that is "no", then that is reason to be cautious, and that is why the browser warns you/is going to warn you. You can of course argue that your goal is not to minimize harm, in which case the default assumption does not apply ... but then the whole discussion is pointless, as you are then essentially just saying "if you don't care about minimizing harm, there is no problem with trusting unencrypted connections (of some sort or another)". True, but not my goal, and obviously also not the goal of those people implementing the change. > Maybe that's actually the better option. But no, "security unknown" in that sense is not equivalent to insecure. As an extreme, I could create a network with an Ethernet cable between two off-grid devices that I control in a faraday cage. Yes, you could. But the browser doesn't know that. Therefore, its subjective determination is "this is not known to me to protect your private data", and that is what it is telling you. If you know better, that's fine, but the browser doesn't, so it warns you. If you don't know better, you better should listen to what your browser is telling you if your goal is to minimize harm. If you do know better, why do you care that your browser warns you based on its incomplete knowledge about the world?