4 ms·

If I'm reading it right, this RFC is seeking public input on a proposed policy of considering pervasive monitoring (PM) another attack vector among a host of at

If I'm reading it right, this RFC is seeking public input on a proposed policy of considering pervasive monitoring (PM) another attack vector among a host of attack vectors that should be considered when designing protocols. I am blissfully ignorant on the politics of how the IETF works so who knows what the actual odds are. But I think it's good that it's at least being considered. That said, I don't know how or if "pervasive monitoring" is mitigated any differently than plain old MITMs. Seems a bit like tilting at windmills if the corporations that host are data are either voluntarily complying with "PM" or being compelled to by subpoena.

AnthonyMouse 12y ago
> That said, I don't know how or if "pervasive monitoring" is mitigated any differently than plain old MITMs. One of the primary concerns with pervasive monitoring is metadata. We could see an increase in protocols that make efforts to not only protect what you're communicating but who you're communicating with. > Seems a bit like tilting at windmills if the corporations that host are data are either voluntarily complying with "PM" or being compelled to by subpoena. The general idea is to change the status quo. Use distributed systems rather than centralized ones.
- XorNot 12y ago
  Yay, a whole new class of protocols which will make it harder to communicate with each other. I'm all for secure protocols but metadata protection is so nebulously defined, and introduces such ridiculous problems, that I really don't want it built into core protocols. There is no solution to it - moving traffic from here to there via a third party requires telling someone how to do it. So long as that third party exists, the problem is unsolvable outside of distributed-risk models like Tor.
  - AnthonyMouse 12y ago
    > There is no solution to it - moving traffic from here to there via a third party requires telling someone how to do it. Why do I have to do everything myself? OK, here's IPv8: The only unencrypted part of the packet is the destination address, the rest of the packet is encrypted with CurveCP. Moreover, every router has a public key, and you can set the "destination address" to any router on the path to the actual destination and encrypt the entire actual packet with its public key. That router will receive the packet and decrypt it only to discover that it contains another encrypted packet, which it sends on its way to the next destination. If you like you can do this more than once. It's onion routing at the IP level. Tor without the inefficiency, because the "relays" are already devices on the path to the destination, and with in some ways better security because each "relay" doesn't inherently know whether the previous hop was also the previous relay or whether the next relay is the actual destination.
    - pjc50 12y ago
      "destination address" to any router on the path to the actual destination 1) In normal IP, the source does not know the route to the destination. You can try to guess with traceroute, but that's not authoritative. And the route out may not be the same as the route back. There may not even be a single well defined route. 2) This has the same pattern as the various reflection/amplification attacks and facilitates DDOS. I think that what "network management" means; if you provide means for people to flood the network with bad traffic then it becomes unusable for everyone, or at least it becomes possible to silence a site or endpoint on an ongoing basis. 3) You've assumed that there's no legal responsibility attached to re-emitting these packets.
      - AnthonyMouse 12y ago
        > 1) In normal IP, the source does not know the route to the destination. You can try to guess with traceroute, but that's not authoritative. And the route out may not be the same as the route back. There may not even be a single well defined route. This isn't normal IP, it's new IP. Moreover, using a relay would be optional (just encrypting the source address would give 90% of the benefit) and the worst case for having chosen one that isn't a router on the preferred route is that the packet would take a mildly suboptimal path to the destination. > 2) This has the same pattern as the various reflection/amplification attacks and facilitates DDOS. I think that what "network management" means; if you provide means for people to flood the network with bad traffic then it becomes unusable for everyone, or at least it becomes possible to silence a site or endpoint on an ongoing basis. I don't see amplification. You send one packet, each router forwards it once. I suppose the attacker could have a packet go back and forth between the same routers multiple times but that is already possible in existing IP using source routing and is trivially mitigated by adding a hop count / TTL field. Amplification means you can send a small amount of data and cause someone else to send a large amount of data to the target. For example, if you send an EDNS query to a DNS server with many records for a particular name, the query is very small and the response could be very large. I don't see that here. Reflection is much more benign. It doesn't allow an attacker with 100Mbps of bandwidth to convert it into 10000Mbps of bandwidth, it only allows an attacker who doesn't care about receiving a response to remain anonymous. So your complaint about a technical measure designed to allow people to remain anonymous is that it would allow people to remain anonymous. Feature not bug. > 3) You've assumed that there's no legal responsibility attached to re-emitting these packets. The existing routers on the existing internet are already re-emitting all the packets. That's what routers are for. Obviously Congress could pass whatever law making it legal or illegal after the fact, but that's orthogonal to the technical issue of how it can be done whatsoever.
  - sp332 12y ago
    Yup, the only way to really hide metadata is for every device to talk to every other device constantly, either with "real" data if they have something to send or "padding" if they don't. That way a sniffer can't tell who you're sending real data to. Everything else is vulnerable.
