W3C

STRINT: Strengthening the Internet Against Pervasive Monitoring
Minutes from Day 2

01 March 2014, see Workshop homepage

See also:

Attendees

Present
See attendees list
Chairs
Stephen Farrell, Hannes Tschofenig, Rigo Wenning
Scribes
Joe Hall, Wendy Seltzer

Contents


for remotes: the room is still quite unsettled

Opportunistic Encryption

we're starting

Farrell: we'll discuss breakouts at the end of this session

Mark Nottingham: I've been asked to intro opportunistic encryption (OE)

… 7 papers submitted on OE or OA

… (summarizes 07, 12, 27, 32, 40, 66, 46)

… Mark Nottingham's is 12, won't discuss much

… 40 deep-dive on OE… not as relevant for a high-level discussion

… 66 good survey of how OE is already used (IPSec, VOIP, NAT, TLS)

… starts to collect relevant terminology… very important to know what we mean clearly when we say OE

… Mark Nottingham was saying "optimistic" originally [laughs]

… 07, 27 discuss what "most people" seem to mean by OE

… tries to understand the risks and benefits of OE

… 07, 27 are good places to start in Mark Nottingham's opinion

… 32 proposes tcpcrypt as a low-cost way of getting OE in the stack

… first paper that separates encryption from auth

… 46 very similar. proposes a secure password store that does not allow the passwords to go out, but used for auth… combined with PAKE

… related things besides these papers

… Mark Nottingham is about to get all HTTPBis on us all

… TLS for HTTP URIs… not sure if it will be authenticated or not just yet

… lots of concerns about what happens when we allow OE

… opportunity cost: what would we miss out by focusing on OE

… folks in the WG submitted a draft talking about an "explicit proxy"

… allows a HTTP proxy that can view content

… Brad Hill from ebay pointed out this goes from two states of security (HTTP/S) to three (Auth or not)

… lot of dependence on unauth connections

… captive portals, virus scanning, policy enforcement, optimization

<sftcd> did Mark actually say pervasive monitoring at all yet?

… TLS MITM is becoming more common

… some suggested discussion points

… terminology. lets' not use "OE" because it causes confusion

… auth vs. anonymous

… fail-safe vs. fail-silent

… (argument ensues about terminology point)

… 2. ratholes to avoid

… specific tech/solns

… speculation on UI/UX

