Subject: [Stackevo] draft-hardie-path-signals and draft-trammell-wire-image

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 4 Apr 2018 10:50:00 +0200

Greetings,

After discussion at our Friday morning London meeting (and thanks, all, on the program for your remarkable  Stack Evolution Program would like the IAB to consider two documents for publication on the IAB stream:

https://tools.ietf.org/html/draft-trammell-wire-image-03

https://tools.ietf.org/html/draft-hardie-path-signals-03

The wire image draft describes what a protocol's wire image is, and explores the situations that arise when a protocol splits its visible wire image from the information it uses for its own operation. (It started as a draft I wrote during the extended Singapore plenary discussion on encryption of protocols, riffing off Ted's observation from the dais that protocols with explicit wire images were a completely new thing, in part to describe what I mean when I use the term.)

The path signals draft recommends that protocol machinery be confidentiality protected, and that any signal exposed to on-path devices (outside confidentiality protection) be *explicitly* so exposed and integrity protected. It reiterates that metadata injection is considered harmful.

Thanks, cheers,

Brian (stackevo lead hat)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Apr 2018 09:58:01 +1000

These look mostly good, and I think that it's a worthwhile thing to publish.

Some nits.

On wire-image:

I think that "Invariants" as a bare phrase is a little too close to
jargon.  Maybe "Declaring protocol invariants" works in the two places
that Invariants is capitalized (title and second sentence).

On path-signals:

That first paragraph of the introduction is a pretty large mouthful.
I also think that it doesn't need to say this, which might avoid
controversy:

   This document recommends
   that explict signals be used by transports which encrypt their state
^^^ typo here
  mechanics.

How about:

   Protocol operation generates signals that are seen by on-path elements.
   Though many such signals are intended for consumption by a peer, network
   elements might also consume or alter these signals.  For example,
   TCP operates entirely in the clear, making its signals available to
path elements.
   Signals that are visible to network elements on the path between
   communicating endpoints can be used as signals by those network elements.

   This document explores the consequences of exposing signals to
   network elements.  It recommends the use of confidentiality
   protection for protocol signaling.  It recommends that protocols that
   expose signals to network elements only do so explicitly and with the intent
   that the signals are available to network elements on the path.

There's an errant "(" in Section 3.1.2.  Please provide a citation for
"Endpoint-Independent Mapping/Endpoint-Independent Filtering" as well.

Extra period at the end of 3.1.3.

In security considerations: divergence is not detectable by on-path
devices -> ... might not be ....  Don't assume that we're that good at
avoiding leakage.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Apr 2018 10:55:23 +1000

Hi Brian,

> On 4 Apr 2018, at 6:50 pm, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Greetings,
> 

I like this document. Two comments:

* 1. Introduction seems to skip around a discussion of whether participants in lower-layer protocols are also participants in "higher" layer protocols -- i.e., is participation transitive? 

* 3.3.1. Invariants begs the question of what networks will do with the parts of the message that are *not* invariant, and the resulting strategies that protocol designers might take -- i.e., some form of encryption, greasing, etc. Not sure if we intend to publish a separate doc here, but it might be worth mentioning.

> https://tools.ietf.org/html/draft-hardie-path-signals-03

Section 3 seems very good; the rest seems very... tentative. That's probably appropriate, except:

* 4.3 Replace These With Per-Transport Signals - the last two sentences here seem very wishy-washy. In combination with 4.4, it feels like it's trying to steer towards a PLUS-like solution, but only justifying it in terms of vague impact upon ossification.

