[Stackevo] Notes from 2017-11-15 Stackevo meeting

Cindy Morgan <cmorgan@amsl.com> Wed, 15 November 2017 05:35 UTC

Return-Path: <cmorgan@amsl.com>
X-Original-To: stackevo@ietfa.amsl.com
Delivered-To: stackevo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77D7127B73 for <stackevo@ietfa.amsl.com>; Tue, 14 Nov 2017 21:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Np1MYMiI89GG for <stackevo@ietfa.amsl.com>; Tue, 14 Nov 2017 21:35:35 -0800 (PST)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B0D1243F6 for <stackevo@iab.org>; Tue, 14 Nov 2017 21:35:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id AC7DB327F5 for <stackevo@iab.org>; Tue, 14 Nov 2017 21:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKj0RtrTtljs for <stackevo@iab.org>; Tue, 14 Nov 2017 21:34:58 -0800 (PST)
Received: from dhcp-884d.meeting.ietf.org (dhcp-884d.meeting.ietf.org [31.133.136.77]) by c8a.amsl.com (Postfix) with ESMTPSA id D7F02327F4 for <stackevo@iab.org>; Tue, 14 Nov 2017 21:34:57 -0800 (PST)
From: Cindy Morgan <cmorgan@amsl.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B21FC08-AA61-400A-A95A-B1E1F045A96B@amsl.com>
Date: Wed, 15 Nov 2017 13:35:32 +0800
To: stackevo@iab.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stackevo/R5p6x44XAeykZTcz7yF28eBbAB4>
Subject: [Stackevo] Notes from 2017-11-15 Stackevo meeting
X-BeenThere: stackevo@iab.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IP Stack Evolution Program Mailing List <stackevo.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo>, <mailto:stackevo-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo/>
List-Post: <mailto:stackevo@iab.org>
List-Help: <mailto:stackevo-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo>, <mailto:stackevo-request@iab.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 05:35:37 -0000

IP Stack Evolution Program
Wed 2017-11-15
Singapore


Present:

Spencer Dawkins
Aaron Falk
Ted Hardie
Lee Howard
Suresh Krishnan
Mirja Kuehelwind
Eliot Lear
Gabriel Montenegro
Cindy Morgan
Erik Nordmark
Dave Thaler
Martin Thomson
Brian Trammell
Suzanne Woolf



1. Determining next steps from the MoET proposal

Brian: There was a workshop proposal we were considering sending up to the IAB, a set of MaRNEW like things for various industries, other people who are affected by the work of the IETF to increase the encryption of the transport part of the stack. In order to get information from them about what they are doing with cleartext and what we're doing with not cleartext, and we threw this over the fence to PrivSec, and it lost its mind. 

Martin: There's a thread

Mirja: The workshop may not attract the right people, and why are we having a closed discussion about what is happening in TLS. 

Eliot: If PATIENT has a BOF--

Brian: DOn't want to rathole on that. What of the goals of that workshop do we think were good, and who of those don't conflict with things currently going on in the IETF. I'm not sure the wider discussion of how to deal with encryption of transport protocols--it's overlapping to the point that I see why there is discussion about having a workshop on that while it's still ongoing in TLS. One thing that might be useful for the community is informing people about (sorry, got distracted by an IM conversation at this point and missed a couple of minutes) .

Martin: What is recoverable as a workshop may be little or nothing, but I certainly think the education and outreach aspects, I don't think having a workshop in private to disseminate this information is the way to do it.

Martin: I like having the conversation in public, and yes all the things we were talking about seem interesting, but QUIC is making me nervous.

Mirja: The thing about having a workshop is to limit the number of people. Maybe allow for remote participation. 2 goals. One is purely editorial, to communicate the standard, and to ask for more input, explain their system.

Eliot: Seems to me that there are several different things going on within in the context of the IAB, QUIC, PATIENT, the draft that Kathleen has been working on; you can scope this down what are my QUIC problem, and you can tell those people to just go there. But maybe what you should answering is what the operational issues are that need to be resolved. I think that's a much more interesting broad topic for the IAB to take on, not to looks for ways to subvert they encryption. When the bankers show up, we're not going to do away with the idea of keys, but there may be something at the end point that they can develop. Where does that work happen? In a RG? Workshop? This is not stuff that is currently chartered, so how do you want to explore that, or do you want to explore it at all? The other aspect is, and who is you? We have this discussion about outreach. The bankers would say they were surprised by this work because they weren't engaged in the IETF processes. People who aren't normally participating in our work, and there is a separate avenue in that. Nervous about crossing the lines in policy circles. It may be something you guys want to take up next year at your retreat, hunt that's a long ways away.

Spencer: When you talked about QUIC, does anyone in this room plan to be at NANOG? Maybe we can talk there. I was there when Geoff Huston was talking about shim6, and they were surprised by that.

Lee: I was asked to do a hot topics talk at RIPE.

Brian: I think wrt QUIC, there is a question if it's for the IAB to be involved, or for the WG. IAB would coordinate who talks to whom. A lot of overlap there, but making sure everyone is aware of who is talking to whom. I think that's a good way to do outreach. One thing raised in the PrivSec thread was does that reach. Going to RIPE and NANOG, does that reach everyone we need to reach, and how do we find out how to get them?