… (it's very important but not for us to talk meaningfully)

… not the right people in the room

… 3. Questions

<DThaler> but we have a breakout session on it

… is protecting against PM worth the risks?

… confusing users, encouraging relatively trivial attacks

… is the use of encryption without auth appropriate?

<wseltzer> [the breakout could be about recoginizing the importance of UX/UI, not designing the interfaces right here]

… is failing encryption silently appropriate?

… are either appropriate for new protocols

… are there alternate ways to overcome deploument issues of "full" encryption?

… finally, what other work is impliated by ubiq-encrypt?

Steve Bellovin: let the games begin!

Dave Crocker: would like to challenge a premise that was put forward twice

… about getting confused for having more states for security

… the assumption is with HTTPS that we don't already have a lot of confusion

… users don't undersand HTTPS

… we should stop using the word security… means too much and too little

Larry Masinter: there's a gap b/w protecting against PM...

… does OE help at all?

Farrell: enc does help!

Larry: not clear to me.

… not clear to the vulnerable populations… mainly concerned about phishing or use of private info.

… since this doesn't protect against active attacks

<wseltzer> [even so, that doesn't mean we shouldn't protect the other parts of the population]

… interferes with anonymizers

Max Pritkin: start with terminology

… when we talk about fail-safe, that's not right…

… it's about do we succeed at all in getting encryption

Danezis: there are more states in the world than auth/unauth

… having after-the-fact evidence of MITM is very valuable

… we should rephrase this whole auth/noauth debate into what kind of evidence do you have that you're speaking to the right person?

… not just a binary thing… much more nuanced

Alissa Cooper: cute setup!

… user confusion is an issue but we can't talk about it?

… very important as this problem is conceptualized too much about what will be exposed to users

… no reason that OE can't be hidden entirely from users

(lots of hear hears!)

Daniel Kahn Gilmor: was going to say that as one point...

… confusion is not possible to talk about without some UI discussion

… there are existing mechanisms that expose things like this… OTR is an example

<dka> +1 to usability being a vital topic here.

… also, the other axis… auth/anonymous… should be auth/no auth

Mark Nottingham: to be clear: not suggesting terminology that should exist past 10:30a GMT today

Peter Resnick: want to reenforce that we really want to have no user exposing of the details at all

… if they are seeing it, it's a mistake

… to Larry's point, does not believe for a minute that this is not helpful in some way

… claim is that this doesn't allow anonymizers to work is rubbish

… now you fail in cleartext

… would much rather have underlying encryption that helps users not be in the clear

Kenny Patterson: speaking on behalf of cryptography community (apologizes for that)...

… OE has a very specific meaning in crypto community

… very different from what we're talking about here

… have no idea what to call it

Philipp Hallam-Baker: thinks that the term fail-silent may be confusing...

… wants "succeed-silent"

… wants there to be an IETF rule that there can be no "Do not talk about the UI" from henceforth

… we already have OE… it's called Domain-validated certs without checking OCSP

… all browsers do this for the sake of shaving ms off of latency

<Ben Laurie> PHB is so right about succeed-silent

… some folks are determined to make us secure only with low latency

Steve Kent: with regard to use of pseudonymous creds, we do need to be careful

… given the confusion with UI, we shouldn't assume [something]

… things that encryption by default is not always a good thing, in net

… the use of battery on mobile devices should be part of the discussion

Steve Bellovin: half of people have spoken that UI is important

(asks for a show of hands… rules that the overwhelming sense of the room is that it is important)

Russ: many years ago, Steve Bellovin and Russ wrote a draft about automated key management

… need a similar statement where if you have an environment that supports encryption, it should be on by default

Rigo: want to insist that we should decouple encryption and auth

… rigo's paper talks about how [something] is totally broken in auth across all protocols

… wants a cognitive scientist to weigh in

EKR: finds this discussion unmoored from reality

… at the HTTP interim in Zurich we talked about this

… encryption tied to an auth cred, although not authenticated encryption

<Ted Hardie> One question that seems to be missed here: if the goal is to raise the cost to the attacker, does the inclusion of authentication increase those costs? The answer seems to me be yes, since it makes the cost of active attack much higher.

… when it came down to what we really wanted to do… we foundered

… some problems:

… 1. on side there was concern that network environments are important

… on the other side there were people that do not want encryption not tied to identity

… when we provisionally agreed to do this, trying to do it in HTTP was very difficult

… due to the interaction model and what servers can assume

… huge gap between "that'd be nice" and how to get there

<Ben Laurie> Ted Hardie: this is true, but its not always an available option

Mark Nottingham: doesn't think the discussion foundered

… ruled out the absolutish perspectives

… and are doing some testing

… it's TBD

<wseltzer> Steve Bellovin: We haven't foundered, we're becalmed

Orit Levin: encryption helps with not only PM but a lot of other things

<Ted Hardie> Ben Laurie: I agree, but if you are persuaded by the idea, then the question may be how to narrow the number of cases where it is not an available option and be transparent on the cases where it still is not.

… while we're talking about OE and auth/noauth… how can we talk about it when we don't know what auth or noauth is?

… there is a zoo of things in there

… what do we mean by auth vs. noauth?

Dan Appelquist: about usability

… when engineers talk about users, they mix usability, UI, UX, etc.

… they mix them all up

… what we're talking about here is "user considerations" maybe

… said well yesterday with "making it safe for users to buy stuff online"

… it's about what we want them to understand about security and auth

<Ben Laurie> Ted Hardie: right, so that's why PAKEs and OS-level password stores are important: often I already have a password-authenticated relationship with the other end - we can leverage that up to authenticated channels

Dan again: dangerous to say that x protocol doesn't have a user

… for email, the user is the person reading the email

<Ted Hardie> Ben Laurie: agreed

<Ben Laurie> btw, "authenticated channel" vs "authenticated encryption" might fix the cryptographer confusion problem

… in IoT there are users connected by IoT

Pete Resnick: with psuedonymous the assumption is that there is no encryption at the auth level

… it's for the later step when you know what the connection is that you can name it something

Wendy Seltzer: speaks in favor of incremental improvements

<rigo> wseltzer: wants incremental improvements

… can we recognize that encryption in the middle doesn't solve all problems but raises costs for the attacker

… don't want this incremental to block further ones that might do an even better job

… but because it doesn't solve all our problems, that's not a good excuse to not do it

Pat McManus: spent the past 6 months deep in this for HTTP

… unauth for HTTP URIs has a few very attractive properties and a few unattractive ones

… the biggest pro is that it's a drop-in replacement

… incentives have to be nontrivial to do things that are not so easy

… making this plug-and-play is crucial

… distinction between auth/unauth is not a binary one

… pinning is an example of a stepping stone

… has a FF build that does OE and alternate services

… will tweet out a link if you'd like to play

… neither Chrome nor Firefox will ship HTTP2 in an unencrypted fashion

… may be forced to compete on cleartext HTTP2 protocol

Melinda Shore: with encrypting in the core...

… on problem with UI, is that applications don't always know their security state

… middlebox issues are getting short shrift

… IETF/W3C are a bit disavantaged by not having network operators in the hizzy

… they're a big deal.

Eliot Lear: need to refine our threat model for middleboxes and OE

… if there are specific actions that we should take, please state them.

Steve Bellovin: need to talk about the "trust model" of a middlebox environment

Ted Hardie: what's the user expectation when a TLS setup is interrupted...

… one of the parties that doesn't know that is happening is the server

… there can be parties that are not aware that they may not be talking to who they want to be talking to

… one other point: for this threat model, what is it that accomplishes raising costs to attackers?

… agrees with Wendy that we want to think incremental

… there are a whole series of steps (e.g., TOFU) that go even further than just turning on enc

… not getting caught is a bit part of the attacker considerations here

… want to rais the attacker's costs as much as possible

… will force more targeted surveillance/attacks

Leslie Daigle: wants to come back to Dan A.'s point about how users feel...

… worked for Verisign when it did certs and cared about auth email

… how the user feels is not something we can do about with network/software engineering

… we look at this unauth enc from what we can achieve and can we win with it

… if we do anything that changes the user's state of mind… rathole.

Steve Kent: it's not anon or pseudon enc, but keying...

… it's the key mgmt that gets us into this situation

… anonymous should be viewed in an accurate fashion…

we're not asserting an identity so that you can't infer one

… the problem with CAs/certs is that a pseudonymous auth and attack are not clearly distinguishable

Daniel Kahn-Gilmor: of the folks taling about UI, everyone is talking about end user

… there are other users… e.g., sysadmins

… however we do this, the sysadmin will feel like they've done enough

Alfredo: would like to raise a point for integrity...

… he cares much more about integrity than surveillance

… blocking an active attacker is very important for integrity

… the OE schemes proposed are not enough to get strong integrity protections

Kai Engert: doesn't like OE

… thinks it should be called "blurring"

… any encryption should use some sort of auth

… we focus largely on the CA model

… we should start to intro alternative forms of auth

… what about submitting a key to a public block

<Ted Hardie> I think he means "locker", not block

<Ted Hardie> But I may misunderstand

… email-validated self-signed certs are not a bad idea

<Ben Laurie> he said public log

<Ben Laurie> like in CT

<Ted Hardie> Ben Laurie: thanks for the clarification

… encryption is only encryption if you've coupled it with some sort of auth

ah

… user feedback that is really secure needs 2FA

Hannes Tschofenig: in IETF there are folks that hope that some types of encryption aren't deployed...

<grothoff> s/???/Kai Engert/

… some companies are selling boxes and wouldn't be happy with [encrypt everywhere]

Philipp Hallam-Baker: if we assume the adversary is disclosur-adverse… we don't need to validate creds before we complete transaction

… if we can detect active attack subsequently, that's an important attacker consideration

… what about checking only in, e.g., 1% of cases, we can likely deter an adversary from an active attack

… as they wouldn't know if they're going to be detected

Max Pritkin: we need to think more about the sysadmin experience

… these are ways of offloading security from the end user to the sysadmin, that might help

Linus Nordberg: I think the auth/enc separation is very valuable for us

Steve Bellovin closes layering discussion for a bit later

RLB: notion of TOFU has been raised...

… wants to inject operational reality

… everyone has run into an SSH server where the keys have changed

… need some way of managing changes in keys for key continuity

… we have a pinning draft that has matured in websec

… not a lot of interest in deployment

… there are risks in mismanaging pins and accidentally shut yourself off the internet

… there are real deployment concerns here

Steve Bellovin wants to focus discussion in a few areas:

… layering, separating auth from enc

… can't separate them cleanly

Hannes Tschofenig: are we talking about handshake? or what?

Steve Bellovin: is hearing a lot of people saying let's separate how we do encryption with who is at the other end

… do people think this is the right way to go? show of hands.

(large but not overwhelming consensus… dispute on numbers)

Stephen Farrell: Russ and Cullen disagreed

Hannes says we do this now… people say that TLS doesn't do this

Mark Nottingham: this has implications for UI

(room groans)

Stephen Farrell: maybe "we should not be tightly binding methods for end point authentication with how we do encryption"

(show of hands)

Eliot lear: I'd like to see a discussion written down about it

(hands had a lot of agreement with Farrell's statement"

EKR: someone give me an example!

Steve Bellovin: unauth DHE to start the crypto and then you sign it later
... on to comprehension issue

… what will people understand and how will this affect their behavior?

… does it matter?

Stephen Farrell: CMS requires a serial number before you can encrypt

<Ben Laurie> other example was CMS requires issuer and serial number

… Steve Bellovin doesn't know if his email server is using STARTTLS with any given recipient

Peter Eckersley: one thing from Chrome team… can't do this, won't do this because people won't do real HTTPS

Steve Bellovin: we don't tell the users, we just do it

(rabble rabble rabble)

Mark Nottingham: this is the admin experience

Orit: it's not about the end-user or the sysadmin

… we need to make clear among ourselves what we're talking about

Farrell: folks clearly will write a terminology RFC

Steve Bellovin: another point that came up: who are the trusted parties/devices?

… who is going to assert/vouch for identities

Lear: this is an important question… session later

Steve Bellovin: finally, the cost of these issues is important

… CPU, battery, comprehension costs

Dave Crocker: the list you have of things we need to work on is great.

… like that when we talk about actors involved, need to include users, sysadmins and us.

… what about goals? What is the "this" that we're trying to accomplish

Steve Bellovin: talked yesterday about that, didn't want to raise it

Aaron Kaplan: layering and costs are very important points

… think about DNSSEC… good stuff, but big amplication factor in terms of DoS potential

jari: voluntary adoption works best in this case

… not forcing anyone to do anything

Jon Peterson: interested in what happens if nobody knows if encryption happens… will this spread to other places

… and what are the costs of that "slippery slope"

… you will have huge sizes and latencies eventually

<Ben Laurie> already happens with ECC, right? Ethernet has a checksum, so does IP, so does TLS...

Steve Rogers: this can be difficult on a mobile network

… especially with satellite backhaul

<grothoff> Ben Laurie: you forgot TCP...

Linus Nordberg: layres should deal with that

Rogers: just want to acknowledge that these problems exist

… solutions now do things like remove encryption to improve things in restricted environments

Philipp Hallam-Baker: we have a lot of companies with certs...

<Ted Hardie> In an internetworking context, the presence of encryption on a particular path is not a guarantee that the encryption will continue to be present. Using at a layer that is not path dependent is required to retain confidence.

… and they don't turn on SSL except for auth and check-out

… in 1995 encryption was $$$

… it's now cheap but we have remanants of these effects

@@@@@@: are we saying that there are cases when authentication is not desirable?

Steve Bellovin: yes, that is in scope

@@@@@@: what about making auth more ubiquituous?

Steve Bellovin: because it's particularly hard

Dana: if the point is to protect against PM...

… then we clearly want to encrypt as much as possible to avoid examination

Dan Appelquist: an encrypted web is a less-cacheable web

… planes with satellite backhaul, the interplanetary web

Lear: there are entire countries that rely on caching...

… can't ignore it. Let's not dismiss it.

Lear: Madagascar is one

(talking about break-outs)

Wendy: want an IRC channel for each of these

<wseltzer> thanks, JoeHallCDT!

<wseltzer> [breakouts in irc, subject to change: #research, #browser, #onbydefault, #measure, #opportunistic]

<wseltzer> [discussion of breakouts]

<Satoshi> Thinking laterally, Why don't we just get the intel services to quiet down by giving them a copy of the Internet backup?

<wseltzer> scribenick: wseltzer

Metadata

<Ben Laurie> wseltzer: you missed #client from the list of breakouts

Alfredo: What is metadata?

<grothoff> metadata is the interesting data which is used to justify and execute drone strikes

Alfredo: "everything that is not encrypted is metadata"?
... let's start there and get more precise
... additional data added to the encrypted payload, e.g., addressing information
... does identity need to be coupled with recipient address?
... side-channels, info disclosed by nature of the communication

<DThaler> yeah can we please not use #browser (point yesterday was stuart's discussion is not limited to browser). #client is better.

Alfredo: e.g. time, size, pattern

<grothoff> Metadata is now a propaganda term used to change the discourse, adopting the language of the national security agencies means playing according to their rules.

DThaler, sure, amendment accepted. #client instead of #browser

Alfredo: metadata is widely available; encrypted variants are not widely deployed

<JoeHallCDT> isn't that incorrect?

<JoeHallCDT> aren't all consumer OSs not doing MAC-based IPv6

Alfredo: Can we have transparent metadata protection?
... challening for efficient routing.
... With application cooperation?
... i.e., if application indicates sensitive or linkable information

<DThaler> @joe: I don't know about "all" but certainly Windows isn't. And there's work in the IETF trying to either deprecate it or at least not use it by default, to match implementations

Alfredo: exploiting metadata
... browsed content, document flow

<JoeHallCDT> thanks, Alissa has a blog from last year that points to other OSs too: https://www.cdt.org/blogs/alissa-cooper/0706privacy-future-forever

-> http://down.dsg.cs.tcd.ie/strint-slides/s5-1metadata-pironti.pdf Alfredo's slides

<DThaler> see http://tools.ietf.org/wg/6man/draft-ietf-6man-default-iids

<JoeHallCDT> thanks!

Alfredo: Federated communication

Ted_Hardie: Mitigations, a bit less hopeful than solutions

-> http://down.dsg.cs.tcd.ie/strint-slides/s5-2metadata-hardie.pdf Ted's slides

Ted Hardie: Metadata in a flow, from the simple fact two parties are communicating

<DThaler> @Joe: I checked the blog you pointed to and Alissa is talking about enabling privacy addresses. That doesn't mean nodes don't ALSO have mac-derived addresses.

Ted Hardie: mitigations require a confidential channel
... not much use protecting the metadata on plaintext content
... Possible mitigations: aggregation, contraflow, multi-path
... raise the cost of pervasive surveillance
... If you have a tap on aggregate data, you know flow originates from pooling point, but not individual behind it without more expense

<JoeHallCDT> ah, thank you, sir

Ted Hardie: Contraflow. tunnelling forces attacker to do more correlation
... Multipath. e.g. split tunnel VPN
... Design considerations. Make sure your protocol works in the face of these mitigations
... combining mitigations may be better; consider how to avoid mitigation itself triggering scrutiny
... nothing is perfect

Alissa: Questions. Are there any low-hanging fruits?
... Distinction between hiding identity attributes, other information

Achim Klabunde: Terminology point
... metadata is technically data about data, but we're talking about first-class data
... it's unfortunate that we're confounding the terms
... In Europe, the legal system talks about traffic and location data
... It's data about people, of course it's worth protecting.

Spencer Dawkins: It's not always obvious when we've achieved multicast. False diversity if all paths connect over the same fiber
... difficult to know whom you can ask, whom you can trust

George Danezis: I've spent 15 years studying traffic analysis, and recommend that we not re-invent the work of that research community

<DThaler> I think s/multicast/multipath/ in spencer's point

George Danezis: Useful here to discuss the different threats against which we can protect users
... Design protocols not to have fixed bit strings that are unencrypted, that allow easy packet selection for analysis

Cullen Jennings: VPNs are expensive to run, so either you need to pay, or it's incredibly slow
... worried that there's a systematic attack in some places on for-pay VPN service
... so can we tie them to other services that are more painful to turn off

Eliot Lear: Who's the "you" in "if you have the data, you have the metadata"?
... different between a trusted aggregator and an attacker

Larry Masinter: Useful to distinguish explicit data from observed data

NickDoty: Low-hanging fruit, data-minimization isn't easy
... we might need to do the slow haul through protocols, to ask about each what data we can hide
... which attackers can we foil? e.g. in fingerprinting

Brian Trammell: Agree with both Nick and George
... much harder to fix timing observation than constant bit-strings
... timing is result of good engineering, for bandwidth and latency minimization
... if you want to change timing, you'll need to increase bandwidth and latency
... Split the two kinds of metadata

<vonlynX> that's why i couldnt join this irc for an entire day... it DISALLOWS TLS!

vonlynX, sorry, we've raised the question with W3C systems

George Danezis: envelope information vs side-channels, perhaps

Peter Eckersley: Can we get a write-up of the worst offenders, e.g. worst bit-strings, so we have a target for fixes

George Danezis: Happy to try

Harry Halpin: Traffic analysis is scary. Not everything has the latency constraints of HTTP.
... e.g. work on email

Steve Kent: Avoid the term metadata
... traffic analysis: externally visible characteristics of communication once you've applied encryption

<Ben Laurie> right, strong anonymity _requires_ high latency

<Ben Laurie> or at least, not low latency

Steve Kent: what's visible is a function of at what layer you've applied the encryption

<vonlynX> btw, nice how naturally w3c/ietf uses irc today... i remember the pains it took to convince ietf to publish "informational" rfcs on irc at a time when it was considered child play stuff

Steve Kent: Distinction makes threat-model consideration clearer

Eric Rescorla: There are opportunities for stripping some fat, explicit strings
... I'm skeptical that we can reduce traffic analysis
... and that we can avoid identifying the seekers of greater protection from traffic analysis

Ted: It's true we've spent a lot of time on performance engineering, but where we've wanted confidential channels, we've been willing to spend bandwidth and latency on it
... so we should consider that tradeoff here
... We should be worried about impacting users in a way that makes them want to turn confidentiality off
... But consider that confidentiality requires both payload and traffic obfuscation
... That's a first-order engineering problem.

Linus Nordberg: Security. @@ [scribe missed]
... Anonymity loves company. Sometimes we'll need to force people to opt in.

Harry Halpin: There are large communities who would want to opt-in to greater security/confidentiality.

Alissa Cooper: It's one question to say, "can we do something better for everyone," and another to ask "can we make solutions for those who want them."

Spencer: People who think PM matters may not be the same people who have to pay, right now.
... we're usually opt-in

Daniel Kahn-Gilmor: Crypto community has consensus that all crypto operations need to be constant-time

<hhalpin> In particular, there are protocols where resistance to traffic analysis will be virtually impossible (HTTP/Web browsing due to its bursty nature), but there's *lots* of protocols (particularly server-side) in e-mail, chat, and even VOIP where this is likely possible but parameters and options for sysadmins are unknown/do not exist.

Daniel Kahn-Gilmor: there, we're willing to incur overheads

Steve Kent: Concern/objection to all incurring expense to protect some users.

<hhalpin> We should allow people who want to take on the overhead an ability to take that overhead on.

<hhalpin> Right now with current protocols that is hard.

<hhalpin> Part of it is a lack of research, which is beyond standardization.

<hhalpin> However, there are some protocols (SMTP comes to mind) where this is low-hanging fruit.

Kathleen Moriarty: Previously, split tunneling for performance, VPN for security; Interesting now to bring them together
... Leverage the expertise of the diverse set of experts we have here

Hannes Tschofenig: Action items, I've heard from George that we should look for what identifying strings can be stripped.

Alissa Cooper: It would be good to have that journey informed by experience.
... When someone wants to add an identifier, they argue "so much else is exposed, I should be able to add this user-identifier."
... If you want to strip other strings, you'll need counter-argument to that.
... maybe PM-thinking helps, but it's an uphill battle.

<wendyg> triangulation of data might be answer to argument needed - tiny bits that match up and together expose a great deal. every time remove a bit makes it a little harder/

Stephen Farrell: Engage people with expertise, but if they come up with solutions the implementers don't care about...

Leslie Daigle: Not ready to be a strong proponent of aggregation or obfuscation, but also not ready to call them non-starters
... You never know when you'll need protection, so don't assume it's limited to helping a few

Mark Donnely: Re overhead, perhaps we can leverage existing privacy modes of Web browsers
... standardize the metadata-hiding functions and encourage browsers to implement in their protected-mode

Nick Doty: Tragedy of the commons re: "I'm just adding one more identifier"; that's why it's useful to have coordinating bodies
... so W3C's Privacy Interest Group is trying to look across new protocols, entire ecosystem, to develop minimization that works
... So IETF, W3C, talk to us about systemic privacy and security reviewing.

Alissa Cooper: we're having a meeting Monday

Phil Zimmerman: For a performance burden that's a small penalty, it's worth doing for everyone
... that argument was once made against TLS, now we're pushing it everywhere
... AES is now part of Intel's instruction-set
... We can justify some incremental penalty in the interest of protecting everyone
... even if only a small fraction regards it as critical to staying alive in an oppressive regime

Daniel Kahn-Gilmor: We need to fix all the leaks, not point elsewhere to explain why we're not fixing our protocols.
... SNI, fix both TLS AND DNS leaks

<Ben Laurie> in general, I hate the argument that we should not fix X because Y is also broken

Eliot Lear: To PZ and Leslie, saying we can pay a penalty, who's "we"?
... @@missed

<hhalpin> BTW, making sure "protected mode" actually makes sense and is an intersting possibility of future standardization if browser vendors have interest.

Alissa Cooper: We have an action item for George,
... I like the idea of looking for an easy minimization opportunity.

Stephen Farrell: It would be even more interesting if implementers and deployers were interested

Ted Hardie: Corner StPeter and the XMPP community

<jphillips> RFC 1149 is suitable for reducing traffic analysis. Perhaps by using anti-radar paint…

Joe Hildebrand: XMPP has yet another series of addresses and metadata
... might be a good playground
... analogy to layer 3 issues, not perfect

Harry Halpin: Email communities

<DThaler> 1149 has good multipath properties. aggregation gets really difficult though.

Harry Halpin: subsets thereof
... activist communities, providing email, specifically

[scribe misses some argumentation]

@@: start from scratch, rather than back-filling existing protocols

Alfredo: XMPP is interesting, because it has a live stream of information

<dougm> In a competitive (price, performance, services, security) un-regulated market - these new security capabilities must win the competition with market sectors that matter.

Alissa Cooper: Some disagreement whether techniques are worth the cost. Ongoing discussion

[Lunch]

<vonlynX> my intervention was, end-to-end/onion routed encryption is essential in the fight against visible transaction data and text-based syntaxes are quite unsuitable for simple band-aid fixes.. also the federation architecture isn't really useful to that aim.. we had discussions on the xmpp standards list and agreed that meta data protection is outside a reasonable scope for xmpp.

<vonlynX> new communication technologies are propping up that achieve this goal already, people just have to use other software. it is low hanging fruit to improve those programs and protocols used in them. we keep a list of such technologies at secushare.org/comparison

<kodonog> I will

Deployment

-> http://down.dsg.cs.tcd.ie/strint-slides/s6-deploy.pdf Deployment slides

Eliot Lear: (a few minutes missed...)
... the snoopometer... a view of the attacker
... sneakometer - using intermediaries as a defense mechanism
... aggregation examples
... concentration versus distribution
... spectrum of which service is more secure and more likely to be attacked

... stretch .. who is paying for the the extra paths, how are you paying in terms of quality of service

... key points -

Jan Seedorf One way forward, "interferable secure communications"? Need to look into new technologies the crypto community is developing, makes good guys technically distinguishable from the bad guys

Joe Hildebrand: my paper talked about costs associated with middle boxes breaking services ... middlebox folks don't get the support calls

Eliot Lear: Questions for the room:

... what knobs, what user interface issues, when is PS a good use of resources, can aggregation/concentration actually harm

Philipp Hallam-Baker: this is the deployment session and we aren't worrying about deployment
... set of profiles that say this is how you lock down the network
... enables auditing

Daniel Kahn-Gilmor: push back on the snoopometer slide... it is actually cheaper to collect everything
... you have the pricing backwards

Dave Thaler: economics today means this slide (snoopometer) is not true, it is more about what we would want it to be.

Christian Grothoff: PRISM program also shows that it is very cheap to get everything

Cullen Jennings: differentiate between proxies that are acknowledged/approved of by one end or the other or both
... generally don't cause issues
... another category of ones that are not approved by either end and generally cause a lot of problems

Stephen Farrell: xmpp flag day in may
... are there other communities doing something similar?

<DThaler> http://technet.microsoft.com/en-us/security/advisory/2880823

Spencer Dawkins: do people think that back to back user agents are enough of a special case ]]

<Ted Hardie> Just to point out to Christian on the Prism revelations about Google: http://googleblog.blogspot.nl/2013/06/what.html

<DThaler> "The new policy will no longer allow root certificate authorities to issue X.509 certificates using the SHA-1 hashing algorithm for the purposes of SSL and code signing after January 1, 2016. "

Steve Bellovin: don't much like middleboxes while acknowledging they are sometimes needed
.... design the middlebox friendly version of this
... that won't work with

<grothoff> Ted Hardie: not giving "direct access" just means that there is a proxy involved. So what?

Max Pritikin: that model that says in some situations middleboxes are ok only works when the server end knows its there
... server needs to authenticate the client

George: (missed comment)

<Ted Hardie> +1 to Max's point; if *both* parties to a communication aren't aware of the middlebox, the party which is unaware may send traffic it would not if it weren't aware. So the server may have a policy not to send bank details to middleboxen (an entirely rational choice, if you don't know who is running the MiTM)

