*** DRAFT MINUTES - 20131114 *** Perpass "BoF" session - Considering pervasive monitoring -------------------------------------------------------- Wed, Nov 6, 1300, Regency D room Goals: - The primary goal of the session is to identify and plan for concrete IETF activities (e.g. new standards track documents or BCPs) that help mitigate pervasive monitoring. - As a secondary goal we also want to figure out how to use perpass list after Vancouver. Chairs: Stephen Farrell/Sean Turner Mailing list: https://www.ietf.org/mailman/listinfo/perpass Jabber: perpass@jabber.ietf.org (log: http://jabber.ietf.org/logs/perpass) Audio: http://ietf88streaming.dnsalias.net/ietf/ietf888.m3u Scribes: Paul Woulters, Karen O'Donoghue, Wendy Selzer Jabber scribe: Dan York, Peter StAndre Materials: - There's a list of relevant sessions here: http://down.dsg.cs.tcd.ie/misc/perpass-sessions.txt - And a rough list of relevant materials here: https://down.dsg.cs.tcd.ie/misc/perpass.txt - Elwyn Davies packaged up those drafts on Oct 29, a tarball can be found from the list archive here: http://www.ietf.org/mail-archive/web/perpass/current/msg00806.html minutes - topic 0000 - intro, agenda bash - chairs 0010 - overview pressie - Dave Thaler 0040 - open mic, have we level-set? 0060 - threat model - Brian Trammell 0070 - hard and open topics - Phillip Hallam-Baker 0080 - high level on more use of tls - Mark Nottingham 0090 - privacy bcp - Alissa Cooper 0100 - open mic, comments on pressies, what's missing? 0120 - summarise actions, open-points, Scott Brim Scott will try to draft a plan based on what he hears at the meeting, then present that here. 0150 - end Online agenda: http://tools.ietf.org/agenda/88/agenda-88-perpass.html Thanks to the note-takers and jabber scribes for doing such a good job! Meeting notes: Intro, Agenda Bash: =================== Stephen Farrell: Goals: identify and plan concrete IETF activities Secondary goal: what to do with the mailing list Non goals: bash any people or agencies Talk to us or any AD Overview Presentation: Dave Thaler ================================== Summary of Recent Pervasive Monitoring Threats Slides: http://www.ietf.org/proceedings/88/slides/slides-88-perpass-5.pdf Potential Threats: Pervasive monitoring is easier than targeted monitoring. Want to reverse it so that pervastive monitoring is more expensive than targeted. Goal of privacy mechanisms, get cost of information > value of information Goal of surveillance, to collect info. Types of info: data, metadata, keys Strategies from the news: - overt cooperation from entity - subvert general service - subvert target's system and covertly collect information How to get secret/private keys: - directly - lower entropy used to generate keys - use existing known weaknesses Multiple points of influence 1. Trusted Roots and certificate authorities: e.g. DigiNotar, Flame, debug tools->add root 2. Software creators & distributors (weak random number generators, compromise crypto APIs, exploit weaknesses in widely used end-user software, coerced backdoors) 3. Data repositories (email svrs, web svrs --> information, secret keys, data correlation) 4. Protocol & algorithm designers (influence solutions) 5. Network Operators 6. Physical fiber, wireless tower, satellite, etc (taps...) 7. Hardware designers & factories (backdoors, trojans Summary table - which portions of the matrix have been covered [slide 16] open-mic(1): ============ Steve Kent: You mentioned records of people checking into hotels. Copying of passport. Not an Internet enabled set of problems. Dave Thaler: This was intended to be scoped to what was within the scope of the IETF. Randy Bush: We can raise the aggregate costs, by encrypting everything and making them break it all to look for what they want. "I want to spread their budget." Sean: Defense in depth is what you want to do. Dave T.: Increase the cost James Woodyatt: Pervasive monitoring entities have budgets for influencing. Those who might be able to help us, we might not be able to trust them. How do we know who we can trust. Stephen: Part of this is not our problem, we use our open processes. James W: Can we adopt Stephen: We take open input from wherever it comes. Sean: Take comments Brian Smith- We could be more insistent when we get feedback about the rationale for that feedback. Rohan Mahy - legitimate uses of monitoring, no moral judgements David Thaler - my reason for this was identifying the stated reasons for monitoring. [ note to scribes: we can always listen to the recording afterward :-) ] Keith Moore - defenses shift attacks. It is worth thinking about where we would like them to attack (some are worse than others) There is benefit to having more people knowing about the monitoring. David Thaler: Shift from covert to overt, pervasive to targeted. Linus Nordberg: Doug Otis: in federated services, we need to have assurance that we are talking to services at the domain level - if we don't, we're really hurting ourselves Bill Manning : Are we trying to prevent operations people from doing their job (monitoring, traffic engineering). Bernard Aboba: we might need to question old values in existing documents Sean Turner: I agree, we need to figure out how to change things more quickly Ted Lemon: Changes in cryptography are not always a good thing. Concerned that we could adopt crypto that could make things worse Sean: Open review and study are critical. We have actual cryptographers on lists. Christian Huitema: we don't look at what information our protocols expose - e.g., SMTP addresses on mailing lists consider, in reviewing protocols, whether it exposes more information than necessary. Could we scrub more of that information? SF: on mailing list, considered UA string in HTTP, don't think we can get rid of it Brian Trammel: The Threat of Pervasive Surveillance =================================================== what is the adversary that we are attempting to protect the internet against.... Reference made to https://datatracker.ietf.org/doc/draft-trammell-perpass-ppa/ Slides: http://www.ietf.org/proceedings/88/slides/slides-88-perpass-3.pdf [1] Eavesdropping every packet on every wire (content, metadata, traffic analysis); compromise of intermediate systems; compromise of crypto protocols; compromise of endpoints; beyond the endpoints.(e.g social engineering) What's in scope for this WG/BOF? What information is actually exposed, what information do these protocols radiate? suggested in-scope for protocol development: eavesdropping and compromise of intermediate systems. Stephen: The scope of this draft and where it goes is up for discussion Phillip Hallam-Baker: The Hard(er) Problems =========================================== Slides: http://www.ietf.org/proceedings/88/slides/slides-88-perpass-2.pdf matrix: overt | covert traffic | increase work factor meta content make attack visible | prevent compromise The genius in the web is the hard problems they decided not to solve. (from Tim Berners-Lee) Don't need to defeat traffic analysis just need to make it more difficult. Forcing a covert attack into the open is a victory. Making them get a subpoena, increasing the work-factor, are wins. Blocking constraints: Usability - security must not require extra effort; must make sense in users' mental model Business model - you need one. open source model Viral marketing alone is not enough Defeating Traffic Analysis: can't encrypt at the routing layer or IP layer because addresses are needed to deliver consider encrypting at lower layers or higher layers hop-by-hop encryption valuable against traffic analysis Message Security: Asynchronous is harder than synchronous Email. can we solve the easy problem first, sending encrypted mail to people we know? The Trust Problem. Can't solve trust without infrastructure. Can't we get beyond the standards battle? how do we evaluate solutions to trust problems, "work-factor analysis" Mark Nottingham: More TLS ========================= Slides: http://www.ietf.org/proceedings/88/slides/slides-88-perpass-4.pdf Day before mtg in Berlin was the day of XKEYSCORE, caused us to think about what we could do in HTTP use of TLS is preferred Threat model, strictly passive attacks out of Berlin A. Opportunistic Encryption. -- don't worry about authentication, downgrade attacks, Deploying Opportunistic Encryption This makes some people very uncomfortable! creates confusion about security, go from two states to threee, encryption, authentication, encryption without authentication (need to fix def here) Some have expressed concern: that this would discourage the full use of TLS and encourage active attacks. B. Opportunistic Encryption with Server Authentication Maybe threat model does include active attacks, Leads you to opportunistic encryption with server authentication (protects against MITM, except for downgrade attacks 1. Barrier to deployment : obtain a cert 2. "Perfect" is the enemy of the good 3. Might as well do C. TLS Everywhere protocol-specific. e.g. for HTTP, it means only HTTPS This makes some people very uncomfortable! 1. Cost/overhead 2. Disempowers intermediaries - and we don't know how they will react Now we're in game theory, trying to figure out secondary and tertiary interactions. e.g., intermediaries allowing only known connections 3. Concerned that we might end up fragmenting the Internet What should we focus on? 1. Threat Model, 2. Tradeoffs, 3. Perceptions of Security There is much we don't know and can't predict. We shouldn't disrupt the existing ecosystem. where we can't predict, we should be wary of disrupting existing ecosystem. [ another note to scribes: we don't need to capture everything from the slides, that's what they are for ] :) yes sir... trying... Alissa Cooper: Privacy BCP ========================== Slides: http://www.ietf.org/proceedings/88/slides/slides-88-perpass-0.pdf Wrote draft building off existing consensus statements. Definition of personal data important to understanding the rest of the draft. Broad definition. Not much list discussion about "MUST minimize their use of such personal data" More discussion on list about "Opportunistic encryption MUST be defined for new IETF protocols" open-mic(2): ============ Question Queue: What should we be doing with a bias towards representing specific things: Ted Hardie: Terminology - two different definitions of opportunistic encryption (1) enrypt without authentication (2) encrypt when possible Alissa: encryption without prior arrangement (3rd thing) Keith Moore: opportunistic encryption as a minimum is only marginal benefit, since it can be easy to overcome. Be careful how we state rules, to account for protocol differences Alissa: We are just setting the floor not the ceiling. Keith: the problem is that floor often becomes the ceiling Eliot Lear: Please define what it is, more general than we should eliminate crime. Dan Harkins: IETF can define a strong random number generator. We should rely on what we are getting from our hardware; lots of security depends on good entropy sources Steve Kent: If this is a working group forming BOF, what would that working group do? Sean: This is not a working group forming BOF. Stephen: Intend is to identify bits and pieces that can be done somewhere in IETF, not forming specific WG. Ralf (no last name on tag) at the mic: IN UAE, Etisalad subverted large numbers of blackberries don't downplay the active attacks, they can be pervasive too Roberto Peon: I think we're lacking some specificity here, but I think encryption everywhere is a good thing - however we don't necessarily understand the implications (pervasive monitoring might not have anything to do with surveillance) encryption allows you to move forward with protocols Dave Crocker: Have not done well with security usability, merging S/MIME and PGP suggested, we have some barriers in this space that we don't know about. Large scale use of keys is something we want to avoid requiring. Kathleen Moriarty: Think about use cases during this work. Stephen: Threat model would be a useful document for protocol designers to remind them what they might have forgotten about. Robin Wilton: thanks Alissa for including minimizing personal data; but consider difficulties in defining what counts as personal data. IETF can/should go beyond definitional approach of EU legislation, define PII as Privacy Impacting Information. Stephen: Do you have a particular protocol in mind that that type of exercise could be applied to? Robin: Trying to encourage people to think beyond the current state of the art. Jana Iyengar: think about encryption at design time. Stephen: This type of thing is more pratical for new protocols. Keith Moore: On the notion of opportunistic encryption as the floor. The floor isn't high enough in general. If prior arrangement is a normal part of using the protocol, then perhaps opportunistics encryption isn't enough. Transparent proxies - interfere with encryption . "If it's indistinguishable from an attack, it is an attack." Middleboxes must be explicit to the endpoints. Stephen: There is alot of diameter and sip that just don't do TLS, Bernard Aboba: Provide new or updated guidelines on the use of cryptography as opposed to a Merike Kaeo: Why are people not using very good protocols that people spent years developing. Look at how people are circumventing protocols. Mark Townsley: most popular port: 80. 2nd most popular prominent feature: UPNP implemented badly, impossible to be updated, operated poorly... need to think beyond protocol design to deployment and operation. Nick Doty: procedural value of these drafts; consider privacy reviews, putting privacy considerations earlier in drafting process. Should we have a renewed organized privacy directorate? reference made to: http://tools.ietf.org/html/rfc6973 Stephen Farrell: we didn't get reviews because people didn't know privacy, or didn't know the document they were asked to review; Let us know if you want to do privacy reviews. John Mattsson. Be careful about the naming, don't imply that opportunistic encryption provides security. Fail to better security, not worse. Stephen: Somewhat skeptical that we should be forcing people to go somewhere that they clearly haven't gone. Jim Gettys: "rough consensus and running code" -- fewer of us are writing running code, but more of the code is open source, so we can get involved; younger devs know more UX. Get involved in open source infrastructure. Linux Plumbers. Another major problem: embedded ecosystem. Christian Huitema: 2 outcomes of this BOF; HTTP WG do some form of encryption; privacy reviews of new protocols. What about old ones? Sean: Are you volunteering? CH: Yes, for some. Joe Salowey: One observation, often when we have cases that think they're using authenticated encryption, they're not, because of how they configure or implement things. Supports the case for having opportunistic encryption. Jim Fenton (via jabber): one of the problems with authenticated encryption that doesn't touch user is - how handle auth problems? how to handle cert expiration? Joe Hildebrand: It is William Allen Simpson (jabber): Those can also interfere with (ok fine ... paste from jabber... i missed it...)## William Allen Simpson (jabber): Photuris (circa 1995) we had an entire section dedidicated to Privacy Protection David Black: We do have some opportunistic encryption for IPv6. Here to +1 for all those talking about opportunistic encyrption, but be careful. if you get it wrong you move to a risk of MITM attacks. Jon Peterson: we made bets about what intermediaries needed to do; we were wrong, but we were successful because we didn't block them -- SIP. Does opportunistic encryption block helpful intermediaries and interfere with adoption/success? Sam Hartman: Favor opportunistic encryption. I want to be out of the frying pan of passive attacks and into the fire of active attacks. Want attackers to have to insert themselves as intermediaries. [rather have disclosed intermediaries than stealth ones] We have success with encrypt everywhere when either you don't have an option or your client will do it by default. Opportunistic not in the sense of opportunistic over authenticated, but plaintext password over opportunistic beats plaintext password over nothing. Improve security, don't sacrifice usability. If turning on encryption means mail and web stops working, I'd be upset. Perhaps revise some advice in BCPs to perhaps capture some of what's said here. Interesting work, to stay focused and make rapid progress. stephen: concrete suggestions? DNS confidentiality? Tim Chown: Homenet has noted the tradeoff between security and zero conf. Homenet can take a fresh look at what we do with IPv6 in the home, perhaps define some different architectures. PHB: Remember digicash? Toll road system in Holland. Catch you with license plate recognition next to the anonymous cash collector. When we design things, set of metrics to tell whether am helping by adding security controls, or whetehr just pushing the balloon down one place and it comes up another. Brian Smith: There is alot that we can do that isn't DNSsec that we can do to improve security. Also wants to agree with those . Arguments for opportunistic encryption is that its too hard to do authenticated encryption. We need to organize into an implementers forum where we can talk about some of those usability programs. Sponsor open source software to improve usability. Stephen: You can call it crap encryption if you want. Wes Hardaker: Disagree with several people regarding DNSsec comments. But I think we often don't come up with good documentation - protocols that have clear specifications tend to have better security. I'm often tempted to write a "User Considerations" section about how an end user will use the technology securely (not saying we want to add those sections, but good mental exercise). privacy usability that engages users, improved and new algorithms Keith Moore: 3 concrete things. 1. User interface -- we can do much better than we are; make it easier for people to get real certs; 2. give users tools for getting their DNS zones signed, get universal registrar support for DNSSEC. 3. deprecate the idea that you can trust your local DNS to validate DNSSEC. William Allen Simpson (via Jabber) Dan York: we need to make our protocols as secure as possible, but we also need to think about how these things will get deployed Cullen Jennings - we need to be realistic about the limitations of this. All of the calling data in the US was delivered. How much would it cost to MITM all those. Not much. Why can't we do authenticated. We need better detection. Want to make it harder for the bad guys and easier for the good guys. Certificates on the user interface. Stephen Farrell: Are you suggesting that we might want a protocol to spot that you are the victim of an attack? Cullen Jennings - Detect that all of the certificates somewhere have been replaced or compromised. Making the cost of getting caught doing this lower. Goal not to "be secure" but to make it detectable when you're not Ralph Droms - Heard about not trusting DHCP... It's not really doable to secure DHCP. Take all that other configuration crap back out of DHCP and put it someplace where we can secure it. Eliot Lear - Two reasons - heard actionable items - making TLS certs easier to configure, doing something that is secure out of the box, group that challenged the IAB to address hard problems in this space. Audit of crypto use in our protocols (willing to help, need someone to lead it) James Woodyatt - RFC6092 IPsec allowed inbound through v6 firewalls. http://tools.ietf.org/html/rfc6092 IT is good to use IPSec because it allows us to move servers and peer services out from the core, thus helping with target dispersal. Rohan Mahy: Usability of security is critical. If you work with implementers, talk with them about the importance of making security easy to turn on. Scott Brim: PERPASS next steps (will send mail to the perpass list) ==================================================================== 1. Threat Model, pretty mature, last call after IETF 89 Brian Trammel: Will put a message out in the next couple of days on where we should go with the threat model draft. 2. Privacy BCP, start from Alissa Cooper's draft, where should the discussion happen Scott: Where to put opportunistic encryption? privacy BCP? Alissa: dunno Sam: Update BCP 61? Russ Housley: must explain what Opportunistic Encryption is/means EKR: Is there some hidden consensus that draft-cooper was the right thing to do? Derek: How do we know that implementors are going to do this? We should be talking to implementors Derek Atkins: How do we make sure implementers actually do what we write up here? Alissa Cooper: There is another piece of the draft that talks about data minimization EKR: There is a document how to configure TLS, but not how to use it in other protocols. If you're looking for the latter, you need somebody to write it. Wes Hardaker: If you don't know who you are talking to, are you really getting privacy. Put this in a separate category. Policy and procedures... we should punt on this More of the list Specific Uses of TLS 3. TLS General BCP, IETF Policy & Don't talk about crypto so much pick th elow hanging fruit use perpass list to talk about these things generally and talk about these things individually with the working groups (scribe needs to revisit this ...) another meeting at IETF89, keep the list going, but don't form a WG [this outline should be filled in by what's sent to the list after] Close ===== Thanks all! more on the list