Subject: [Stackevo] IAB Workshop on Manageability of Encrypted Traffic (MoET)

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 18 Oct 2017 23:25:21 +0200

Greetings, IAB Privacy and Security Program,

The Stack Evolution Program is working on putting together a small workshop before the IETF in London to work to increase the common ground for communication between the IETF community and operations communities affected by the definition and deployment of encryption further up and down the stack. Think of this as a smaller MaRNEW focused on fostering communication where that could be productive, but not for mobile.

We're seeking comments on the call and on the plan, as well as help with and ideas for invited speakers (first aim in the call).

--

IAB Workshop on Manageability of Encrypted Traffic (MoET)

The increasing deployment of encryption improves end-user privacy, and further secures the Internet as a technology for trustworthy communication and free expression. This is today mostly achieved by the use of HTTPS/TLS on the application layer. Current work on transport protocols also aims to encrypt the headers at lower layers, such as proposed by QUIC and the WebRTC data channel, further securing the leakage of potentially privacy sensitive information, as well as enabling the deployment of these transport protocols in the face of middlebox interference. Ubiquitous encryption, however, comes at the cost of rendering widely deployed passive troubleshooting, performance measurement, and measurement-based network management techniques useless.

This workshop will bring together stakeholders from the network operations and standardization communities together for focused discussion. The workshop has two broad aims:

- Inform and advise network operators and vendors who are not directly involved in the standardization process of the operational implications of these new encrypted protocols, through invited talks by contributors to the standardization of those protocols.

- Collect information to inform the IAB and ongoing standardization efforts in the IETF about currently deployed techniques in network operations and troubleshooting, to determine the effects of the ubiquitous deployment of encryption at different layers on current practice, through invited talks and the presentation of selected position papers by attendees.

This will be a one-day workshop co-located with IETF 101 in London on Saturday, March 17, 2018. The workshop will be run according to Chatham House rules. Attendance is limited and by invitation only; expressions of interest in attending should be sent to <probably [email-masked]> accompanied by a short (two-page) position paper by 19 January 2018.

--

Key to the success of such an effort is getting the right people in the room, ensuring that the focus stays on a two-way exchange of information as opposed to opinion, and finding (possibly miniscule) areas of common ground. For the latter, we'll need some relatively strong moderation; this isn't like the recent Ename workshop where free-roaming thought was necessary to even understand the bounds of the problem space. For the former:

From the IETF community we will invite people to present IETF work while highlighting the impact of encryption at a conceptual (as opposed to deeply technically detailed) level. Mirja recently gave a talk about QUIC at a network monitoring vendor sales event, which might be an example of this type of talk:
https://github.com/mami-project/roadshows/blob/master/IT%20Monitoring%20Konferenz%20Zurich%20-%20Sep%2028%20-%202017/QUIC%20and%20HTTP2.pdf

With the call for position papers we mainly will target people that are not actively participating in the standardization process. To reach these people we have two things in mind: 1) we create a list of people we know and contact them directly. Mirja already has about half a dozen people in mind for that list that work for companies that develop monitoring tools that she's recently talked to about QUIC; 2) we go to operator meetings and announce the workshop there. This would be meetings like RIPE where Brian and Lee have already indicated that they are going; they could take care of this. We'd also want to bring this to APRICOT and NANOG. We're also seeking contacts in the datacenter and enterprise networking communities as well.

--

Cheers,

Brian (for the Stackevo program)

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Oct 2017 17:30:52 -0400

Brian:

One aspect of this dialogue is playing out on the TLS mail list, where former Security ADs are on opposite sides of the issue.  I do not want to bring that discussion here; however, the workshop is likely to stumble over some of the same topics.  When there is a connection from t host on the public Internet to an enterprise datacenter, where is the "end" in the end-to-end model,

Russ

> On Oct 18, 2017, at 5:25 PM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> _______________________________________________
> Privsec-program mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/privsec-program

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Oct 2017 22:40:17 +0100

Hi Russ,

On 18/10/17 22:30, Russ Housley wrote:
> Brian:
> 
> One aspect of this dialogue is playing out on the TLS mail list,
> where former Security ADs are on opposite sides of the issue. 

Personally, I don't think folks' former roles are interesting
in this context. It's a digression in any case.

> I do
> not want to bring that discussion here; however, the workshop is
> likely to stumble over some of the same topics. 

I agree. Though I'd say "stumble" isn't strong enough;-) ISTM
this proposed w/s will end up covering much the same ground
unless that's specifically taken out of the w/s scope.

I don't think having a closed IAB w/s discuss an ongoing item
of public IETF controversy is a good plan at all. OTOH, if
such a w/s is held and doesn't discuss that live topic, then
that'd also seem weird.

To me that seems like an indicator that maybe this is not the
right time for this w/s.

Brian, can you or some others involved in stackevo comment on
that aspect? (I've other comments I'll send separately.)

> When there is a
> connection from t host on the public Internet to an enterprise
> datacenter, where is the "end" in the end-to-end model,
> 

Yep, that's a real question. To answer it though, I believe
one has to move away from TLS. (But then we're back to the TLS
list discussion.)

S.