cnst 12y ago
> That said, I don't know how or if "pervasive monitoring" is mitigated any differently than plain old MITMs. The difference is that with passive monitoring, you don't have to worry about authentication, and opportunistic encryption without any sort of authentication is good enough. Think STARTTLS in SMTP. I actually found this RFC7258 through http://tools.ietf.org/html/draft-nottingham-http2-encryption-03 http://tools.ietf.org/html/draft-nottingham-http2-encryption... "Opportunistic Encryption for HTTP URIs", so, there's that. Personally very interested in this, as I have a dozen of different domains and subdomains for my non-profit reference web-sites like http://mdoc.su/ http://mdoc.su/, and I also care about supporting legacy clients and having minimal administrative costs, hence I cannot deploy HTTPS://.
- dchest 12y ago
  In your last paragraph, you've actually provided a good example of why opportunistic encryption is dangerous. Instead of deploying proper HTTPS, you're thinking that opportunistic encryption is good enough for you, that it is a valid replacement for HTTPS.
  - belorn 12y ago
    Your comment provide an excellent example why current views of HTTPS is dangerous to security. It diffuses the line between encryption, authentication and trust. Opportunistic encryption adds encryption as a fundamental part of the network, where HTTPS create added features on top of an primitive network design. So long one understand what HTTPS do, putting encryption into the transport layer will highlight HTTPS as an authentication system and make network security more understandable, reliable, and in the long run, better.
  - cnst 12y ago
    > Instead of deploying proper HTTPS, you're thinking that opportunistic encryption is good enough for you, that it is a valid replacement for HTTPS. But I will never deploy HTTPS:// regardless -- no backwards compatibility with http-only clients, not even much compatibility with HTTPS-enabled clients with no SNI support (e.g. Android 2.3 or Windows XP), the tie-in of the new address scheme, huge opportunity costs for non-commercial multi-dozen-site owners (certificates for wildcard domains like "*.example.net" cost several times more than the domain names themselves; plus the multi-domain certificates for both both "example.net" and "example.com" simultaneously (to avoid having to deal with SNI) cost even more, and those 50$+/domain for multi-domain certs don't even seem to have wildcard support, either). So, even though I will never deploy HTTPS://, you think opportunistic encryption is still a waste of time for me? IETF now begs to differ! And I'm very glad they finally do!
fulafel 12y ago
> If I'm reading it right, this RFC is seeking public input on a proposed policy No, all the IETF published documents are called "request for comments" for historical/cultural reasons. This is an actual finalized policy document. The phase where the IETF seeks input to these is the "Internet-Draft stage".
- mattdeboard 12y ago
  Oh. That's.. strange, but good to know. Thanks.

AnthonyMouse 12y ago

> That said, I don't know how or if "pervasive monitoring" is mitigated any differently than plain old MITMs. One of the primary concerns with pervasive monitoring is metadata. We could see an increase in protocols that make efforts to not only protect what you're communicating but who you're communicating with. > Seems a bit like tilting at windmills if the corporations that host are data are either voluntarily complying with "PM" or being compelled to by subpoena. The general idea is to change the status quo. Use distributed systems rather than centralized ones.

