5 ms·

> So on one hand you believe that supporting one standard will necessarily come at the cost of supporting another (I don't), So, you think vendors who have cov

> So on one hand you believe that supporting one standard will necessarily come at the cost of supporting another (I don't), 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%? > and you agree that what I suggested might cover 99%+ of the current user base, yet you favor a solution that depends on global addresses, something which definitely doesn't come close to 99% of potential users? 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. > Well, if you want to be really anal about it you could call them "addresses which fall into one of the address ranges allocated for private use", but you're just splitting hairs. But that is still equally misleading. There is nothing "private" about those addresses, and in particular nothing "more private" than globally routable addresses. Anyone can use those addresses, all the RFC essentially says is that you won't collide with addresses allocated by RIRs, but they might collide with other administrative domains that choose to use the same prefix. That doesn't mean that you cannot use them on a WAN, or between companies, or really anywhere where you can agree with all participating networks on the allocations. All it means is you have to expect collisions if you connect previously separate administrative domains, and that you cannot expect yout ISP to announce them for you on the public internet, that's it. 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. > There is no guarantee, but that's different from saying that it's inherently unsafe. 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". > It's a reflection on how the internet is built. It doesn't matter that in the ideal network, everything might have an address, when pretty much every device is behind some kind of NAT. IPv6? Come back when it's widely adopted. 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?! Or do you think we should just wait until device vendors have screwed up IPv6 before we try to enforce some sensible policy? > It stopped mattering because of address exhaustion and slow adoption of IPv6. Now, NAT is an integral part of the internet. I'm not trying to justify it or state this as a matter of preference—I'd definitely prefer having a ton of IPv6 addresses over the single IPv4 address I actually have—I'm just laying things out as they are, and how they are for the vast majority of consumers. So ... because noone uses IPv6, you suggested to use ULA as an indicator for security?! I am not sure I follow ... > No. Flagging a website as "safe" when it can not be established that it is safe is at least as wrong as flagging it as "unsafe" when it can not be established as being unsafe. 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. > What I'm suggesting, not flagging it in any particular way at all, would be taking a neutral stance. 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". > IMO, the practice of calling HTTPS sites "secure" is itself potentially misleading to consumers. It is only secure in a very specific sense, likely not in the broader sense a layman would consider. Well, yeah, but that is not really relevant to the question about warning about an insecure situation. Just because there are insecure situations that you cannot warn about, does not mean that therefore warning about other insecure situations isn't useful. Really, it makes much more sense to warn about insecure situations (which means, situations not known to be secure against certain types of attacks deemed relevant in the respective context) than to in display anything that says "this is secure", as security is alway relative to specific attacks, not a global property. > The question I stop at is "why is my browser supposed to know that?" Because your browser should help you protect your personal data that you process using your browser? I mean, I don't think it should know that, it should just enforce the same encryption requirements everywhere, but you seem to disagree with that because there are networks where your personal data is secure without encryption--in which case, your browser would either have to give up the goal of protecting your personal data, or it would have to know about which parts of your network are secure without encryption. > Both a way of verifying and distributing certificates network-wide in a LAN and for those certificates to be usable globally. Well, that would be a pairing mechanism then?! (Which still should not overload global routability with security semantics.) > The premise of my suggestion is that the browsers won't back down from indiscriminately marking plain HTTP sites as insecure, hence "Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks."—so suppose they would support such a method. Would that be better or worse than current practice? It depends on the mechanism? Yes, centralized certificate management for your own devices would be useful, but it should not in any way overload the routability of addresses. If you want to use the LAN as a semi-trusted key exchange mechanism, that probably should happen at the ethernet layer. Or maybe with a one-hop TTL on the IP layer. You have to detect whether you are on the same LAN, not whether you are using an RFC1918/ULA prefix, because not all LANs use RFC1918/ULA, and nor all RFC1918/ULA are limited to a LAN, let alone a trusted LAN. > That's a load of conjecture. I'm not sure how to respond except with a bunch of other conjecture, so I'll refrain. It is mostly an observation of what always happens in such situations.

boomlinde 9y ago
> 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...

boomlinde 9y ago

> 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...