>> The Stack Evolution Program is working on putting together a small
>> workshop before the IETF in London to work to increase the common
>> ground for communication between the IETF community and operations
>> communities affected by the definition and deployment of encryption
>> further up and down the stack. Think of this as a smaller MaRNEW
>> focused on fostering communication where that could be productive,
>> but not for mobile.
>> 
>> We're seeking comments on the call and on the plan, as well as help
>> with and ideas for invited speakers (first aim in the call).
>> 
>> --
>> 
>> The increasing deployment of encryption improves end-user privacy,
>> and further secures the Internet as a technology for trustworthy
>> communication and free expression. This is today mostly achieved by
>> the use of HTTPS/TLS on the application layer. Current work on
>> transport protocols also aims to encrypt the headers at lower
>> layers, such as proposed by QUIC and the WebRTC data channel,
>> further securing the leakage of potentially privacy sensitive
>> information, as well as enabling the deployment of these transport
>> protocols in the face of middlebox interference. Ubiquitous
>> encryption, however, comes at the cost of rendering widely deployed
>> passive troubleshooting, performance measurement, and
>> measurement-based network management techniques useless.
>> 
>> This workshop will bring together stakeholders from the network
>> operations and standardization communities together for focused
>> discussion. The workshop has two broad aims:
>> 
>> - Inform and advise network operators and vendors who are not
>> directly involved in the standardization process of the operational
>> implications of these new encrypted protocols, through invited
>> talks by contributors to the standardization of those protocols.
>> 
>> - Collect information to inform the IAB and ongoing standardization
>> efforts in the IETF about currently deployed techniques in network
>> operations and troubleshooting, to determine the effects of the
>> ubiquitous deployment of encryption at different layers on current
>> practice, through invited talks and the presentation of selected
>> position papers by attendees.
>> 
>> This will be a one-day workshop co-located with IETF 101 in London
>> on Saturday, March 17, 2018. The workshop will be run according to
>> Chatham House rules. Attendance is limited and by invitation only;
>> expressions of interest in attending should be sent to <probably
>> [email-masked]> accompanied by a short (two-page) position paper by
>> 19 January 2018.
>> 
>> --
>> 
>> Key to the success of such an effort is getting the right people in
>> the room, ensuring that the focus stays on a two-way exchange of
>> information as opposed to opinion, and finding (possibly miniscule)
>> areas of common ground. For the latter, we'll need some relatively
>> strong moderation; this isn't like the recent Ename workshop where
>> free-roaming thought was necessary to even understand the bounds of
>> the problem space. For the former:
>> 
>> From the IETF community we will invite people to present IETF work
>> while highlighting the impact of encryption at a conceptual (as
>> opposed to deeply technically detailed) level. Mirja recently gave
>> a talk about QUIC at a network monitoring vendor sales event, which
>> might be an example of this type of talk: 
With the call for position papers we mainly will target people that are
not actively participating in the standardization process. To reach
these people we have two things in mind: 1) we create a list of people
we know and contact them directly. Mirja already has about half a dozen
people in mind for that list that work for companies that develop
monitoring tools that she's recently talked to about QUIC; 2) we go to
operator meetings and announce the workshop there. This would be
meetings like RIPE where Brian and Lee have already indicated that they
are going; they could take care of this. We'd also want to bring this to
APRICOT and NANOG. We're also seeking contacts in the datacenter and
enterprise networking communities as well.
>> _______________________________________________ Privsec-program
>> mailing list [email-masked] 
> _______________________________________________ Privsec-program
> mailing list [email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Oct 2017 08:56:52 +1100

If this is just an information session with a chance to collect
feedback, I don't see significant risk of running afoul of live
topics.  Particularly if there is good moderation, from people who are
aware of those topics.  I see no value in retreading the same ground,
but if we are able to ensure that information on what is going on
reaches a new audience, that would be good.

The biggest concern here is that we get the same audience we got at
the TLS session.  That would represent - to my mind - a complete
failure.  While we need one or two people in the room who are aware of
that debate, but that would only be so that we can avoid it.

As I have learned, the sorts of things we are doing in the IETF often
come as a surprise to this particular type of audience.  Surprises
here are bad because they tend to elicit stronger reactions than are
warranted.  If the only goal is to smooth out the surprise response, I
think that this is OK.

This is probably a good time to dust off our traffic analysis work.  I
hope to submit a -00 version of an individual draft on that subject
before the meeting.  That might be the substance of my own
contribution here.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Oct 2017 23:00:07 +0100

Other comments:

- I don't get the goal. "Increase the common ground for
communication" seems vague in the extreme. What do the
proponents of this expect to achieve? Why is it needed?
None of those are clear to me.

- I don't get why it's good to have a w/s that ignores the
fact that more crypto, good as that is, does nothing about
the concentration of endpoints (and hence cleartext) at
mega-companies. Encrypting more may even help accelerate
such trends. The call here seems to ignore that. And if one
is concerned with privacy (as the text seems to say) then
surely an IAB w/s would try address that elephant in the
room. (DPRIVE is a fine thing that highlights this as an
issue nicely.)

- I don't get who you want in the room tbh. Who fits the
"not aware of IETF crypto work," "not mobile operators"
and (similar to Russ' comment) "not already involved in
the do|don't-break-TLS debate"? I'm not seeing a relevant
small set of people who'd make this worthwhile. The examples
given (RIPE,APRICOT,Nanog,"data centre") don't seem to me
to fit the disjunction above.

- "Ubiquitous encryption, however, comes at the cost of
rendering widely deployed passive troubleshooting,
performance measurement, and measurement-based network
management techniques useless." That's a badly stated
incorrect statement. There is no "ubiquity" in crypto,
as there are always some fields clear and "useless" is
way overstated. Kathleen and Al's draft has had trouble
getting this kind of text right, I'd suggest that the
results of those discussions be leveraged in any call
text, and to not cause those discussions to be
repeated.

All in all: I think this is a bad idea and do not
support having such a w/s at this time.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Oct 2017 23:09:26 +0100

Hiya,

On 18/10/17 22:56, Martin Thomson wrote:
> topics. 

If not re-doing the TLS topic is a goal, that absolutely has to
be explicit in the CFP. And then the CFP looks dumb IMO. Right
now, the CFP clearly asks to talk about TLS, and maybe even about
breaking TLS.

> Particularly if there is good moderation, from people who are

I'll be interested in answers as to who that new audience might
be. I'm not seeing it anyway.

> failure.  

Right. Not just a w/s fail though. It'd be (rightly seen as)
an IAB fail IMO to have a closed Chatham-house w/s on that
topic in that timeframe. I for one would whine at the plenary
if the IAB sponsored that and didn't clearly rule out the
topic.

> While we need one or two people in the room who are aware of

That goal would be better achieved by sending people to talk
at places where crowds of potentially-surprised folks gather
and not in a small room co-located with an IETF meeting.

> before the meeting.  That might be the substance of my own

Yeah, be great to progress that if we can.

S.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 19 Oct 2017 00:11:28 +0200

> On 18 Oct 2017, at 23:56, Martin Thomson <[email-masked]> wrote:
> 

> that debate, but that would only be so that we can avoid it.

Agree completely.

> warranted.  If the only goal is to smooth out the surprise response, I

One of the bits of feedback we're looking for from the privsec program is where to strike the balance between the "inform and advise" aim -- which, as you say, is first and foremost an exercise in surprise-avoidance -- and the collection aim -- getting additional information about the impacts of standardization decisions in this space. Discussing TLS interception in enterprise networks to for the purpose of content inspection is at this point neither useful for surprise avoidance nor for collecting information about requirements or current practices -- I'm not following the discussion in any detail, but it doesn't seem that the problem is missing information on either side.

> before the meeting.  That might be the substance of my own

That would IMO be very useful.

Cheers,

Brian

> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Oct 2017 15:52:42 -0700

I share some of Stephen's concerns here, but maybe to restate in my own
terms:

- This is phrased as an exercise in information exchange, but I have not
generally
found the problem is that the various participants are substantively
missing information
but that they fundamentally have different priorities. Certainly, that's
been my
experience with the discussion over monitoring in QUIC, and perhaps to a
lesser
extent with TLS 1.3.

- Chatham House rules is concerning here. Many of these topics are live
issues
in WG, and they need to be discussed in an open process. What information is
actually sensitive here, rather than just embarrassing.

As it stands, I think it would be better if this workshop were not held.

-Ekr

On Wed, Oct 18, 2017 at 3:11 PM, Brian Trammell (IETF) <[email-masked]>
wrote:

> One of the bits of feedback we're looking for from the privsec program is
> where to strike the balance between the "inform and advise" aim -- which,
> as you say, is first and foremost an exercise in surprise-avoidance -- and
> the collection aim -- getting additional information about the impacts of
> standardization decisions in this space. Discussing TLS interception in
> enterprise networks to for the purpose of content inspection is at this
> point neither useful for surprise avoidance nor for collecting information
> about requirements or current practices -- I'm not following the discussion
> in any detail, but it doesn't seem that the problem is missing information
> on either side.
>
> workshop before the IETF in London to work to increase the common ground
> for communication between the IETF community and operations communities
> affected by the definition and deployment of encryption further up and down
> the stack. Think of this as a smaller MaRNEW focused on fostering
> communication where that could be productive, but not for mobile.
> >>
> >> The increasing deployment of encryption improves end-user privacy, and
> further secures the Internet as a technology for trustworthy communication
> and free expression. This is today mostly achieved by the use of HTTPS/TLS
> on the application layer. Current work on transport protocols also aims to
> encrypt the headers at lower layers, such as proposed by QUIC and the
> WebRTC data channel, further securing the leakage of potentially privacy
> sensitive information, as well as enabling the deployment of these
> transport protocols in the face of middlebox interference. Ubiquitous
> encryption, however, comes at the cost of rendering widely deployed passive
> troubleshooting, performance measurement, and measurement-based network
> management techniques useless.
> >>
> operations and standardization communities together for focused discussion.
> The workshop has two broad aims:
> >>
> >> - Inform and advise network operators and vendors who are not directly
> involved in the standardization process of the operational implications of
> these new encrypted protocols, through invited talks by contributors to the
> standardization of those protocols.
> >>
> operations and troubleshooting, to determine the effects of the ubiquitous
> deployment of encryption at different layers on current practice, through
> invited talks and the presentation of selected position papers by attendees.
> >>
> >> This will be a one-day workshop co-located with IETF 101 in London on
> Saturday, March 17, 2018. The workshop will be run according to Chatham
> House rules. Attendance is limited and by invitation only; expressions of
> interest in attending should be sent to <probably [email-masked]>
> accompanied by a short (two-page) position paper by 19 January 2018.
> >>
> >> --
> >>
> >> Key to the success of such an effort is getting the right people in the
> room, ensuring that the focus stays on a two-way exchange of information as
> opposed to opinion, and finding (possibly miniscule) areas of common
> ground. For the latter, we'll need some relatively strong moderation; this
> isn't like the recent Ename workshop where free-roaming thought was
> necessary to even understand the bounds of the problem space. For the
> former:
> >>
> while highlighting the impact of encryption at a conceptual (as opposed to
> deeply technically detailed) level. Mirja recently gave a talk about QUIC
> at a network monitoring vendor sales event, which might be an example of
> this type of talk:
> >> https://github.com/mami-project/roadshows/blob/master/
> IT%20Monitoring%20Konferenz%20Zurich%20-%20Sep%2028%20-%
> 202017/QUIC%20and%20HTTP2.pdf
> >>
> not actively participating in the standardization process. To reach these
> people we have two things in mind: 1) we create a list of people we know
> and contact them directly. Mirja already has about half a dozen people in
> mind for that list that work for companies that develop monitoring tools
> that she's recently talked to about QUIC; 2) we go to operator meetings and
> announce the workshop there. This would be meetings like RIPE where Brian
> and Lee have already indicated that they are going; they could take care of
> this. We'd also want to bring this to APRICOT and NANOG. We're also seeking
> contacts in the datacenter and enterprise networking communities as well.
> >>
> >> --
> >>
> >> Cheers,
> >>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 19 Oct 2017 10:34:35 +0200

hi Ekr, Stephen, all,

Thanks for the feedback. A couple of answers and further questions.

> I share some of Stephen's concerns here, but maybe to restate in my own terms:
> 
> - This is phrased as an exercise in information exchange, but I have not generally
> found the problem is that the various participants are substantively missing information
> but that they fundamentally have different priorities. Certainly, that's been my
> experience with the discussion over monitoring in QUIC, and perhaps to a lesser
> extent with TLS 1.3.

This is a good point. When reviewing the proposed call, I wasn't thinking about TLS as in scope at all (see below), rather the class of problems raised by QUIC, DOH, and other efforts that have encryption of formerly exposed "infrastructural metadata" as a goal. You're right that these are also a question of different priorities, which makes it impossible to have objective discussions balancing the risk of overexposure with the utility afforded by that exposure. We're hashing a tiny little corner of that space out in the QUIC RTT DT, where agreement will I think not be sweeping or easy to come to. It'd be nice if it were possible to try and arrive at some first principles for achieving this balance.

> and not in a small room co-located with an IETF meeting.

Also a good point... perhaps a work item for both programs here is to look at how we can more effectively communicate the impacts that decisions being made in the IETF might have on the practices of stakeholders we don't know. It'd be hard to do this "as the IETF", since you necessarily need to be a little speculative as to where the WG process will end up. Liaising out what we're doing and why (working with people to explain the technical logic behind 2804, for example) won't change governments' minds, but other stakeholders might be able to make better decisions with more insight into those arguments we do agree on.

That, in my opinion, would not really fulfill the charge that the IAB took up with its statement on encryption in November 2014 ("...[w]e also acknowledge that many network operations activities today, from traffic management and intrusion detection to spam prevention and policy enforcement, assume access to cleartext payload.  For many of these activities there are no solutions yet, but the IAB will work with those affected to foster development of new approaches for these activities which allow us to move to an Internet where traffic is confidential by default.")... but it's better than nothing, I guess.

> - Chatham House rules is concerning here. Many of these topics are live issues
> in WG, and they need to be discussed in an open process.

Agree fully that having side discussions on topics substantially overlapping in scope with active topics in a WG discussion under other than note well terms is a Bad Idea. I personally considered the specific TLS question so far out of scope for this workshop that I didn't even see that it the call could be interpreted as an invitation to rehash that discussion in a closed room, but given this thread I can see how it could be interpreted that way.

I'll admit to having stopped following the TLS discussion after Prague -- I'd characterize it as you do, not a question of missing information. It's also, as it was phrased when I stopped following it, not really an architectural question (beyond the architecture of the protocol).

In your opinion, is the TLS discussion as it currently stands scoped in such a way that general discussion of architectural approaches to the replacement of cleartext traffic inspection for arbitrary applications (those beyond "cleartext traffic inspection" as an end in itself, which seems to be what static DH is explicitly meant to do) would be in scope there? If so, then yes, let's table the workshop proposal and see if we can get a wider set of people with problems that *can* be scalably solved without exposing cleartext into the room.

> What information is

The aim using of Chatham House rules here is not to pass judgement on the distinction, but to allow participants to make the participation on their own, but *only* in cases where that yields useful information not otherwise available. If we don't think that'll happen, then we shouldn't afford the protection of non-attribution. I'm not yet convinced that this is the case.

Thanks, cheers,

Brian

> On Wed, Oct 18, 2017 at 3:11 PM, Brian Trammell (IETF) <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Oct 2017 11:46:20 +0100

Hiya,

On 19/10/17 09:34, Brian Trammell (IETF) wrote:
>> - This is phrased as an exercise in information exchange, but I
>> have not generally found the problem is that the various
>> participants are substantively missing information but that they
>> fundamentally have different priorities. Certainly, that's been my 
>> experience with the discussion over monitoring in QUIC, and perhaps
>> to a lesser extent with TLS 1.3.
> 
> This is a good point. When reviewing the proposed call, I wasn't
> thinking about TLS as in scope at all (see below), rather the class
> of problems raised by QUIC, DOH, and other efforts that have> encryption of formerly exposed "infrastructural metadata" as a goal.

TBH, I don't see how you can avoid re-hashing the TLS debate
until after at least the TLS WG has disposed of the topic.

> You're right that these are also a question of different priorities,
> which makes it impossible to have objective discussions balancing the
> risk of overexposure with the utility afforded by that exposure.

I agree that wrt TLS surprise is not an issue. I further agree
that people's priorities do feed into their arguments and
conclusions. I absolutely do not agree at all that it is impossible
to discuss the issues objectively. There are many architectural
issues embedded in this discussion, e.g.: Complexity => vuln++;
2-party -> N-party changes; the acceptable imperfections of
forward secrecy etc. (My point in saying the above is to oppose
any tendency to describe this debate as being purely subjective,
or only driven by one's biases, it is not, on either side. In
saying that I fully admit to being biased towards not breaking
TLS, but I consider that an objectively defensible position and
not solely a bias.)

> We're hashing a tiny little corner of that space out in the QUIC RTT
> DT, where agreement will I think not be sweeping or easy to come to.
> It'd be nice if it were possible to try and arrive at some first
> principles for achieving this balance.
> 
>> That goal would be better achieved by sending people to talk at
>> places where crowds of potentially-surprised folks gather and not
>> in a small room co-located with an IETF meeting.
> 
> Also a good point... perhaps a work item for both programs here is to
> look at how we can more effectively communicate the impacts that
> decisions being made in the IETF might have on the practices of
> stakeholders we don't know. It'd be hard to do this "as the IETF",
> since you necessarily need to be a little speculative as to where the
> WG process will end up. Liaising out what we're doing and why
> (working with people to explain the technical logic behind 2804, for
> example) won't change governments' minds, but other stakeholders
> might be able to make better decisions with more insight into those
> arguments we do agree on.

I think the onus there is on IESG and IAB members to get out and
talk about what's up at the IETF. If each AD/IAB member did a
couple of such talks per year that'd be more than one/week on
average. While I was on the IESG some ADs did that kind of thing,
and I'm sure the same is true of some IAB folks, but I guess it
could be more organised and maybe have a bit more co-ordination
as to what topics are worth liasing out at a given moment.

> That, in my opinion, would not really fulfill the charge that the IAB
> took up with its statement on encryption in November 2014 ("...[w]e
> also acknowledge that many network operations activities today, from
> traffic management and intrusion detection to spam prevention and
> policy enforcement, assume access to cleartext payload.  For many of
> these activities there are no solutions yet, but the IAB will work
> with those affected to foster development of new approaches for these
> activities which allow us to move to an Internet where traffic is
> confidential by default.")... but it's better than nothing, I guess.

I wasn't suggesting that liaising out would achieve that. I am
suggesting it'd be more effective than any small w/s for the
specific goal of surprise avoidance. That therefore seems to me
to call into question the idea that the putative w/s ought try
help avoid surprises as a primary justification for holding a w/s.

> 
>> - Chatham House rules is concerning here. Many of these topics are
>> live issues in WG, and they need to be discussed in an open
>> process.
> 
> Agree fully that having side discussions on topics substantially
> overlapping in scope with active topics in a WG discussion under
> other than note well terms is a Bad Idea. I personally considered the
> specific TLS question so far out of scope for this workshop that I
> didn't even see that it the call could be interpreted as an
> invitation to rehash that discussion in a closed room, but given this
> thread I can see how it could be interpreted that way.
> 
> I'll admit to having stopped following the TLS discussion after
> Prague -- I'd characterize it as you do, not a question of missing
> information. It's also, as it was phrased when I stopped following
> it, not really an architectural question (beyond the architecture of
> the protocol).

See above. I'm not sure what the parenthetical means there (it
seems to contradict the clause preceding it:-) but there are
significant architectural issues in the do|don't-break-TLS
argument. (See above for 3.)

And it didn't stop with draft-green, we have another variant
of the same thing that currently needs killing (IMO:-).

> 
> In your opinion, is the TLS discussion as it currently stands scoped
> in such a way that general discussion of architectural approaches to
> the replacement of cleartext traffic inspection for arbitrary
> applications (those beyond "cleartext traffic inspection" as an end
> in itself, which seems to be what static DH is explicitly meant to
> do) would be in scope there? 

Sorry, I don't get the question. Can you re-phrase?

If the re-phrasing ended up as "Can the proposed w/s avoid serious
overlap with the ongoing TLS debate?" then I'd answer "no, that is
not possible."

If it ended up as: "Is it possible to separate the architectural
discussion in general from the TLS WG discussion?" then I'd also
say "no, that's also not possible."

Cheers,
S.

> If so, then yes, let's table the
> workshop proposal and see if we can get a wider set of people with
> problems that *can* be scalably solved without exposing cleartext
> into the room.
> 
>> What information is actually sensitive here, rather than just
>> embarrassing.
> 
> The aim using of Chatham House rules here is not to pass judgement on
> the distinction, but to allow participants to make the participation
> on their own, but *only* in cases where that yields useful
> information not otherwise available. If we don't think that'll
> happen, then we shouldn't afford the protection of non-attribution.
> I'm not yet convinced that this is the case.
> 
> Thanks, cheers,
> 
> Brian
> 
>> As it stands, I think it would be better if this workshop were not
>> held. -Ekr
>> 
>> 
>> 
>> 
>> 
>>> topics.  Particularly if there is good moderation, from people
>>> who are aware of those topics.  I see no value in retreading the
>>> same ground, but if we are able to ensure that information on
>>> what is going on reaches a new audience, that would be good.
>> 
>>> The biggest concern here is that we get the same audience we got
>>> at the TLS session.  That would represent - to my mind - a
>>> complete failure.  While we need one or two people in the room
>>> who are aware of that debate, but that would only be so that we
>>> can avoid it.
>> 
>> Agree completely.
>> 
>>> As I have learned, the sorts of things we are doing in the IETF
>>> often come as a surprise to this particular type of audience.
>>> Surprises here are bad because they tend to elicit stronger
>>> reactions than are warranted.  If the only goal is to smooth out
>>> the surprise response, I think that this is OK.
>> 
>> One of the bits of feedback we're looking for from the privsec
>> program is where to strike the balance between the "inform and
>> advise" aim -- which, as you say, is first and foremost an exercise
>> in surprise-avoidance -- and the collection aim -- getting
>> additional information about the impacts of standardization
>> decisions in this space. Discussing TLS interception in enterprise
>> networks to for the purpose of content inspection is at this point
>> neither useful for surprise avoidance nor for collecting
>> information about requirements or current practices -- I'm not
>> following the discussion in any detail, but it doesn't seem that
>> the problem is missing information on either side.
>> 
>>> This is probably a good time to dust off our traffic analysis
>>> work.  I hope to submit a -00 version of an individual draft on
>>> that subject before the meeting.  That might be the substance of
>>> my own contribution here.
>> 
>>>> The Stack Evolution Program is working on putting together a
>>>> small workshop before the IETF in London to work to increase
>>>> the common ground for communication between the IETF community
>>>> and operations communities affected by the definition and
>>>> deployment of encryption further up and down the stack. Think
>>>> of this as a smaller MaRNEW focused on fostering communication
>>>> where that could be productive, but not for mobile.
>>>> 
>>>> We're seeking comments on the call and on the plan, as well as
>>>> help with and ideas for invited speakers (first aim in the
>>>> call).
>>>> 
>>>> --
>>>> 
>>>> The increasing deployment of encryption improves end-user
>>>> privacy, and further secures the Internet as a technology for
>>>> trustworthy communication and free expression. This is today
>>>> mostly achieved by the use of HTTPS/TLS on the application
>>>> layer. Current work on transport protocols also aims to encrypt
>>>> the headers at lower layers, such as proposed by QUIC and the
>>>> WebRTC data channel, further securing the leakage of
>>>> potentially privacy sensitive information, as well as enabling
>>>> the deployment of these transport protocols in the face of
>>>> middlebox interference. Ubiquitous encryption, however, comes
>>>> at the cost of rendering widely deployed passive
>>>> troubleshooting, performance measurement, and measurement-based
>>>> network management techniques useless.
>>>> 
>>>> directly involved in the standardization process of the
>>>> operational implications of these new encrypted protocols,
>>>> through invited talks by contributors to the standardization of
>>>> those protocols.
>>>> 
>>>> - Collect information to inform the IAB and ongoing
>>>> standardization efforts in the IETF about currently deployed
>>>> techniques in network operations and troubleshooting, to
>>>> determine the effects of the ubiquitous deployment of
>>>> encryption at different layers on current practice, through
>>>> This will be a one-day workshop co-located with IETF 101 in
>>>> London on Saturday, March 17, 2018. The workshop will be run
>>>> according to Chatham House rules. Attendance is limited and by
>>>> invitation only; expressions of interest in attending should be
>>>> sent to <probably [email-masked]> accompanied by a short
>>>> (two-page) position paper by 19 January 2018.
>>>> 
>>>> --
>>>> 
>>>> Key to the success of such an effort is getting the right
>>>> people in the room, ensuring that the focus stays on a two-way
>>>> exchange of information as opposed to opinion, and finding
>>>> (possibly miniscule) areas of common ground. For the latter,
>>>> we'll need some relatively strong moderation; this isn't like
>>>> the recent Ename workshop where free-roaming thought was
>>>> necessary to even understand the bounds of the problem space.
>>>> For the former:
>>>> 
>>>> From the IETF community we will invite people to present IETF
>>>> work while highlighting the impact of encryption at a
>>>> conceptual (as opposed to deeply technically detailed) level.
>>>> Mirja recently gave a talk about QUIC at a network monitoring
>>>> vendor sales event, which might be an example of this type of
>>>> talk: 
>>> _______________________________________________ Stackevo mailing
>>> list [email-masked]

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 19 Oct 2017 12:57:45 +0200

> On 19 Oct 2017, at 12:46, Stephen Farrell <[email-masked]> wrote:
> 

More the second than the first. More precisely, split into three:

"Is the proper venue for broader architectural discussion of the space of tradeoffs between manageability and confidentiality currently the TLS working group?"

"...even in those cases in which there are clear paths forward to meet the claimed requirements without inspection of cleartext application-layer headers and payload?"

"...even in those cases where TLS is not the protocol used to protect confidentiality?"

If the answer to two or three of those is yes -- mind you, I think the answers to the second and third are no -- then yeah, a workshop here would be inappropriate, and we should make sure that all the potentially-sane positions in this space are represented in the TLS discussion.

Cheers, B

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Oct 2017 12:09:03 +0100

Hiya,

> More the second than the first. More precisely, split into three:

Thanks, that helps my little brain in the early morning:-)