Also, in 5. Recommendations, do we want to say anything about whether a protocol should *enable* path elements to add signals (at least within the protocol's control)?

> Brian (stackevo lead hat)

Cheers,

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

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 6 Apr 2018 12:01:11 +0200

hi Mark,

Answering -wire-images questions only in this reply...

> On 5 Apr 2018, at 02:55, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Brian,
> 
> 

Hm, this is a good point...  I looked at this for a while, though, and I couldn't come up with text here without going down a side-tracked philosophical rabbit hole; suggestions?

> * 3.3.1. Invariants begs the question of what networks will do with the parts of the message that are *not* invariant, and the resulting strategies that protocol designers might take -- i.e., some…

I've added some text here to the working copy (https://britram.github.io/draft-trammell-wire-image/draft-trammell-wire-image.html#rfc.section.3.3.1) -- is this what you had in mind?

Thanks, cheers,

Brian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 Apr 2018 10:39:10 +1000

> On 6 Apr 2018, at 8:01 pm, Brian Trammell (IETF) <[email-masked]> wrote:
>> 

I'd change the first sentence in the second paragraph to something like:

"""
Implicit in a protocol specification is the information the protocol radiates toward nonparticipant observers of the messages sent among participants, often including participants in lower layer protocols.
"""

> I've added some text here to the working copy (https://britram.github.io/draft-trammell-wire-image/draft-trammell-wire-image.html#rfc.section.3.3.1) -- is this what you had in mind?

I'd add something like:

"""
Parts of a protocol's wire image that are purposefully not invariant because they are not intended to be visible or manipulated by defines on paths should, where possible, be protected by encryption, "greasing" [ref?] or other techniques to assure that they do not become invariant over time, through ossification.
"""

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 10 Apr 2018 14:04:53 +0200

hi Mark,

> On 9 Apr 2018, at 02:39, Mark Nottingham <[email-masked]> wrote:
> 
> 
> 

Yeah, this is better. Changed, thanks!

> Parts of a protocol's wire image that are purposefully not invariant because they are not intended to be visible or manipulated by defines on paths should, where possible, be protected by encryptio…

I'd thought this followed, but yeah it bears making explicit.

I'm pointedly avoiding referring to "greasing" by that name here because it seems to be that the discussion around it in QUIC has become dominated by overgeneralization and magical thinking; a reference to use-it-or-lose-it seems more precise (Martin, I presume you're intending to publish that one on the IAB stream eventually?).

Have reworked, will submit -04 shortly.

Cheers,

Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 10 Apr 2018 07:49:00 -0500

FWIW,

On Tue, Apr 10, 2018 at 7:04 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> >>> * 1. Introduction seems to skip around a discussion of whether
> participants in lower-layer protocols are also participants in "higher"
> layer protocols -- i.e., is participation transitive?
> >>
> >> Hm, this is a good point...  I looked at this for a while, though, and
> I couldn't come up with text here without going down a side-tracked
> philosophical rabbit hole; suggestions?
> >
> > Implicit in a protocol specification is the information the protocol
> radiates toward nonparticipant observers of the messages sent among
> participants, often including participants in lower layer protocols.
> > """
>
> >>> * 3.3.1. Invariants begs the question of what networks will do with
> the parts of the message that are *not* invariant, and the resulting
> strategies that protocol designers might take -- i.e., some form of
> encryption, greasing, etc. Not sure if we intend to publish a separate doc
> here, but it might be worth mentioning.
> >>
> >> I've added some text here to the working copy (
> https://britram.github.io/draft-trammell-wire-image/
> draft-trammell-wire-image.html#rfc.section.3.3.1) -- is this what you had
> in mind?
> >
> > I'd add something like:
> >
> > """
> > Parts of a protocol's wire image that are purposefully not invariant
> because they are not intended to be visible or manipulated by defines on
> paths should, where possible, be protected by encryption, "greasing" [ref?]
> or other techniques to assure that they do not become invariant over time,
> through ossification.
> > """
>
> I'm pointedly avoiding referring to "greasing" by that name here because
> it seems to be that the discussion around it in QUIC has become dominated
> by overgeneralization and magical thinking; a reference to
> use-it-or-lose-it seems more precise (Martin, I presume you're intending to
> publish that one on the IAB stream eventually?).
>

I couldn't possibly comment on "magical thinking" (tempting though that
might be), but "overgeneralization" does sound about right to me. Right
enough that I hope Martin's "intending to publish" is a Yes.

Spencer

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 10 Apr 2018 06:28:38 -0700

> Am 10.04.2018 um 05:49 schrieb Spencer Dawkins at IETF <[email-masked]>:
> 
> > """

