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

[Alissa Cooper <[e-mail]>]

Couple of mostly random thoughts ...

> On Apr 4, 2018, at 4:50 AM, Brian Trammell (IETF) <[e-mail]> wrote:
> 
> 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-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 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.

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

> 
> Thanks, cheers,
> 
> Brian (stackevo lead hat)