> "Is the proper venue for broader architectural discussion of the
> space of tradeoffs between manageability and confidentiality
> currently the TLS working group?"

Not for all of them, no. But it is the proper venue for those
discussions as they affect TLS and is a live discussion in the
WG now. (And a highly controversial one.) And yes, some of
the issues are broad and architectural despite the discussion
being specific to TLS.

> 
> "...even in those cases in which there are clear paths forward to
> meet the claimed requirements without inspection of cleartext
> application-layer headers and payload?"

Part of the discussion in the TLS WG is around debating the
validity and applicability of claims in that space. Some folks
claim that one cannot meet requirements without breaking TLS
(IIUC). Others have claimed that attempting to meet those
requirements by breaking TLS would be illegal in some
jurisdictions. And lots in between.

> "...even in those cases where TLS is not the protocol used to protect

No, that's not been raised in the TLS WG so far as I recall.
(Well, other than comments to the effect that if we MitM TLS,
then that'll impact all other IETF security protocols as they'd
not be able to resist doing similarly.)

But, honestly, I don't see how you can scope a w/s to avoid
the TLS debate, as that's where the pressure is being seen.

Cheers,
S.

> 
> If the answer to two or three of those is yes -- mind you, I think
> the answers to the second and third are no -- then yeah, a workshop
> here would be inappropriate, and we should make sure that all the
> potentially-sane positions in this space are represented in the TLS
> discussion.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Oct 2017 05:44:55 -0700

