W3C

- DRAFT -

STRINT breakout, On By Default

01 Mar 2014

See also: IRC log

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
JoeHallCDT

Contents


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)

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-03-01 16:09:04 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]