Spencer: Looking under a lamp post, I was in this conversation in 2001-2002 about how to find the enterprise guys. Which bush to look under is a general problem. Don't blow off talking to the people you can find just because you can't find them all.

Martin: I think this aspect of the question is interesting, but the secondary aspect of the workshop is the thing we struggle with. I think we have a strategy here, in broad strokes. We will never reach the people who aren't listening on the channels we broadcast on, but what we are really looking for here is input on practices. I've spoken to the banking folks who came in at length, and they have many use cases for these things they're trying to do. I have a better understanding of that, but not an operational understanding. Having trouble understanding the workshop we would produce. Problem with format and venue. Having workshops as our mechanisms for getting the information is failing us in this case. Not getting any new information and it's really hard to separate real needs from wants.

Mirja: Want to disagree a bit. A workshop isn't the only thing we should do to address this, but it could be a starting point. People will come to a workshop that won't come to an IETF meeting. Even if you have someone who is a problem from a company, you want to talk to the person who has all the technical details, and at a workshop you might have the time to figure out who that is.

Lee: NANOG isn't the place where you find enterprises. Cisco Live or RSA. You reach them by reaching out to the resellers. 

Aaron: I think that's a good point; people are motivated by fear and greed, and pervasive encryption hits those. When I was with the [something] project, we were trying to think about the future of the internet at a time when that was a new thing to be talking about, and one of the things we did was writing editorials for journals and publications that were otherwise not engaged, e.g. IEEE Spectrum. The tactic may be useful to us, if we can come up with an article that's useful for a few different venues, getting information to flow into this community, for the people who will be impacted by pervasive encryption. 

Eliot: This is why I had thought, what vehicles does the IAB have at their disposal for this. RGs can provide a venue without all of the standardization baggage. The IAB is free to create new mechanisms around this.

Martin: The challenge is identifying the form that will give us the return we're looking for.

Eliot: Get out into places like CIO magazine and filter them into the process. The IAB can talk to them privately. There's the bankers, or maybe a healthcare IT event; pick your favorite.

Aaron: This may be an area where ISOC can help.

Mirja: But there is a general point that the IETF should be better in its outreach.

Suresh: I think one way would to be find larger, GSMA, NANOG, RIPE. I think that would be a good start already, and one thing I hear about is people feel threatened to come here. But if we go to them. 

Lee: To some extent, enterprise operators have already organized in response to their feeling of outsiderness. Enterprise data center operators. But saying what other concerns do you have; you guys know your market and how to reach it better than we do.

Eliot: As you're having the dialog, as much as you can, you're looking to take input. Part of this is outreach, getting out to these various forms, and how do you disseminate that internally, in a way that it can be consumed and acted upon. You can track the input in some way. That's an aspect that we should be thinking about as an aspect of this activity.

Brian: The 2-way communication, but primarily broadcast first. The first question is, we're spending a lot of time on QUIC, but there are other examples, and I think having this be a thing the WG do is not the model. Organizing it a foreign office thing, and falls under the IAB. And the second question is, is this a stack evolution thing, and I think it is. In the case of QUIC, the fear is that someone pulls the trigger and you get a deployment graph that looks like ECN.

Martin: I think there are things you could throw to PrivSec.

Gabriel: QUIC versus all the other similar problems, and I think QUIC deserves special attention. If any of this affects the invariance, it may be too late. If there's any chance of getting those validated.

Brian: That is an interesting and depressing point. But I meant do we need to go to the chairs and say you need to do outreach, and I think the answer is probably no. There's a whole other aspect of the invariance that we need to talk about later anyway.

Eliot: PrivSec vs StackEvo, I think it depends on how it's scoped. We've been focused on the impact of encryption in this discussion. Could take a longer view of how to approach wider industry, alert them to the activities of the IETF. That may sound like an ocean to boil, but maybe we just boil the pond. Other things like that. Take one and start and set your sights on that level of activity. I think this is an all-IAB conversation.

Lee: Yes, and maybe with Mat an Olaf in the room. Cross-Program coordination.

Dave: Question about how the process worked in the past. There was the User Services Area in the past--anything we can learn from what they did, or is it a disjoint problem?

Brian: I think it's a disjoint problem because the whole business model has changed. 

Aaron: Yes, current problem is about changing existing services.

Ted: I work with a bunch of the user services people, and I think there are 2 pieces to what they did. Some on how to bring up a service that serves your community. How to set up other network services. There was also a piece of it about the norms, the first anti-spam stuff came out of user services. There is also some groups that are very different from where ISOC even has gone. I don't think they have the right connections, either. There is a baseline question of if we're going toe pun up a major outreach effort to a community we don't know at all, is that really a good thing for StackEvo to take on, or would this be better for ISOC to start and bring to us when more is known.

Mirja: I don't know that ISOC has the right technical expertise.

Ted: They do have stuff.

Eliot: I think ISOC does have a bit of a gap in this area, between the business community and the broader networking community, but it feels to me like this is the time for that gap to close. 