On Thu, Oct 19, 2017 at 1:34 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> This is a good point. When reviewing the proposed call, I wasn't thinking
> about TLS as in scope at all (see below), rather the class of problems
> raised by QUIC, DOH, and other efforts that have encryption of formerly
> exposed "infrastructural metadata" as a goal. You're right that these are
> also a question of different priorities, which makes it impossible to have
> objective discussions balancing the risk of overexposure with the utility
> afforded by that exposure. We're hashing a tiny little corner of that space
> out in the QUIC RTT DT, where agreement will I think not be sweeping or
> easy to come to. It'd be nice if it were possible to try and arrive at some
> first principles for achieving this balance.\
>

I agree that it would, but I don't see how that could possibly come out of
a semi-private
discussion with this group of stakeholders.

Also, I don't see how TLS can possibly not be in scope given that we're
currently discussing
SNI encryption.

> overlapping in scope with active topics in a WG discussion under other than
> note well terms is a Bad Idea. I personally considered the specific TLS
> question so far out of scope for this workshop that I didn't even see that
> it the call could be interpreted as an invitation to rehash that discussion
> in a closed room, but given this thread I can see how it could be
> interpreted that way.
>

Well, the QUIC, DOH, and SNI discussions are also live issues.

In your opinion, is the TLS discussion as it currently stands scoped in
> such a way that general discussion of architectural approaches to the
> replacement of cleartext traffic inspection for arbitrary applications
> (those beyond "cleartext traffic inspection" as an end in itself, which
> seems to be what static DH is explicitly meant to do) would be in scope
> there?

If so, then yes, let's table the workshop proposal and see if we can get a
> wider set of people with problems that *can* be scalably solved without
> exposing cleartext into the room.
>

I'm not really following here, as you seem here to be assuming that the
amount of encryption is fixed and we are only discussing how to help
operators deal with that, but that has not been the context of *any*
discussion I have been involved in here. To the contrary, everything from
the TLS 1.3 discussion to the QUIC discussion has been about requests that
the endpoints exfiltrate more information.

> The aim using of Chatham House rules here is not to pass judgement on the
> distinction, but to allow participants to make the participation on their
> own, but *only* in cases where that yields useful information not otherwise
> available. If we don't think that'll happen, then we shouldn't afford the
> protection of non-attribution. I'm not yet convinced that this is the case.
>

I think you've got the defaults backwards. The assumption should be
openness.

-Ekr

> > One of the bits of feedback we're looking for from the privsec program
> is where to strike the balance between the "inform and advise" aim --
> which, as you say, is first and foremost an exercise in surprise-avoidance
> -- and the collection aim -- getting additional information about the
> impacts of standardization decisions in this space. Discussing TLS
> interception in enterprise networks to for the purpose of content
> inspection is at this point neither useful for surprise avoidance nor for
> collecting information about requirements or current practices -- I'm not
> following the discussion in any detail, but it doesn't seem that the
> problem is missing information on either side.
> >
> communication and free expression. This is today mostly achieved by the use
> of HTTPS/TLS on the application layer. Current work on transport protocols
> also aims to encrypt the headers at lower layers, such as proposed by QUIC
> and the WebRTC data channel, further securing the leakage of potentially
> privacy sensitive information, as well as enabling the deployment of these
> implications of these new encrypted protocols, through invited talks by
> contributors to the standardization of those protocols.
> > >>
> information as opposed to opinion, and finding (possibly miniscule) areas
> of common ground. For the latter, we'll need some relatively strong
> moderation; this isn't like the recent Ename workshop where free-roaming
> thought was necessary to even understand the bounds of the problem space.
> For the former:
> > >>
> > >> With the call for position papers we mainly will target people that
> are not actively participating in the standardization process. To reach
> these people we have two things in mind: 1) we create a list of people we
> know and contact them directly. Mirja already has about half a dozen people
> in mind for that list that work for companies that develop monitoring tools

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 19 Oct 2017 15:19:35 +0200

> On 19 Oct 2017, at 14:44, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Thu, Oct 19, 2017 at 1:34 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> hi Ekr, Stephen, all,
> 
>> This is a good point. When reviewing the proposed call, I wasn't thinking about TLS as in scope at all (see below), rather the class of problems raised by QUIC, DOH, and other efforts that have encryption of formerly exposed "infrastructural metadata" as a goal. You're right that these are also a question of different priorities, which makes it impossible to have objective discussions balancing the risk of overexposure with the utility afforded by that exposure. We're hashing a tiny little corner of that space out in the QUIC RTT DT, where agreement will I think not be sweeping or easy to come to. It'd be nice if it were possible to try and arrive at some first principles for achieving this balance.\
> 
> I agree that it would, but I don't see how that could possibly come out of a semi-private
> Also, I don't see how TLS can possibly not be in scope given that we're currently discussing
> SNI encryption.