EKR: browsers are implicit in this problem, until someone tells me how to make, i have no interest

<Ted Hardie> The Hotspot problem gets better with hotspot 2.0

<DThaler> s/implicit/complicit/ in EKR's comment

<vonlynX> I think middle boxes use cases can be solved differently: Enterprise policy can be implemented on the end devices. If you own the PC, you can bug it. Caching and optimizing mobile data can be solved by migrating users to a push model: With anonymous encrypted distribution trees

<vonlynX> we bring information to each subscriber in an efficient and privacy-preserving way. It also makes it easier to route information around censoring nation state firewalls. Advertising: Whoops, wrong business model. Yet, homomorphic TLS is also an interesting approach.

Peter Resnick: third party that is giving the data and doesn't want to to share, that is the one I don't get

Rigo Wenning: service concentration, need to be smarter by distributing more control in addition to the data

<rigo> Rigo: service concentration: legal access to everything you control and gag order

Jan Seedorf: web traffic acceleration is an example of a use case of interest

<rigo> ... distribution of data not sufficient, also distribution of control

Peter Eckersley: agree with EKR that doing something about corporate MITM attacks against employees
... we should try to do more about hotel networks and such
... need to get rid of captive portal models

<npdoty> pde, do we really want to encourage an arms race of captchas on captive portals?

