See also: IRC log
scribe is me
on by default, more than MTI, something other than certs
Sean: we can have religious wars about things…
… whatever it is in the area that you're going to try to bind a key to a container, just do it
more than certs: don't care, religious argument, moving on
Sean: on by default, and more than MTI are subtely the same thing
Jon P. more than MTI means something about how IETF process works
… on by default is slightly different from there is no encryption optoin
Culen: and a third is "there's no way to turn encryption off"
Sean: we can say MTI is great but we can say MTU
… we can eat our own dogfood and not do kabuki theatre
… turning it off in walled garden doesn't work
Bernard aboba: complaints I've heard about difficulut in using security, is because of lack of implementation experience
… when dev team is not able to do their work, bugs get fixed
Cullen: negotiating security options has been difficult, the fewer options the easier it is
Joe H: we have a history of no adequately dealing with downgrade attacks
Sean: new attacks have made it obvious that we made the wrong choice
Eliot: what is it? encryption
… well there is another room over there that talks about if you have a cert
Andrea: encryption on by default is what we want for sure, auth by default is hard to do by default… what do we use?
Russ: you can't get authentication with nothing
Andrea: why haven't we been using TLS all these years? maybe not the encryption but the cert auth.
… the fact that you can get the encryption without dealing with auth is a good thing
Jon: are we talking about making a process change to IETF specs? or creating guidelines (BCP) that we think you should do x?
… what we don't want, is IPSec, tcpcrypt, TLS, CMS to be MTI and then we have bloat bloat bloat
woman from cisco: if it's on by default, you can still turn it off
Coop: what are the different choices that we're talking about?
… building a protocol and design is different from process
Russ: it's more about will the IESG send it back?
Jon: what process change do we want? because we're not buidling a protocol here.
McManus: layers and switches create a market problem where people deploy them in the easiest way possible.
… if crypto is baked in, that can be a win
Sean: want to get to where it's on, it's secure and the user doesn't have to check
some guy: on by default catches a minor subset of people that don't
… no one has the MTU scope
… so if there is not insecure version defined, that's how we get to MTU at IETF
Dave Crocker: if there is no alternative than MTU than folks will just work around it.
… have to make it more deployable.
Doug Montgomery: can't have utopian view… his enterprise depends on DPI and stuff
… not going to turn it off due to other concerns
Rogers: some of these blocks of companies and countries will swing the pendulum the other way...
and ban businesses if they don't do things this way
Rogers: real world user problem is that there is a lot of crap in the pipe
Cullen: don't see why you need DPI to do these things.
Jon: middleboxes are used to do those things, so...
Dave Crocker: some organizations have made decisions to look at stuff in the middle...
… the other problem is stuff is hard to deploy… maybe we want "easier to implement"
… these are separate topics
Rogers: in WebCrypto… there is a bit of crypto snobbery going on
… my requirement as a developer is to "just be secure"
… but people implement all the options in the wrong manner
… we're also thinking in a browser context
… defacto expectation that in the mobile context SSL is mandatory
Joe H. we're forcing developers to use the same mechanisms as attackers
some guy2: when we get a real IoT, there will be law enforcement pressure to snoop
Joe H.: may be that we force them to use attackers' methods
… anything less than that 1) we have the "IETF is trying to break security" blow up...
… and 2) can't tell if the attacker is good or bad
Melinda: exentsive work on firewall/NAT traversal
… some of which include explicit signaling about ports and such
… no deployment due to burden
… people rely on STUN and TURN and ICE that are in some sense an attack
Jon: doesn't agree at all
Joe H.: is there a problem that we think we can solve if we can't be explicit or implicit?
McManus: passive agressive
Jon: on by def, MTI/MTU…
… we're exploring implications of actually doing this
Dave Crocker: if we just decide to make this requirement then we're done...
… of course, we're not because that's far from implementation reality
some guy3: we want to make downgrade detectable
Joe H.: how to you tell who downgraded?
Rogers: we don't want a warning triangle permanently
Jon: let's talk about IPSec for a minute
rogers: in mobile, we have an error interface to the small cell, then IPSec tunnelling back to the core network
… and you can just grab the keys
Alissa: one protocol at a time is going to come through and the decision has got to get made
Berndard: the distinction is not something that hasn't been on and turning it on...
… if you turn IPSec on in some organizations, all hell will break loose
<drogersuk> air interface encryption, not error interface
… but for clean slate, that's easier as there's no path dependence
<drogersuk> box is a weak point, physical access and so on
some guy4: on by default is only one option
… IPSec on by default, how do we do that?
Lear: at different levels, the answers come out differently
… esp. deployed vs. green field
… the Cooper draft [something]
… from an enterprise security perspective, I ask will that be a conduit for something getting out
… what is the risk of on by default?
Cullen: what is on by default? we're talking about mandatory to use?
Russ: we're trying to figure out for legacy stuff, changing the defaults and for new things, shipping it by default
McManus: is mandatory to offer a twist on this disucssion?
Dave Crocker: this implies and active decision by the user
Mnot: well, it could be that the product choice makes the decision
… this came up in Berlin… can we correct this?
Lear: there are some working groups that are going to on by default and MTU… e.g., SKIM (sp?)
some guy3: great example there… what are you going to do when people implement something different?
Alissa: if you can't interoperate, then you have a problem
some guy3: but interoperability is across organization and firm… that may not be particularly relevant for certain services
Cullen: in the case where it is on by default but the off button exists...
… the discussion will get interesting
Lear: if something can be made mandatory (passes the sniff test), common sense dictates that this is what you do
… on other extreme, if existing toolset doesn't support it, you can't do it
… so we can document things like this and these boundaries
… suppose we're going to mandate client certs for everything
… preposterous, but we can ask how do we get there?
… what engineering-wise can we do to raise those bars
Andrea: wants to bring back the layering discussion
… OBD is great, but must be backwards compatible
… sure client certs would be a disaster… unless it were very very easy to do
… that was what was behind the Session ID in tcpcrypt
… can be used for things like client certs when we get there as a society
Crocker: let's take eliot's point and look at the highest point of departure...
… it would have to have benefits for this meeting, we know it has problems being more widely deployed
… if we can get wider deployment, it's easier to say this needs to be used all the time
(discussion as if that's technical work)
Rogers: a lot of people are using the technical excuse (blame the techies) for bad business decisions
Doug Montgomery: in the extreme that you don't design an insecure mode...
… has to be painless or there will be no deployment
… has to be dead easy, scales and robust or it won't get deployed
Sean: put your money where your mouth is
DM: the things that we're deciding to secure and lock up are used by businesses
… you have to raise the perceived value of security,
… risk is a local perception
… who's risk? enterprise vs. the individual are very different
Jon: pervasive monitoring is an attack. full stop.
Rogers: do we cut off things that might help millions of people
some guy3: it's about context… contexts are different
… but the controls should be there to choose to do things
Jon: always-on-TLS can be always-on with a null cipher!
Andrea: programmers find security to be hard bc of auth… it's hard and far from generic
… if we could decide what is the always-on, we can get far
Cullen: on by default means "secure by default"
Jon: what do you think WebRTC is?
Cullen: hmmm… doesn't have security without IdP
Jon: opportunistic confidentiality is a non-trivial improvement
Cullen: what's going to make a difference?
… what would make a difference is not designing the protocol to not support insecure shit
… is the bottom opportunistic encryption, and auth enc is higher
lear: [missed that]
cullen: there are old protocols and new protocols, two classes
Alissa: other is chance of deployment given a change
… no clear way to figure that out
lear: probably circumstances where the high bar doesn't need to be auth enc… what meets that bar?
… when key mgmt can be solved
… when we know that can't be solved, that's a problem
Russ: maybe what you said is: in the negotation… if you can reach auth enc, do it… if you can't fall back to OE
Bernard: this gaurantees that unauth enc will be used
crocker: tone in the room doesn't seem to be concerned with real world problems in deployment
(going to slow down scribing due to hands that hurt)
some guy3: don't be afraid of authenticated or unauthenticated encryption
Mike P: how do you decide to drop from AE to OE?
(stop scribing, sorry)
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/some guy/Doug Montgomery/ No ScribeNick specified. Guessing ScribeNick: JoeHallCDT Inferring Scribes: JoeHallCDT WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: Alissa Andrea Bernard Berndard Coop Culen DM Eliot Jon Lear McManus Melinda Mnot Russ Sean arobach azet cabo crocker cullen dacheng donnelly drogersuk hildjj jphillips jphillips2 kaie ln5 maxpritikin rogers steffi wendyg wseltzer xnyhps You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 01 Mar 2014 Guessing minutes URL: http://www.w3.org/2014/03/01-onbydefault-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]