hm, point; for TLS here I read "TLS + static DH and similar", which is *specifically* focused on *content exposure*, which is more specifically what I think should be out of scope. SNI encryption does raise architectural questions, and questions of the tradeoff between confidentiality and flexibility in server design.

> Well, the QUIC, DOH, and SNI discussions are also live issues.

...and these discussions which are currently being held on the details across a range of working groups. I take that as a signal that there are wider, higher-level issues to discuss in a forum not bound to a specific working group.

>> In your opinion, is the TLS discussion as it currently stands scoped in such a way that general discussion of architectural approaches to the replacement of cleartext traffic inspection for arbitrary applications (those beyond "cleartext traffic inspection" as an end in itself, which seems to be what static DH is explicitly meant to do) would be in scope there?
>> If so, then yes, let's table the workshop proposal and see if we can get a wider set of people with problems that *can* be scalably solved without exposing cleartext into the room.
>> 
> I'm not really following here, as you seem here to be assuming that the amount of encryption is fixed and we are only discussing how to help operators deal with that, but that has not been the context of *any* discussion I have been involved in here. To the contrary, everything from the TLS 1.3 discussion to the QUIC discussion has been about requests that the endpoints exfiltrate more information.

My (personal) assumption is that the amount of encryption is fixed (although I find that framing of the situation a little puzzling... certainly encryption is a means to a set of security goals, not an end in itself? But perhaps it is useful shorthand.) Approaches like the-space-of-proposals-descibed-by-mcTLS are off the table, because they're basically addressing content exposure.

As I hope is obvious from my record of participation on this subject over the past half-decade, I tend to think that approaches that signal network-interesting but application-semantic-unlinked information -- the latency spin bit proposed QUIC being pretty close to the most distilled form possible of this -- are the only workable way to reconcile these issues for passive measurement, if that's a capability we are interested in keeping. I'm not sure that I'd characterize that as "requests for exfiltration", though, but I think that's just because we're working from different estimates of the risk involved with each specific selectively exposed information element -- exfiltration, to me, implies exposing information with application-layer semantics or from which application-layer semantics can be inferred.

> I think you've got the defaults backwards. The assumption should be openness.

Wasn't presuming a default. But I'll take this as a vote for "will be held under IETF Note Well rules, with the possibility to apply Chatham House rules for sessions or subsessions within which sensitive information may be shared" in any revised workshop CFP that comes out of this. This worked well for CARIS, IMO.

Thanks, cheers,

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Oct 2017 14:27:17 +0100

Hi Brian,

> Wasn't presuming a default. But I'll take this as a vote for "will be
> held under IETF Note Well rules, with the possibility to apply
> Chatham House rules for sessions or subsessions within which
> sensitive information may be shared" in any revised workshop CFP that
> comes out of this. This worked well for CARIS, IMO.

To be clear: I don't think the IAB having a small
number of invited participants on topics that so
significantly overlap with ongoing and controversial
WG discussions is open enough.

For me, it's not mostly an IETF Note Well issue,
it's mostly a timing issue. The proposed w/s would
be like holding a bunch of co-located WG interims
on controversial live topics but without everyone
interested being allowed to be in the room.

S.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 19 Oct 2017 15:33:15 +0200

hi Stephen,

> On 19 Oct 2017, at 15:27, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Brian,
> 

No worries, that was clear enough. :)

> interested being allowed to be in the room.

Thanks for explaining. I agree fully that "a bunch of co-located WG interims on controversial live topics but without everyone interested being allowed to be in the room" is A Bad Idea, but I'm not sure I agree with your assessment that the space of possible workshops here has the properties you assume.

Cheers,

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Oct 2017 14:38:19 +0100

On 19/10/17 14:33, Brian Trammell (IETF) wrote:
> I'm not sure I agree with your assessment that the space of possible
> workshops here has the properties you assume.
Well, that is a LARGE space:-)

I'm happy to chat more (by email or im whatever) but
honestly can't really see how one might disentangle
a w/s CFP from those WG topics that'd cause the "Bad
Idea" problem.

S.

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 19 Oct 2017 16:05:32 +0200

Hi all,

I think this is a good moment to level up the discussion bit again. I 
originally proposed this workshop which we then discussed for a while in the 
stackevo programm where there were several people that indicated that they 
know about people outside the IETF that would be interested in such a workshop.

I recently went to a (non-research) conference on monitoring to talk about 
quic where most other presentations where product presentation offrom eople 
selling monitoring boxes or software system that would do monitoring on 
various layer (from classic netflow to application monitoring at the host but 
also including TLS interception). I got a lot of positive feedback about my 
talk because those people were very interested in quic but they don't like to 
and simply will not read drafts or RFCs. Their business is monitoring, so if 
they want to know something they look at the traffic. Just telling these 
people that the quic they see right now will by far not be the same quic 
they'll see in future was an important message.

So I agree it would be helpful if more people would go to these kind of 
meetings, reach out to these communities, and channel the messages we have in 
an appropriate way. However, I did this because this meeting was in Zürich 
and I could just step by for a few hours. I usually just don't have time for 
that. And I'm afraid this might not scale. So my question would be, how can 
we get the messages we want to communicate in a understandable to the right 
audience if writing RFC is not the best choice. I think general communication 
actions like writing blog posts and such things may actually help as well but 
we also might need a better plan than that. I'm not saying that holding one 
workshop with quite a limited number of participants solves the problem but 
maybe we get a better idea from talking to that sample set about what we 
should do. I personally e.g. am hoping every concretely that this workshop 
could produce a set of tutorial-style slide material that then could be 
reused at various venues.

The other thing I'm hoping to get to with this workshop is that I can ask 
questions to those people that build and deploy these boxes. For the specific 
topic of monitoring there is a huge number of small vendors that are big 
enough to have impact as quite some large companies world-wide use their 
systems for monitoring their enterprise networks but their are too small to 
contribute actively in the IETF. That leaves us in a situation where we have 
many systems that often have very similar goals (detect problems) but use 
very different approaches. So for me it was very interesting to learn more 
about these systems and ask questions about some of the details things they do.

For me this workshop is really about exchanging information about the status 
quo and not to engineer any new solutions to potential future problems. 
Especially when problems are specific to a certain protocol these discussions 
of course should happen in the respective working group. I though that was 
very clear from the call, but we definitely can add another paragraph to make 
more clear what this workshop is not about. I would be really interested in 
having such a workshop and I know already a bunch of people who I had no 
chance to convince that they should come to an IETF meeting but who would 
also be interested in this kind of venue. As the call also states this 
workshop is mostly target at those people that are currently not coming to 
the IETF (for, I guess, various reasons) and not for people that are already 
at the IETF and are already involved in these on-going discussions in the 
existing working groups. If there is a concern that we will not be able to 
get these people in the room, then that is a valid concern but I'm personally 
convince of the opposite and I would at least like to give it a try.

So while I do take note of everybody's position in the previous discussion 
and I even share some of the concerns, this discussion did not provide much 
input for me to think that this workshop could not be useful (of course under 
the precondition that we are able to get the right people in the room and 
have a good moderation).

Mirja

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Oct 2017 07:09:30 -0700

On Thu, Oct 19, 2017 at 6:19 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> thinking about TLS as in scope at all (see below), rather the class of
> problems raised by QUIC, DOH, and other efforts that have encryption of
> formerly exposed "infrastructural metadata" as a goal. You're right that
> these are also a question of different priorities, which makes it
> impossible to have objective discussions balancing the risk of overexposure
> with the utility afforded by that exposure. We're hashing a tiny little
> corner of that space out in the QUIC RTT DT, where agreement will I think
> not be sweeping or easy to come to. It'd be nice if it were possible to try
> and arrive at some first principles for achieving this balance.\
> >
> hm, point; for TLS here I read "TLS + static DH and similar", which is
> *specifically* focused on *content exposure*, which is more specifically
> what I think should be out of scope. SNI encryption does raise
> architectural questions, and questions of the tradeoff between
> confidentiality and flexibility in server design.
>

Hmm... I don't think this is about server design. We get input from the
server people. The question is about entities which are not affiliated with
the server.

> live issues
> ...and these discussions which are currently being held on the details
> across a range of working groups. I take that as a signal that there are
> wider, higher-level issues to discuss in a forum not bound to a specific
> working group.
>

Perhaps, but every single discussion I've been in has quickly devolved into
the specifics of the live issues.

> >> If so, then yes, let's table the workshop proposal and see if we can
> get a wider set of people with problems that *can* be scalably solved
> without exposing cleartext into the room.
> >>
> My (personal) assumption is that the amount of encryption is fixed
> (although I find that framing of the situation a little puzzling...
> certainly encryption is a means to a set of security goals, not an end in
> itself? But perhaps it is useful shorthand.) Approaches like
> the-space-of-proposals-descibed-by-mcTLS are off the table, because
> they're basically addressing content exposure.
>
> As I hope is obvious from my record of participation on this subject over
> the past half-decade, I tend to think that approaches that signal
> network-interesting but application-semantic-unlinked information -- the
> latency spin bit proposed QUIC being pretty close to the most distilled
> form possible of this -- are the only workable way to reconcile these
> issues for passive measurement, if that's a capability we are interested in
> keeping. I'm not sure that I'd characterize that as "requests for
> exfiltration", though, but I think that's just because we're working from
> different estimates of the risk involved with each specific selectively
> exposed information element -- exfiltration, to me, implies exposing
> information with application-layer semantics or from which
> application-layer semantics can be inferred.
>