I don’t know because that’s basically the message of the path-signals draft. Maybe add a pointer instead?

Mirja

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Apr 2018 11:25:05 +1000

> I'm pointedly avoiding referring to "greasing" by that name here because it seems to be that the discussion around it in QUIC has become dominated by overgeneralization and magical thinking; a refe…

Sure.  Though not a lot of feedback on that to date, so maybe there is
only lukewarm interest.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 11 Apr 2018 08:52:46 +0200

> On 11 Apr 2018, at 03:25, Martin Thomson <[email-masked]> wrote:
> 

consider this +4°C of interest, will read and send comments today.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 13 Apr 2018 16:08:06 -0400

Couple of mostly random thoughts ...

> On Apr 4, 2018, at 4:50 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Greetings,
> 
> https://tools.ietf.org/html/draft-trammell-wire-image-03 <https://tools.ietf.org/html/draft-trammell-wire-image-03>
> https://tools.ietf.org/html/draft-hardie-path-signals-03 <https://tools.ietf.org/html/draft-hardie-path-signals-03>

In the long-ago of the IAB privacy program, Stephen Farrell and I had an exchange with George Danezis about doing some reviews of specific IETF protocols’ susceptability to traffic analysis. That never happened, but George did express an interest in doing some sort of work in the IETF. He might be a good reviewer and/or contributor to these documents, particularly to add some rigor to the bits about packet timing and size information.

There has been some discomfort expressed with using the term “consent” in the context of communications consent for RTCWEB. I didn’t particularly think that was actionable in the RTCWEB context, but I do worry a bit in the general context that consent connotes a user’s involvement, when clearly that is not how the term is used in these documents. Might be good to find a different way to describe the same concept.

> The path signals draft recommends that protocol machinery be confidentiality protected, and that any signal exposed to on-path devices (outside confidentiality protection) be *explicitly* so expose…

As a product intended for broad consumption by the IETF community, I think the path-signals document needs to be more clear about the scope of its recommendations. Limited to transport protocols? Limited to new transport protocols? More generally, both of these documents are probably not easily understood by the parts of the community that have not been closely following spud/plus/quic. More context would help if the idea is to broaden the conversation (although I’m not sure that is the idea).

Thanks,
Alissa

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 17 Apr 2018 11:33:21 +0200

hi Martin,

I've read draft-thomson-use-it-or-lose-it. IMO it would be useful to publish on the IAB stream, as a higher-level discussion of the space of protocol design principles which includes greasing. It seems to me to be broadly ready for IAB stream adoption, and I'd encourage other program members to have a look.

A few disorganized musings while reading the document follow:

There's a more fundamental truth hiding in sections 2 and 2.1: "an implementation of a protocol design is the intersection of that design with the minimum set of functionality  considered important by the implementors." Basic interop is generally considered important. Future extensibility less so, which leads to extension points being (perhaps uniquely) affected. IOW it's not that these implementations are bad, it's that they're exactly as good as they think they need to be.

The document is (perhaps unsurprisingly) focused primarily at layer 7, but the insights here are equally applicable at layers 3 and 4. Especially sections 2.2, 3.1, 3.3 could use some transport/network layer examples. I can propose a PR here.

I like the barnacles-on-hulls image invoked by "protocols that deploy without active measures against intermediation can accrue middleboxes that depend on certain aspects of the protocol" (section 2.2. para 3), but "middlebox accrual" is a little imprecise here. How about: "Protocols deployed without active measures against intermediation will tend to become intermediated over time, as middleboxes are deployed to perform some function (actual or perceived) on their traffic"?

Cheers,