XorNot 12y ago
Yay, a whole new class of protocols which will make it harder to communicate with each other. I'm all for secure protocols but metadata protection is so nebulously defined, and introduces such ridiculous problems, that I really don't want it built into core protocols. There is no solution to it - moving traffic from here to there via a third party requires telling someone how to do it. So long as that third party exists, the problem is unsolvable outside of distributed-risk models like Tor.
- AnthonyMouse 12y ago
  > There is no solution to it - moving traffic from here to there via a third party requires telling someone how to do it. Why do I have to do everything myself? OK, here's IPv8: The only unencrypted part of the packet is the destination address, the rest of the packet is encrypted with CurveCP. Moreover, every router has a public key, and you can set the "destination address" to any router on the path to the actual destination and encrypt the entire actual packet with its public key. That router will receive the packet and decrypt it only to discover that it contains another encrypted packet, which it sends on its way to the next destination. If you like you can do this more than once. It's onion routing at the IP level. Tor without the inefficiency, because the "relays" are already devices on the path to the destination, and with in some ways better security because each "relay" doesn't inherently know whether the previous hop was also the previous relay or whether the next relay is the actual destination.
  - pjc50 12y ago
    "destination address" to any router on the path to the actual destination 1) In normal IP, the source does not know the route to the destination. You can try to guess with traceroute, but that's not authoritative. And the route out may not be the same as the route back. There may not even be a single well defined route. 2) This has the same pattern as the various reflection/amplification attacks and facilitates DDOS. I think that what "network management" means; if you provide means for people to flood the network with bad traffic then it becomes unusable for everyone, or at least it becomes possible to silence a site or endpoint on an ongoing basis. 3) You've assumed that there's no legal responsibility attached to re-emitting these packets.
    - AnthonyMouse 12y ago
      > 1) In normal IP, the source does not know the route to the destination. You can try to guess with traceroute, but that's not authoritative. And the route out may not be the same as the route back. There may not even be a single well defined route. This isn't normal IP, it's new IP. Moreover, using a relay would be optional (just encrypting the source address would give 90% of the benefit) and the worst case for having chosen one that isn't a router on the preferred route is that the packet would take a mildly suboptimal path to the destination. > 2) This has the same pattern as the various reflection/amplification attacks and facilitates DDOS. I think that what "network management" means; if you provide means for people to flood the network with bad traffic then it becomes unusable for everyone, or at least it becomes possible to silence a site or endpoint on an ongoing basis. I don't see amplification. You send one packet, each router forwards it once. I suppose the attacker could have a packet go back and forth between the same routers multiple times but that is already possible in existing IP using source routing and is trivially mitigated by adding a hop count / TTL field. Amplification means you can send a small amount of data and cause someone else to send a large amount of data to the target. For example, if you send an EDNS query to a DNS server with many records for a particular name, the query is very small and the response could be very large. I don't see that here. Reflection is much more benign. It doesn't allow an attacker with 100Mbps of bandwidth to convert it into 10000Mbps of bandwidth, it only allows an attacker who doesn't care about receiving a response to remain anonymous. So your complaint about a technical measure designed to allow people to remain anonymous is that it would allow people to remain anonymous. Feature not bug. > 3) You've assumed that there's no legal responsibility attached to re-emitting these packets. The existing routers on the existing internet are already re-emitting all the packets. That's what routers are for. Obviously Congress could pass whatever law making it legal or illegal after the fact, but that's orthogonal to the technical issue of how it can be done whatsoever.
- sp332 12y ago
  Yup, the only way to really hide metadata is for every device to talk to every other device constantly, either with "real" data if they have something to send or "padding" if they don't. That way a sniffer can't tell who you're sending real data to. Everything else is vulnerable.

cnst 12y ago

> That said, I don't know how or if "pervasive monitoring" is mitigated any differently than plain old MITMs. The difference is that with passive monitoring, you don't have to worry about authentication, and opportunistic encryption without any sort of authentication is good enough. Think STARTTLS in SMTP. I actually found this RFC7258 through http://tools.ietf.org/html/draft-nottingham-http2-encryption-03 http://tools.ietf.org/html/draft-nottingham-http2-encryption... "Opportunistic Encryption for HTTP URIs", so, there's that. Personally very interested in this, as I have a dozen of different domains and subdomains for my non-profit reference web-sites like http://mdoc.su/ http://mdoc.su/, and I also care about supporting legacy clients and having minimal administrative costs, hence I cannot deploy HTTPS://.

dchest 12y ago
In your last paragraph, you've actually provided a good example of why opportunistic encryption is dangerous. Instead of deploying proper HTTPS, you're thinking that opportunistic encryption is good enough for you, that it is a valid replacement for HTTPS.
- belorn 12y ago
  Your comment provide an excellent example why current views of HTTPS is dangerous to security. It diffuses the line between encryption, authentication and trust. Opportunistic encryption adds encryption as a fundamental part of the network, where HTTPS create added features on top of an primitive network design. So long one understand what HTTPS do, putting encryption into the transport layer will highlight HTTPS as an authentication system and make network security more understandable, reliable, and in the long run, better.
- cnst 12y ago
  > Instead of deploying proper HTTPS, you're thinking that opportunistic encryption is good enough for you, that it is a valid replacement for HTTPS. But I will never deploy HTTPS:// regardless -- no backwards compatibility with http-only clients, not even much compatibility with HTTPS-enabled clients with no SNI support (e.g. Android 2.3 or Windows XP), the tie-in of the new address scheme, huge opportunity costs for non-commercial multi-dozen-site owners (certificates for wildcard domains like "*.example.net" cost several times more than the domain names themselves; plus the multi-domain certificates for both both "example.net" and "example.com" simultaneously (to avoid having to deal with SNI) cost even more, and those 50$+/domain for multi-domain certs don't even seem to have wildcard support, either). So, even though I will never deploy HTTPS://, you think opportunistic encryption is still a waste of time for me? IETF now begs to differ! And I'm very glad they finally do!

fulafel 12y ago

> If I'm reading it right, this RFC is seeking public input on a proposed policy No, all the IETF published documents are called "request for comments" for historical/cultural reasons. This is an actual finalized policy document. The phase where the IETF seeks input to these is the "Internet-Draft stage".

mattdeboard 12y ago
Oh. That's.. strange, but good to know. Thanks.