The spin bit is a great example here: it's information which would
otherwise be concealed which we are being asked to expose to the network
for no immediate benefit to the endpoints. How is that not exfiltration?

> the distinction, but to allow participants to make the participation on
> their own, but *only* in cases where that yields useful information not
> otherwise available. If we don't think that'll happen, then we shouldn't
> afford the protection of non-attribution. I'm not yet convinced that this
> is the case.
> >
> Wasn't presuming a default. But I'll take this as a vote for "will be held
> under IETF Note Well rules, with the possibility to apply Chatham House
> rules for sessions or subsessions within which sensitive information may be
> shared" in any revised workshop CFP that comes out of this. This worked
> well for CARIS, IMO.
>

I think it's more than that. I think there should be a strong presumption
of openness absent some sort of overwhelming reason to do otherwise.

-Ekr

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 19 Oct 2017 16:44:05 +0200

> On 19 Oct 2017, at 16:09, Eric Rescorla <[email-masked]> wrote:
> 
>> On Thu, Oct 19, 2017 at 6:19 AM, Brian Trammell (IETF) <[email-masked]> wrote:
>> 
> Hmm... I don't think this is about server design.

Sorry, you're right, this is not an issue with single servers: "content delivery service design"

> We get input from the server people. The question is about entities which are not affiliated with the server.

For every information element currently in cleartext which future protocol developments will conceal, there is the intended use by the endpoint (in the SNI use case, "which cert to present"), ancillary but benign uses by not-endpoints (use of SNI as a load-balancing hint), and misuse (anything else)... or am I missing something with SNI?

> Perhaps, but every single discussion I've been in has quickly devolved into the specifics of the live issues.

Maybe I am being uncharacteristically optimistic that it is possible to frame a discussion and moderate it that it will not so devolve. This thread is probably proof of your point, though.

> The spin bit is a great example here: it's information which would otherwise be concealed which we are being asked to expose to the network for no immediate benefit to the endpoints. How is that not exfiltration?

In the case of end-to-end RTT signaling, because its concealment would be a side-effect of content and header protection, but it's probably not useful to continue down this path, since the definition of exfiltration is the very point of disagreement we're having, and I have a general rule that applies to arguing with people online about anything other than Scrabble: when you feel the need to go and look something up in a dictionary, it's time to stop. :)

> I think it's more than that. I think there should be a strong presumption of openness absent some sort of overwhelming reason to do otherwise.

Noted, and I agree. We'll have to evaluate the tradeoff in the quality and quantity of input we will getunder Note Well rules from those communities which do not value openness as much.

Thanks, cheers,

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Oct 2017 07:49:13 -0700

On Thu, Oct 19, 2017 at 7:44 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> have not generally
> > We get input from the server people. The question is about entities
> which are not affiliated with the server.
>
> For every information element currently in cleartext which future protocol
> developments will conceal, there is the intended use by the endpoint (in
> the SNI use case, "which cert to present"), ancillary but benign uses by
> not-endpoints (use of SNI as a load-balancing hint), and misuse (anything
> else)... or am I missing something with SNI?

Well, I suppose if your position is that any use of the SNI by someone not
affiliated with one of the endpoints is "misuse", then maybe not, but
that's precisely the point of contention: there are entities in the network
who want to use the SNI for monitoring and therefore are upset that we are
looking at encrypting SNI. So it's precisely the tension I thought
motivated this workshop.

-Ekr

> >> >> The aim using of Chatham House rules here is not to pass judgement
> on the distinction, but to allow participants to make the participation on
> held under IETF Note Well rules, with the possibility to apply Chatham
> House rules for sessions or subsessions within which sensitive information
> may be shared" in any revised workshop CFP that comes out of this. This
> worked well for CARIS, IMO.
> >
> > I think it's more than that. I think there should be a strong
> presumption of openness absent some sort of overwhelming reason to do
> otherwise.
>
> Noted, and I agree. We'll have to evaluate the tradeoff in the quality and
> quantity of input we will getunder Note Well rules from those communities
> which do not value openness as much.
>
> Thanks, cheers,
>
> Brian
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Oct 2017 17:20:08 +0200

Hi,

On this one point:

> I think you've got the defaults backwards. The assumption should be

We already have an existence proof of some of the participants in the
TLS working group not being able to share what they do.  They may STILL
not want to share even WITH Chatham House rules.  My suggestion is to
ask prospective participants about this and then make a decision.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Oct 2017 08:22:07 -0700

On Thu, Oct 19, 2017 at 8:20 AM, Eliot Lear <[email-masked]> wrote:

> the
> TLS working group not being able to share what they do.

I'm not sure that's true. It's true that they asked for a private
discussion, but I've
met with them privately and what they had to say there is not really
significantly
different than what they said in public.

-Ekr

They may STILL

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 19 Oct 2017 11:34:40 -0400

> different than what they said in public.

And I clarified their use case in a blog and they agreed with the
clarification.  The blog gets at Stephen's point about getting the
word out.

I did also see Mirja's response including information about a recent
talk she gave.  I submitted a panel proposal to the RSA Conference (I
get no preference as a Dell EMC employee) on this topic.  It's the
largest security conference as far as I am aware.  DKG, US Bank, and
Tim Polk are proposed panelists.  I have no idea if we'll be selected,
but I also agree getting the word out is important.  We will talk
about TLS, but I was careful to include related topics in the overview
for the broader conversation.

In terms of this particular workshop, I am not sure I see the value in
a small w/s.  Would Al or I be invited from our survey work?  I do
think broader and open discussion is important.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Oct 2017 13:27:26 -0700

On Thu, Oct 19, 2017 at 7:05 AM, Mirja Kühlewind <
[email-masked]> wrote:

> <snip>

>  I'm not saying that holding one workshop with quite a limited number of
> participants solves the problem but maybe we get a better idea from talking
> to that sample set about what we should do. I personally e.g. am hoping
> every concretely that this workshop could produce a set of tutorial-style
> slide material that then could be reused at various venues.
>
> Is there a chance that some subset of us could sit down in Singapore and
produce such a tutorial slide set that others could then review?  A blog
post with a pointer to that would be a good outcome.

> questions to those people that build and deploy these boxes. For the
> specific topic of monitoring there is a huge number of small vendors that
> are big enough to have impact as quite some large companies world-wide use
> their systems for monitoring their enterprise networks but their are too
> small to contribute actively in the IETF. That leaves us in a situation
> where we have many systems that often have very similar goals (detect
> problems) but use very different approaches. So for me it was very
> interesting to learn more about these systems and ask questions about some
> of the details things they do.
>

This tends to suggest that the right timing for this, if we do hold it,
might be alongside an existing conference or meeting around that topic.
Sadly, I think NANOG, RIPE/APRICOT may not be right, but I'm not really
sure where else that would be.  Any clue from this group?

>
> For me this workshop is really about exchanging information about the
> status quo and not to engineer any new solutions to potential future
> problems. Especially when problems are specific to a certain protocol these
> discussions of course should happen in the respective working group. I
> though that was very clear from the call, but we definitely can add another
> paragraph to make more clear what this workshop is not about. I would be
> really interested in having such a workshop and I know already a bunch of
> people who I had no chance to convince that they should come to an IETF
> meeting but who would also be interested in this kind of venue. As the call
> also states this workshop is mostly target at those people that are
> currently not coming to the IETF (for, I guess, various reasons) and not
> for people that are already at the IETF and are already involved in these
> on-going discussions in the existing working groups. If there is a concern
> that we will not be able to get these people in the room, then that is a
> valid concern but I'm personally convince of the opposite and I would at
> least like to give it a try.
>
> input for me to think that this workshop could not be useful (of course
> under the precondition that we are able to get the right people in the room
> and have a good moderation).
>
> Mirja
>
>
>
I think any IAB workshop starts from an architectural question.  The
baseline question here is very similar to the MARNEW question, but no
longer limited to radio networks:  what data about flows does the network
need to function (and perform well)?

The answer we've gotten so far is "much less than we're collecting and
likely much less than we thought".  It was particularly interesting in the
MARNEW context that the box builders and deployers didn't necessarily
agree.  Quite a few of the deployment folks would happily have foregone the
complex and expensive TCP boxes if they could be sure that the performance
wouldn't degrade.  But it's really not clear that the answer is "none",
even if we eliminate all the inspection cases that are actually about
content.

If a workshop isn't the right way to get that data, and it certainly may
not be, how do we get it?  Or do we believe it is the wrong question?

Ted

---

From: Lucy Lynch <[email-masked]>
Date: Thu, 19 Oct 2017 21:37:50 +0000 (UTC)

On Thu, 19 Oct 2017, Ted Hardie wrote:

> Sadly, I think NANOG, RIPE/APRICOT may not be right,

Why do you think this? Is it the event size? Past experience? Bad fit?
The recent NANOG 71 agenda and participants list has some overlap of
interests stated above re: building and deploying boxes and current 
monitoring practitioners along with a ton of CDN related topics.

https://pc.nanog.org/static/published/meetings/NANOG71/agenda.html
http://www.cvent.com/events/nanog-71/attendees-15-4f71b2f3181e49c1ab199f5d5d405bb8.aspx

same with RIPE. Both already include some IETF cross participation. Do you 
think these folk won't engage? The NANOG hackathon slot might be 
interesting if there was something hands on to test/collect or measure.