Brian: I think I'm hearing that the IETF has an outreach problem that needs to be corrected. This is not a thing for Stackevo to do on its own. ISOC has resources here that may be brought to bear. I'm a bit skeptical that they can do that in a useful tie scale. I think to the extent that we engage ISOC to do something about this, we say to the IAB we considered this workshop, and what came out of it is we tell the IAB to ask ISOC to do the thing.

Ted: Yes, and we need to describe the audience we want them to reach out to.

Brian: And need to make sure the message out is right, and gets channeled out into the IETF in a way that can be used. 

Mirja: Want to disagree with something you said earlier

Brian: WRT the way we've done it before, having focused workshops of 30 people in each of these communities will have a scaling problem.

Mirja: I think it's still useful.

Brian: Next obvious candidate would be the bankers, but that would piss off the IETF community.

Ted: We continue to have conversations with the bankers, but I think there is a problem that it looks like the IAB is going to go aside and solve this problem for them. 

Eliot: Put it in a context beyond TLS

Ted: If we could do that in some useful way, but we got pretty clear feedback from PrivSec that if we stick our oar in now it would not be welcome.

Brian: Next step is to kick it up to the IAB.

Martin: Have you extracted the information you wanted from this discussion?

Mirja: I still think a workshop would be useful, but I do understand.

Brian: If there is community that is close enough to this issue that we could do it without raising a red flag--

Eliot: There are probably some things that could be done to ameliorate the issues that are not standards-related. Maybe IAB provides some assistance there. 

Mirja: As long as they don't see a large number of QUIC connections they will happily ignore it

Several: Too late

Eliot: But if [something] endpoint

Brian: There is--I got accosted on the way to the restroom by the bankers. I had a conversation on Sunday with Nalini's group of people, and the bit of info I got out of that was, here is the set of things that are politically untenable, etc., and one thing I hadn't thought of before is one of the drivers for them is they have a certain equipment replacement cycle, and they also have regulatory input from above that say you must have X by X date, and they have a fear they may not be able to remain compliant. 

Lee: Now it's a regulatory outreach, and need to make sure they understand.

Ted: What you actually heard is we don't want to spend money but we still want to get the benefit of the new technology. These guys are using a procurement cycle that they manage and a regulatory threat that hasn't happened, and they are using that to slow this up.

Eliot: The issues are real; there are certain regulatory controls that mean they need access to clear text for certain things. My other experience is that they are willing to spend money over time. This is where the IAB needs to be thinking a couple of years down the line. If we understand your problem we may be able to restate it.

Suresh: One of the things that wasn't clear to me from the workshop proposal is how the other side gets to explain their views. The people who want to do something about managing the traffic get to say what they want to say, but it's end users whose interest are against this. Need to know what is on the other side of changing our protools. I want something in the workshop that says what we're doing and why. It would be good to explain the reasoning as to why things are this way.

Aaron: I think this is, in trying to figure out how to engage with the broader world on the impact of changes in the stack, a very specific example would be helpful. Relative to this 3rd rail privsec discussion, has there been a discussion with the bankers, there is a slightly different workshop than the one Mirja conceived, and why don't we focus on this community specifically and try to understand where this is going, and this way we can have an informed discussion about what the bankers want.

Brian: In the current climate the Privsec thing would kill that.

Aaron: They have enormous resources and aren't dumb. There is a lot of clue there and I think we should try to push the wall down.

Mirja: For the TLS discussion, they came in too late.

Aaron: Yes, but this isn't the last time we're going to be here.

Brian: Can we take this to the list. 


2. Tech Plenaries

Brian: The IAB met and was talking what we want to do with future plenaries, and we went all the way down a rabbit hole and a bunch of theory ideas fell out, some of which may be of interest to people in this group. It's relatively Privsec heavy, but wanted you guys to have some visibility into this:

1. Look back on how we responded to Pervasive Monitoring and what's next

2. Emerging threats (you can't trust the network, including data at rest.

3. Advertising surveillance. Corporate surveillance
  - Zeynep Tufeci
  - Maciek Cegelowski
  - LinkedIn Chief Privacy Officer
  - or Google, Apple, etc.

Eliot: Or entrust your data on your local device to attackers as well. Local device as likely to be broken into as anything else.

Brian: Data as an application layer currency, and how the architecture we have relates to that. The other thing you might be more interested in is the consolidation topic

- Consolidation, fate sharing
  - DNS, links, content
  - Start at app layer, but's all the way down the stack
- IOT Security
  - Ross Anderson or Richard Clayton

Brian: If you look at how business is consolidated all the way down the stack. Just wanted to bring it up so maybe we can discuss it on the list, and if we as a program have input on any of it, or if this has impact on what the program could do in terms of brain power to help.

3. Path signals draft

Mirja: What about the path signals draft

Brian: I also have a draft on wire image, also the "what's an endpoint" draft. Action item for me schedule a call in January on that.

Mirja: Didn't we decide no to do that.

Martin: And I dropped a draft [draft-thomson-postel-was-wrong, The Harmful Consequences of the Robustness Principle (I think?)].