<Ted Hardie> For those not aware of 802.11u, the Hotspot 2.0 effort changes how a WiFi connectivity event will occur.

Max Pritikin: client authentication lets the server make decisions
... if there is going to be a MITM then we need to design for it

Eliot Lear: What I mean by aggregation is small service versus large service, # of users

Philipp Hallam-Baker: before we try to disable parts of the network we need to understand what these hotel portals are using web content impact on caching

Patrick McManus: horrible architecture that we want to implement, from the points in Joe Hildebrand's paper

Jon Peterson: there wasn't any subset of actions and configurations that middleboxes are willing to be limited to, and they don't mind having CALEA compliance as a result

<vonlynX> Then again, I am being told homomorphic crypto is computationally expensive and from my understanding none of the middle box use cases are compatible to how it operates, unless we reduce privacy (allow middle boxes to detect a request for a certain jpeg etc, which obviously means that the middle box knows which website you are going to). NSFP (not safe for pr0n).

<rigo> oh, we are going back to PICS :) W3C had made POWDER to solve this middlebox problem for the Web

Kathleen Moriarty: can we eliminate malware, the root of the firewall problem, then we can flip this on its head

Dave Crocker: as we make suggestions we should consider the risk of the suggestion. Changing hotel portals is high risk wrt knobs/levers, having an impact here is high risk