- Lucy

> but I'm not really sure where else that would be.  Any clue from this 
> group?
>
>
>>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Oct 2017 15:05:21 -0700

> interesting if there was something hands on to test/collect or measure.
If they turn out to be the right ones, that's a bonus.  My impression came
from two things:  the upthread mention of enterprise networks, whose
operators don't tend to do *NOG (unless that has changed a lot), and the
breadth of topics that those meetings  try to get through in a meeting.  I
think the CARIS workshop as well as it did because the FIRST conference it
was joined to was all about incident response, rather than being a more
general security conference.

I'm not sure whether there is anything equally well tailored to this
question, hence the "not really sure where else that would be" that
followed this.

Ted

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Oct 2017 12:25:36 +1100

I would suggest that we at least defer this discussion until we better
understand the goal and audience.

I've been thinking some more about this and I think that Ted is right
about audience.  The relatively short notice probably doesn't help
with getting the right group in Singapore either.  That is, unless you
really do want to host the TLS argument.

On Fri, Oct 20, 2017 at 7:27 AM, Ted Hardie <[email-masked]> wrote:
> Sadly, I think NANOG, RIPE/APRICOT may not be right, but I'm not really sure
> where else that would be.  Any clue from this group?

Mark spoke about QUIC and this general topic at AUSNOG recently and
can probably report on what he learned about talking to that sort of
group.

> baseline question here is very similar to the MARNEW question, but no longer
> limited to radio networks:  what data about flows does the network need to
> function (and perform well)?
...
> If a workshop isn't the right way to get that data, and it certainly may not
> be, how do we get it?  Or do we believe it is the wrong question?

We've asked this and similar questions many times, in many formats,
and we get the same sorts of responses every time: some people don't
care and others care a whole lot.  I'm starting to wonder if the
question isn't specific enough.  And maybe that asking these questions
won't get us the information we need no matter how we ask.  We seem to
be seeing a lot of proxy battles in this space and the cross talk is
impossible to correct for.

This is worse when "managing a network" means diagnosing the services
that use that network to one group, ensuring that malware doesn't
enter to another, or that confidential information doesn't leak out to
another, and none of those match with what I think Brian and Mirja has
in mind here (where network means network and not also the things that
attach to it).

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Oct 2017 12:46:31 +1100

--
Mark Nottingham   https://www.mnot.net/

> On 23 Oct 2017, at 12:25 pm, Martin Thomson <[email-masked]> wrote:
> 

Yes; I spoke not only about the changes in QUIC (and the spin bit, etc.), but also TLS1.3, DOH, etc., and asked folks to give me feedback (either during the talk or after) as to whether it would cause them any pain as network operators. 

"Them" self-identified as a mix of ISP, transit and enterprise network operators; about 250 people in the room.

*No one* indicated that it would cause them any problems.

It was suggested that if we wanted more data, a survey to AUSNOG members could easily be run; it's useful in that members can be segregated by role, so you can filter out vendors and others who don't actually run networks.

Likewise, the other NOGs would be good sources of data if properly handled, I think. NZNOG expressed interest in a similar talk (but alas, it overlaps with the planned QUIC interim in Melbourne).

As an aside - I think it'd also be interesting to get folks like CAIDA / KC Claffy involved in the discussion.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 23 Oct 2017 10:26:33 +0400

> On 23 Oct 2017, at 05:25, Martin Thomson <[email-masked]> wrote:
> 

by "this discussion" I presume you mean the proposed MoET workshop -- however, I'd like to suggest that we try to continue "this discussion" that we're having on the lists, perhaps during the stackevo slot in Singapore (Wednesday lunchtime), because it seems like we might actually be moving in the direction of getting somewhere maybe.

> can probably report on what he learned about talking to that sort of

It occurs to me that a talk like Mark's and Mirja's would be useful to propose to RIPE -- the RIPE plenary in Dubai is _very_ measurement and monitoring heavy, both passive and active, so a discussion of how that impacts network visibility (in the non-euphemistic sense) would be welcome here. The next RIPE is in Marseille in May, at which point it will be a matter of informing the ops community what has happened in the WG.

