STRINT breakout, On By Default -- 01 Mar 2014

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)

- DRAFT -

STRINT breakout, On By Default

01 Mar 2014

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output