Stephen Farrell: I really don;t want a knob that says I don't want to route via country A because it won't be effective

Peter Eckersly: need to revisit the captive portal topic
... dhcp is what it is and we need to build around it

<npdoty> I think captive portals might be more amount branding / advertising / sending traffic than just boilerplate legal agreements

Jan Seedorf: crypto could provide finer grains of control

Barry Leiba: how do you know you are connected to the right captive portal

EKR: every time we try to wall things off from the middle boxes they find a way around it

<npdoty> http 511 code is defined here: http://tools.ietf.org/html/rfc6585

Dave Thaler: maybe we can do something to solve the captive portal

<npdoty> doesn't the 511 status code help us with this problem? the status code tells you that this is a redirect because of captive portal authentication required

<kodonog> (another scribe failure)

Hannes Tschofenig: standards that have a little bit more system nature

[break]

Breakouts

<jphillips> Sounds like Phil brought a rotary telephone while waiting for his Darkphone.

[breakouts in irc: #research, #client, #onbydefault, #measure, #opportunistic]

<freewill> hi everyone

<JoeHallCDT> (in break-out sessions, so not a lot of action here)

<freewill> unfortunately I could not join earlier today

<JoeHallCDT> back on in this one at 16:00 GMT

<freewill> yes just checked the agenda

<JoeHallCDT> might be 15:30, actually

<JoeHallCDT> (we're a bit early)

<freewill> audio down also for you?

freewill, we're still on breakouts/break

<freewill> wseltzer: okay another break

<freewill> thx

<jphillips> There is a lot of cake. We need all the breaks.

<freewill> hehe enjoy

<freewill> beam me up jphillips

<jphillips> Negative, Heisenberg compensator is still not operational.

[returning]

thanks to npdoty and JoeHallCDT for scribing breakouts!

Report back from breakouts

<scribe> scribenick: wseltzer

Cheshire: Good discussion, a few highlights
... Separate cases: Captive portals, Misconfigurations
... Third case, self-signed certs. Browser can tell the difference
... Loose consensus, already a W3C mailing list public-hardfail@w3.org
... Can implementors do something like World IPv6 Day,
... where it's clear that no one browser is "broken," but rather the security of websites is being improved

-> http://www.w3.org/2014/03/01-client-minutes.html Client breakout notes

<Ted Hardie> Was it client-hardfail@w3.org?

<Ted Hardie> for the mailing list at w3c?

<freewill> about encrypted network, is anyone mentioned today that the use of mixing techniques and multi-hop transmission of data must be the norm nowadays for the end user?

Aaron Kaplan: Aggregation/measurement

Ted Hardie, public-hardfail@w3.org

Aaron Kaplan: look at the problem at layer 7 and above
... Testing and measurement; we tried to identify existing groups and interesting tests
... SSLlabs
... how to protect testing data?
... gamification as an approach to spur improvement

Kenny Paterson: We talked about research, not about clean-slate
... Meta challenge in relationship between academics and standards bodies
... Specific action to bring research on linkability to attention of IETF, on Linus
... Specific problems in need of research, non-exhaustive
... CRIME-inspired; interaction of compression and encryption
... Pro-active algorithm deprecation
... Return-oriented crypto; make existence and traffic stealthy

<scribe> ... Continued guidance on algo selection

UNKNOWN_SPEAKER: Efficient Private Information Retrieval (PIR)
... Metrics for obfuscation of code and data
... Specific research in search of applications:
... Limited-interference secure communications
... Format-transforming ncryption
... clean-slate designs using DHTs
... insider threat models

Steve Kent: Opportunistic
... Preferred term "opportunistic keying"
... focus on passive attack model
... Start with DH/ECH for PFS (perfect forward secrecy)
... fall back to plain text, or escalate to authenticated (in parallel?)
... Invisible to users, so they don't think it's replacement for HTTPS
... report to server? "I tried to contact you using opportunistic keying but couldn't reach you"
... Threat model: pervasive monitoring, passive attack
... understand middleboxes, which layers they're operating
... this is not a replacement for HTTPS TLS paradigm, explicitly note that in Security Considerations

Peter Resnick: How does escalate-to-authenticated interact with no UI?

Steve Kent: possibly lock icon

EKR: policy-enforcing middleboxes
... user-experience, if fall-back is slow, how does the experience suffer?

Steve Kent: Possible parallel start for plaintext

@@: Discussed in the client session too; need something below the application to provide a uniform interface

scribe: Might be something to raise in transport-services BOF

Turner: #onbydefault

-> http://www.w3.org/2014/03/01-onbydefault-minutes.html #onbydefault minutes

Sean Turner: More than MTI/on by default = MTU
... Legacy: On by default but off is available

<scribe> ... New protocols: put your best foot forward, if you can't, fall back

UNKNOWN_SPEAKER: need WG guidance

EKR: what would you expect HTTP2 to do?

Sean Turner: New protocols: 1/ where you can do auth encryption, do it
... 2/ if not, do unaut encryption / OE
... 3/ need to indicate up the stack which level was negotiated
... 4/ Need WG guidance!
... Past Security ADs should write such guidance

@@: Also people who understand applications

Ted Hardie: WG guidance is a lovely thing, but WGs are a tiny fraction of those needed for deployment
... We need marketing.
... call upon the IETF chair, who just put his hand up.

Jari Arkko: I wasn't actually volunteering...
... IETF will discuss, through normal process

Sean Turner: Russ volunteered, I volunteered

Stephen Farrell: Thanks!

<npdoty> Eliot volunteering to write; Jari volunteering to blog

Stephen Farrell: Thanks to DKA and Telefonica for hosting! [applause]
... Summary:
... Crypto works, do more, raise the bar; not free but worthwhile
... Data minimization is worthwhile but hard
... Threat model-> RFC
... Opportunistic keying definition and mechanism cookbook -> RFC
... Policy: tech community could do better to explain PM
... UI issues not out of scope
... gamification, bettercrypto.org
... easier security configuration
... can we improve captive portals?
... add a new RFC to BCP 72 re pervasive monitoring; we're not there yet
... but should be working toward it

Juan-Carlos Zuniga: IEEE, this was useful to other communities as well

scribe: we're willing to communicate 802, link-layer, SSIDs

<hhalpin> For discussion of hard fail and browser cert problems, see public-cert-hardfail@w3.org

Cheshire: Thanks Stephen, Hannes, Rigo, and all PC [Applause]

[adjourned]

<hhalpin> just email "subscribe" to public-cert-hardfail-request@w3.org

Summary of Action Items

[End of minutes]

Minutes taken life and later edited. IRC un-edited
$Id: 01-strint-minutes.html,v 1.10 2014-03-06 10:53:01 rigo Exp $