See also:
for remotes: the room is still quite unsettled
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
<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
-> 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]
<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!
<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