Brian

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Apr 2018 06:07:18 -0700

On Tue, Apr 17, 2018 at 2:33 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

>
>
> I like the barnacles-on-hulls image invoked by "protocols that deploy
> without active measures against intermediation can accrue middleboxes that
> depend on certain aspects of the protocol" (section 2.2. para 3), but
> "middlebox accrual" is a little imprecise here. How about: "Protocols
> deployed without active measures against intermediation will tend to become
> intermediated over time, as middleboxes are deployed to perform some
> function (actual or perceived) on their traffic"?
>
>
I like the image, but I worry about the lack of agency in "may accrue"
seems like we're dancing around the issue.  There are specific folks who
deploy these for specific purposes, and we might want to treat them as
actors here.

Ted

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 17 Apr 2018 15:12:31 +0200

> On 17 Apr 2018, at 15:07, Ted Hardie <[email-masked]> wrote:
> 
> On Tue, Apr 17, 2018 at 2:33 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> 
> I like the image, but I worry about the lack of agency in "may accrue" seems like we're dancing around the issue.  There are specific folks who deploy these for specific purposes, and we might want to treat them as actors here.

"...as network operators deploy middleboxes to perform..."?

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Apr 2018 06:19:57 -0700

On Tue, Apr 17, 2018 at 6:12 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> Works for me.

Ted

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Apr 2018 18:15:10 +1000

Thanks for the review Brian,

I have updated text based on your feedback, tweaked a few other
things, added some acknowledgments, and I eagerly await your pull
request.

Repo here:
https://github.com/martinthomson/use-it-or-lose-it

HTML here:
https://martinthomson.github.io/use-it-or-lose-it/draft-thomson-use-it-or-lose-it.html

I've also opened an issue so that I don't forget that you volunteered
to help out :)
https://github.com/martinthomson/use-it-or-lose-it/issues/4

Cheers,
Martin

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 30 Apr 2018 10:25:38 -0400

FWIW, I read the doc and like it a lot.  Publishing it would be a Good 
Thing, IMO.

--aaron

On 30 Apr 2018, at 4:15, Martin Thomson wrote:

>> I've read draft-thomson-use-it-or-lose-it. IMO it would be useful to 
>> publish on the IAB stream, as a higher-level discussion of the space 
>> of protocol design principles which includes greasing. It seems to me 
>> to be broadly ready for IAB stream adoption, and I'd encourage other 
>> program members to have a look.
>>
>> There's a more fundamental truth hiding in sections 2 and 2.1: "an 
>> implementation of a protocol design is the intersection of that 
>> design with the minimum set of functionality  considered important by 
>> the implementors." Basic interop is generally considered important. 
>> Future extensibility less so, which leads to extension points being 
>> (perhaps uniquely) affected. IOW it's not that these implementations 
>> are bad, it's that they're exactly as good as they think they need to 
>> be.
>>
>> The document is (perhaps unsurprisingly) focused primarily at layer 
>> 7, but the insights here are equally applicable at layers 3 and 4. 
>> Especially sections 2.2, 3.1, 3.3 could use some transport/network 
>> layer examples. I can propose a PR here.
>>
>> without active measures against intermediation can accrue middleboxes 
>> that depend on certain aspects of the protocol" (section 2.2. para 
>> 3), but "middlebox accrual" is a little imprecise here. How about: 
>> "Protocols deployed without active measures against intermediation 
>> will tend to become intermediated over time, as middleboxes are 
>> deployed to perform some function (actual or perceived) on their 
>> traffic"?
>>
>> Cheers,
>>
>> Brian
>>
>>>> I'm pointedly avoiding referring to "greasing" by that name here 
>>>> because it seems to be that the discussion around it in QUIC has 
>>>> become dominated by overgeneralization and magical thinking; a 
>>>> reference to use-it-or-lose-it seems more precise (Martin, I 
>>>> presume you're intending to publish that one on the IAB stream 
>>>> eventually?).
>>>