1 / 7

(we need your advice!) Jon Peterson MIT– December 2010

IETF & Privacy. (we need your advice!) Jon Peterson MIT– December 2010. The IETF builds protocols. Protocols assume architectures Ideally, these protocols should be useful in a variety of architectures. However, certain protocols are not useful in some.

bryga
Download Presentation

(we need your advice!) Jon Peterson MIT– December 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF & Privacy (we need your advice!)Jon PetersonMIT– December 2010

  2. The IETF builds protocols • Protocols assume architectures • Ideally, these protocols should be useful in a variety of architectures. • However, certain protocols are not useful in some. • We don’t mandate implementation style and deployment characteristics, but we constrain them in various ways. • Example: DNS was designed to have a single root. • Ostensibly, the network intermediaries makes simple forwarding decisions, doesn’t inspect or log packets in any deeper semantics • Today, we have plenty of reason to fear otherwise

  3. Architecting for privacy • What does an application need to share to get a service delivered, and with whom? • Intermediation • SIP, for example, uses intermediaries to route requests • However, intermediaries inspect many other elements of requests • How can SIP share with intermediaries only the information they need to do their job? (RFC 3323 is a start) • How do we get other protocol designs to learn from this experience? • ALTO (ongoing right now) • How can the user share enough with the network for it to be useful and vice-versa?

  4. IPv6 Privacy Addresses • In IPv6 stateless addressing, the Interface identifier was constructed based on the MAC address. • This raised privacy concerns. • RFC 4941 supported a dynamically generated IPv6 Interface identifier. • Questions: • Threat model: Who are we attempting to hide the address from? ISP, eavesdropper (where?), other communication partner, government (police, fire, medical)? • The same mechanisms that allow ISPs to track users are used to provide location for emergency services and to deal with certain security attacks (botnets).

  5. “Hemispheres” in ALTO We, the P2P users and P2P vendors want to do ALTO, but we will not disclose info about the overlay H1 We, the network operators want to do ALTO, but we will not disclose info about the network topology and state H2 How to bring them together?

  6. Customizing data per recipient • Classic “presence” problem • I might want to share different presence information with my friend than with my boss (RFC 2778) • Had we defined “presence” as a unique rather than a potentially manifold property, however, would this be possible? • Some presence architectures admit of only one view of presence, which is either shared with a particular recipient or not • We layer our basic architecture for geolocation privacy on top of this (RFC 4119) • However, just because you choose to share information selectively, what about those you shared it with? • Policy framework in geopriv for expressing usage preferences about retention, redistribution, and so on

  7. What we need • Guidance to authors of protocol specifications on at least four fronts: • How do we build privacy threat models? • How do we design protocols that do not fall into obvious privacy traps? • What are some common ways around traps that you can’t get out of? • How do we document traps that we don’t how how to get out of? • draft-morris-privacy-considerations

More Related