My lightning talk asking the passive measurability question (https://github.com/mami-project/roadshows/blob/master/ripe-75-dubai/quic-rtt-ripe.pdf) is on the agenda today after all, will report back both here and on the RTT DT list on the response.

> question isn't specific enough.

I've long suspected it isn't, but don't know how to ask a more specific question that isn't tied to a specific protocol. Maybe I should get over that and give up on a grand unified theory of explicit an intentional information exposure in protocol wire image design and just start asking extremely specific questions.

On that point, we (Mirja and I) should submit an -01 of the manageability draft shortly that is reorganized in terms of "what you can derive from passive observation of QUIC headers" that may be a first step toward creating a list of said specific questions.

>  And maybe that asking these questions

Anecdata: I was discussing QUIC with a network engineer at a hosting provider and he was very anti. Paraphrasing: "I'm starting to get pressure from my customers to offer QUIC on the server side, because it sounds faster, but I'm terrified of turning it on because I don't know how to filter UDP garbage after I do. We filter inbound UDP, and if I look udp/443 right now there's a lot of garbage there." To some extent this is a proxy battle for "I like my UDP filters, don't break them", but I read that as one vote for "make stateless rejection of garbage at the border possible", and one network engineer who needs information about how to do that, preferably with the gear he already has.

> in mind here (where network means network and not also the things that

That is what I mean, at least.

I think we're getting caught up on the euphemism stacked into "managing the network" in this thread ourselves, so maybe we should try to reframe the discussion in terms of specific questions...

More after the coffee break.

Cheers,

Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 23 Oct 2017 08:16:21 -0500

On this specific point ...

On Thu, Oct 19, 2017 at 3:27 PM, Ted Hardie <[email-masked]> wrote:

>> So while I do take note of everybody's position in the previous
>> discussion and I even share some of the concerns, this discussion did not
>> provide much input for me to think that this workshop could not be useful
>> (of course under the precondition that we are able to get the right people
>> in the room and have a good moderation).
>>
>> Mirja
>>
>>
>>
> wouldn't degrade.

Bingo. I've actually worked in the twiddling-with-TCP space, and this was
the most amazing output from MaRNEW to me. Jana asked if operators could
turn off their TCP boxes long enough to get traces of untwiddled TCP
traffic on modern radio networks, so he could understand what specific
problems they would have been seeing without TCP boxes, and the response he
got back was, roughly, "we're not sure what would happen, and we're afraid
to find out".

This is deeply into "if it ain't broke in a way that impacts revenues in a
way we can track, don't fix it" territory. At least some of those boxes
were sold to optimize TCP over GPRS, which was a couple of cellular
generations ago. TCP boxes could improve performance THEN, but it's not
clear to me that TCP boxes improve performance NOW, and (almost) no one
with a network wants to find out for sure.

This was why I was excited about the conversation Al Morton was having
about how ATT really tries to measure performance, after the QUIC interim
ended earlier this month - because it's a different way to have the
conversation we tried to have with MaRNEW. But that's not what the proposed
workshop would cover, and it's not clear that an IAB workshop would be the
right place to have that conversation (so I agree with Mirja's assessment
about that).

Spencer

> But it's really not clear that the answer is "none", even if we eliminate
> all the inspection cases that are actually about content.
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Oct 2017 18:53:09 -0700

On 10/23/2017 6:16 AM, Spencer Dawkins at IETF wrote:

> about how ATT really tries to measure performance, after the QUIC
> interim ended earlier this month - because it's a different way to
> have the conversation we tried to have with MaRNEW. But that's not
> what the proposed workshop would cover, and it's not clear that an IAB
> workshop would be the right place to have that conversation (so I
> agree with Mirja's assessment about that).

This goes back to the comment that the "Manageability of Encrypted
Traffic" is way too vague a subject to be constructive. Just here, we
have heard two concrete proposals:

1) TCP optimizers. Are they really needed? Many of us feel that the
answer to the first question is "probably not". What can the network
operators do instead? Probably some combination of nothing, AQM and ECN.
Plus better congestion control algorithms in the end node.

2) UDP Garbage. Is that a real problem? Probaby yes. What can we
operators do? Again, there are probably concrete solutions, largely in
the AQM category, or maybe firewalls just a little smarted than the
basic stateful stuff. And that "little smarter than stateful" may well
require some cooperation of the end-to-end transport, so the boxes can
distinguish between "desirable traffic" and "garbage".

Specific workshops on simple themes like that are much more likely to
produce results than some catch-all "management of encryption."

-- 
Christian Huitema

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 24 Oct 2017 09:52:31 +0400

> On 24 Oct 2017, at 05:53, Christian Huitema <[email-masked]> wrote:
> 

In both of these cases, it doesn't seem like a workshop is necessary, *if* we think we know enough about the problem.

One could argue that the mostly-inconclusive outcome of ACCORD points at (1), and it's now the responsibility of tsvarea/tsvwg to provide normative advice here.

On part (2), this is at this point a QUIC-specific issue, since QUIC is the instance of "encapsulate transport evolution in UDP" the IETF has decided to work on. So we should just make sure that advice makes it into the manageability draft, and that any requirements to support filtering (having an observable handshake, anything beyond it) are reflected in the transport draft. Also a WG thing.

I'm interested in trying to shake other cases out, whether concrete or abstract.

Cheers,

Brian

---

From: Ted Hardie <[email-masked]>
Date: Tue, 24 Oct 2017 09:15:22 -0700

> produce results than some catch-all "management of encryption."

A different way we have talked about this topic before is in terms of
implicit path signals being removed with encryption.  The two examples you
have above are responses from network operators to the signals they got
from examining the traffic along the path ("this TCP latency is
problematic" and "this UDP traffic isn't to a real service").
Interestingly, those examples fall into the same classes we came up with at
MARNEW:  one is a flow characteristic (which does not require examining the
payload) and the other is an application characteristic (which currently
either requires examining the payload or knowing something about the
deployment of the application, like what ports are active services  at a
specific IP address)/

Those may actually imply that there are two very different questions here:
are there any flow characteristics that must be available to the path for
it function correctly and efficiently?  are there any methods that allow
you to determine application characteristics without providing blanket
access tot he payload?

Folks are still discussing the former question, but the answer seems to be
that the required characteristics are pretty few.  If even those are
missing, network operators may need to add infrastructure that does new
kinds of measurement to interpolate the correct answers, but there seem to
be at least a few ways forward there.

The latter is currently done by shared keys in something that could be
charitably called a split client model (and uncharitably called an attack
or many worse things).  I can come up with ways of replacing it, but they
seem to either require unworkable key distribution systems or a level of
ossification that would go far beyond what we have seen before, because it
ossifies the applications as well as the network stack.  If there are
better approaches than these, though, it would be darn useful to surface
them, because the tender mercies of the relevant vendors are a little less
tender than I personally like.  I'm okay with tackling these on a one-off
basis, but my intuition is that this is a class of problems and that there
may be a common toolkit for solving them if they can be solved at all.

Having written that, I am wondering whether we are talking workshop or RG.

Ted

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 24 Oct 2017 16:05:14 -0500

Hi, Ted,

On Tue, Oct 24, 2017 at 11:15 AM, Ted Hardie <[email-masked]> wrote:

> Those may actually imply that there are two very different questions
> here:  are there any flow characteristics that must be available to the
> path for it function correctly and efficiently?  are there any methods that
> allow you to determine application characteristics without providing
> blanket access tot he payload?
>

Assuming you mean a workshop or RG for "the latter"? PANRG is just getting
started, but I'd think the former questions are in (the
larger-than-IETF-WG) scope for that proposed RG.

ISTM that the path forward in either direction would be strongly influenced
by how we can get the right people in the room.

I note that an IRTF RG can have closed membership (we don't do that often,
but it happens), so the same pressures about who can say what in public
could be accommodated either way.

Spencer

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Oct 2017 02:57:12 +0100

Sorry, I've lost track - where are we with this overall?

(I hope we're at: "yeah, bit of a re-think needed, back later")

S.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 25 Oct 2017 10:40:41 +0400

hi Stephen,

Here's where I think we are, hatless personal opinion:

(1) Communicating *out* what we think the impacts of IETF work to improve privacy and evolvability are to effected nonparticpiant communities is useful, and we don't quite know yet the right way to do/target this. Mirja went to the CH monitoring conference, I had a lightning talk at RIPE this week, but calling this a strategy is potentially mistargeted and/or doesn't scale. I think we need to keep talking about this, and would suggest that stackevo and privsec could discuss this jointly during the stackevo lunch on Wednesday in Singapore.

(2) We don't have a very good handle on a grand unified theory of measurement and management without cleartext. For each effected function, We've identified a couple of specific cases, as Christian notes: TCP optimization (we see no evidence that we need it, so probably shouldn't design for it), UDP garbage rejection for QUIC (potentially/probably necessary, but a matter for the QUIC WG). There are also the TLS static DH and SNI encryption discussion (ongoing in TLS).

I personally still think we need an effort on 2 (said grand unified theory), whatever form that takes. I don't think we have a very good handle on that yet. I'd like to try and discuss this in person in Singapore, but yeah, from a merely logistical standpoint unless a very clear and focused suggestion for a workshop program falls out of that, I don't think MoET will happen in London.

Cheers,

Brian

> On 25 Oct 2017, at 05:57, Stephen Farrell <[email-masked]> wrote:
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Oct 2017 08:37:11 +0100

Thanks Brian,

That seems like a fair summary. Happy to chat in Singapore
about how to approach your grand unified theory.

S.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 25 Oct 2017 12:14:48 +0400

hi Spencer,

(#include <bht/rants/gmail_quoting_sucks.txt>; see inline below)

> On 25 Oct 2017, at 01:05, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Ted,
> 
> On Mon, Oct 23, 2017 at 6:53 PM, Christian Huitema <[email-masked]> wrote:

<snip>

>> Folks are still discussing the former question, but the answer seems to be that the required characteristics are pretty few.  If even those are missing, network operators may need to add infrastructure that does new kinds of measurement to interpolate the correct answers, but there seem to be at least a few ways forward there.
>> 
>> The latter is currently done by shared keys in something that could be charitably called a split client model (and uncharitably called an attack or many worse things).  I can come up with ways of replacing it, but they seem to either require unworkable key distribution systems or a level of ossification that would go far beyond what we have seen before, because it ossifies the applications as well as the network stack.  If there are better approaches than these, though, it would be darn useful to surface them, because the tender mercies of the relevant vendors are a little less tender than I personally like.  I'm okay with tackling these on a one-off basis, but my intuition is that this is a class of problems and that there may be a common toolkit for solving them if they can be solved at all.
>> 
> Assuming you mean a workshop or RG for "the latter"? PANRG is just getting started, but I'd think the former questions are in (the larger-than-IETF-WG) scope for that proposed RG.

PANRG is looking at only one half of the former; see draft-trammell-panrg-questions. In path-aware networking as it's (currently) framed there, the properties of a path are available to the endpoints, and endpoints can select paths based on those properties. I *guess* you could implement flow characteristic exposure by creating path properties such as "this kind of flow goes here", and expose flow properties through path selection choices, but that's squandering most of the flexibility of architectures like this IMO.

> ISTM that the path forward in either direction would be strongly influenced by how we can get the right people in the room.
> 
> I note that an IRTF RG can have closed membership (we don't do that often, but it happens), so the same pressures about who can say what in public could be accommodated either way.

as a point of order, if we're thinking it makes sense to have a closed RG -- i'm skeptical, since I think that the "latter" question Ted poses is less "what are you doing now?" and more "how can we make split-client architectures, where they are deemed to be necessary, less inherently dangerous?" for which I don't see how being closed gets us better results -- we should ask Allison about that early.

Cheers,

Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Oct 2017 10:36:45 +0200

Hi,

On 10/25/17 10:14 AM, Brian Trammell (IETF) wrote:
> as a point of order, if we're thinking it makes sense to have a closed
> RG -- i'm skeptical, since I think that the "latter" question Ted
> poses is less "what are you doing now?" and more "how can we make
> split-client architectures, where they are deemed to be necessary,
> less inherently dangerous?" for which I don't see how being closed
> gets us better results -- we should ask Allison about that early.

If you get serious about even considering a closed RG, if you want a
perspective from someone who has run one, give me a ping.

Eliot

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 26 Oct 2017 13:44:17 -0500

Hi, Brian,

> > gets us better results -- we should ask Allison about that early.

Perhaps I lost state, but I thought one of the strategies under
consideration was a closed venue (an IAB workshop) under Chatham House
rules.

I'm not on the IAB (and you are), but ISTM that the discussion was headed
for less ambitious questions than what I would have expected from an IAB
workshop, so when the possibility of an RG was mentioned, I was pointing
out that some level of "get people in a closet and let them tell you what
they're really seeing/doing, now that we've proved they can't tell you that
in public" was possible with an RG.

That was all, and sorry if I wasn't clear ("text is hard").

That said, I did like the possibility of giving people a place to provide
input without attribution for this topic.

When I was Tech Director for the SIP Forum, we had multiple sessions on
fraud detection that couldn't have happened in an open and quotable
session. I assumed you were thinking about that kind of thing.

But I don't have opinions about how that should happen.

> perspective from someone who has run one, give me a ping.

Always good advice.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 27 Oct 2017 13:06:14 +0400

hi Spencer,

> On 26 Oct 2017, at 22:00, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Brian,
> 
> Perhaps I lost state, but I thought one of the strategies under consideration was a closed venue (an IAB workshop) under Chatham House rules.

You lost state because this thread has become stateless. :)

We're currently in "identify what the problem is and figure out how to address it", some part of which may be a workshop under some set of rules, some part of which may be an RG, open or closed, long or short running, some of which may be referral of work to existing RGs/WGs, some of which may be merely "step back and let the WGs slug it out on their own", and some of which may be improving communication from the IETF to affected nonparticipants, less in terms of "tell us what you need" which doesn't work very well, and more "here's what we're doing".

> I'm not on the IAB (and you are), but ISTM that the discussion was headed for less ambitious questions than what I would have expected from an IAB workshop, so when the possibility of an RG was mentioned, I was pointing out that the same level of "get people in a closet and let them tell you what they're really seeing/doing, now that we've proved they can't tell you that in public" was possible with an RG.
> 

Yep, we're there. I was just pointing out that we don't want to surprise the chair of the IRTF with this, so that was just a marker to point out that if we think we might get there we'd want Allison's opinion on it.

> That said, I did like the possibility of giving people a place to provide input without attribution for this topic.

"please post your complaints about IETF protocols in the blockchain"?

> When I was Tech Director for the SIP Forum, we had multiple sessions on fraud detection that couldn't have happened in an open and quotable session. I assumed you were thinking about that kind of thing.
> 

I agree, but also believe that openness should be a pretty sticky default.

Cheers,

Brian