Subject: Re: Call for Comment: <draft-trammell-wire-image-04> (The Wire Image of a Network Protocol)

From: Stephen Farrell <[email-masked]>
Date: Thu, 6 Sep 2018 03:01:34 +0100

Hiya,

(cc'ing [email-masked] - I'm not keen that discussion of such
IAB drafts be banished to [email-masked]:-)

I don't believe this is ready. It's an interesting topic, but
the IAB ought do more work on this before freezing text in
an RFC. There is a useful RFC to be written here, but this is
not yet it IMO. More detailed comments below.

Aside: as a process question - was there any indication to
the community that this would be an IAB draft? Neither the
draft filename nor content (other than acks) indicate that
the IAB were collectively involved in this work. It puzzles
me that the IAB don't ask earlier in cases like this.

On 06/09/18 01:14, IAB Executive Administrative Manager wrote:
> This is an announcement of an IETF-wide Call for Comment on 
> draft-trammell-wire-image-04.
> 
> The document is being considered for publication as an Informational RFC 
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/draft-trammell-wire-image/>
> 
> The Call for Comment will last until 2018-10-03. Please send comments to
> [email-masked] and [email-masked].
> 
> Abstract
> 
>    This document defines the wire image, an abstraction of the
>    information available to an on-path non-participant in a networking
>    protocol.  This abstraction is intended to shed light on the
>    implications on increased encryption has for network functions that
>    use the wire image.
> 

- Why does section 1 only have references to things that call
out difficulties with more confidentiality and has no references
to things that explain why that's needed or potential benefits?
Seems unbalanced to me. (And not in isolation - ISTM there's
a real trend that folks primarily interested in transport
protocol issues "sin" like this. I'm not casting aspersions,
it's entirely understandable to focus on the issues that are
of most concern, but better to be more balanced I think? For
other examples, see the evolution of Gorry's header encryption
draft, and text contributed by various folks to versions of
Kathleen and Al's RFC.)

- Section 2 & 3: you're right! the definition *is* so vague as
to be useless:-) In particular that definition doesn't seem to
reflect RTT, which I guess would affect inferences that can be
derived from packet timing. Similarly, the definition doesn't
reflect message sizes correctly (referring to a "sequence of
messages" or "bits") which seems to me to ignore the possibility
that APDUs are mapped to ciphertext packets in non-trivial ways
so that an observer cannot reliably distinguish APDU boundaries.
Also, I think you need to explicitly include protocol headers
at the levels below the one at which the last confidentiality
service was applied as those also expose information and are
not clearly "protocol messages" for the protocol that is of
concern to the analyst. Information leakage may also depend
on the observer knowing about machine details, e.g. if the
bad actor is to take advantage of inter-packet timing to infer
higher lay protocol features. Lastly, (for now:-) and as
reflected below (and in your text), related protocols (like
DHCP or port 53 DNS) can expose information, so I think the
useful concept here involves more bits, timing, flows and
peers than your definition.

- "From the point of view of a passive observer, the wire
image of a single protocol is rarely seen in isolation." To
me that implies that you're considering the wrong abstraction
but perhaps that's debatable. Was that debated? If so, are
there records of that debate? (This partly replicates one
of the points above.)

- "However, it cannot be applied to protecting non-header
information in the wire image." Not sure that's correct,
even with your (IMO-broken:-) definition - the "it" there
being cryptography, one could define a ciphersuite so that
it adds chaff messages and not only padding, so I think the
"cannot" is incorrect. Padding and cover traffic are generally
a matter of relative efficiency and not absolute. I think
AEAD ciphers may also contradict this statement as there is
nothing to prevent a layer 4 AEAD using layer 3 or 2 headers
as part of the additional data. (Might be unwise, but could
be done, so "cannot" isn't right I think.)

- "While packets cannot be made smaller than their
information content,..." - I'm not sure if this is correct
and perhaps again reflects a problem with definitions. With
MPTCP the packets visible to some observers may be smaller
than the information content of the exchange between the
endpoints. I guess the same is true whenever there are any
OOB possibilities.

- 3.2: "impossible" isn't correct. We do know there are
MITM boxen in the real world for example. I think that may
invalidate the subsequent "solely" conclusion, as those
boxen can often modify messages or spoof.

- "Integrity protection can only practically be applied to
the sequence of bits in each packet," seems incorrect. I
once wrote code that signed the first N bits of an N byte
message and have seen similar bugs, so integrity can clearly
be applied to subsets of those bits. I'm also not sure your
text matches a TESLA-like scheme.

- Since I mentioned TESLA, IP multicast seems not to have
been considered here - was it? How about message replication
at other layers?

- (skipping some...) 3.1.1: the "extent" of a wire image
seems to me to deserve an equally precise definition as
the wire image itself. I'm not sure which is really more
interesting - given that I disagree with aspects of
the current definition of the latter, and there's no
definition of the former at all, I'm not sure if we can
easily argue this. (Could be that the idea of defining
invariants is a good approach. Not saying it isn't, just
not sure.) I think there may be an interesting thing to
define here that's like what I think you mean by "extent."
Intuitively it seems there should be a useful thing to
define that encompasses all of the bits sent anywhere due
to the playing a protocol-role and emitting a (minimally
defined) "wire image" of a specific layer-N protocol.

- "Parts of a protocol's wire image not declared invariant..."
Again I think the broken definitions render this moot, but
this seems to conflate ideas about "invariants" with the
"wire image" in ways that assume both are much more
well-defined than I think is the case.

- 3.3.2: I don't know how a protocol receiver can ever
handle "veracity"

- There's a bunch of text that seems sensible but where
I'm not sure, given the definitional issues. Most of it,
looks ok though.

- Lastly, if the IAB published this as-is, the sky won't
fall. But I think the IAB will look a little less wise.

Cheers,
S.

---

From: Brian Trammell (IETF) <[email-masked]>
Date: Thu, 6 Sep 2018 18:51:02 +0200

hi Stephen,

> On 6 Sep 2018, at 04:01, Stephen Farrell <[email-masked]> wrote:
> 
> Signed PGP part
> 
> Hiya,
> 

This is indeed why we put it out for community review. Many thanks for your input, replies inline.

> me that the IAB don't ask earlier in cases like this.

I had to look this up, since it was adopted a while ago.

Adoption on the IAB stream happened during the 11 April telechat (see https://www.iab.org/documents/minutes/minutes-2018/iab-minutes-2018-04-11/). This document transitioned to "Active IAB document" state on 19 April (see https://datatracker.ietf.org/doc/draft-trammell-wire-image/history/).

This draft, together with draft-iab-path-signals, was also presented as an adopted IAB draft in both tsvarea and opsec in Montreal.

So, yes, there was both an indication to the community through the minutes of the meeting at which the document was adopted, as well as through presentations at two relevant sessions of the IETF meeting following said adoption. I'm not sure what more we should have done here, but I am open to suggestions.

> draft, and text contributed by various folks to versions of

I note you couch this objection, accurately in my opinion, in religious terms, though I am admittedly a little confused at how one can openly accuse a whole area of IETF participants of committing sins without casting aspersions. :)

I *think* the ask here is a sentence in the intro about how awesome encryption is, which IMO is not really what this document is about. This document is a discussion of the view an on-path observer has about (any) stack of protocols in the Internet, and what changes when encryption moves down that stack. Section 3.3, especially, takes this movement as a given.

> derived from packet timing.

I'm not sure I understand this comment -- what aspect of RTT is not covered by "In particular, interpacket timing, packet size, and message sequence information can be used to infer other parameters of the behavior of the protocol, or to fingerprint protocols and/or specific implementations of the protocol" (section 3 para 2)?

> Similarly, the definition doesn't

Yes, this could be tightened up a bit. Since each message in the "sequence of messages" is a "sequence of bits" and all finite sequences of bits have a finite size, I'd argue that it does reflect message sizes, but yeah, this is probably not the most readable way to do so.

> concern to the analyst.

Yep, this is a good point.

> Information leakage may also depend
> higher lay protocol features.

In practice, everything about the wire image can be correlated with everything else the observer knows (note that we explicitly avoid assigning intent to this observer, because this document is scoped to the properties of the *image* itself, agnostic of threat model, though this lack of pejorative terminology should not be taken as a value judgement). We can add a note to this effect to the last paragraph of section 3.

> Lastly, (for now:-) and as
> of the points above.

IMO this is the distillation of all of the comments above.

I don't think that the issue is that we're using the wrong abstraction, but I do think we need to dig into it a bit deeper: first, the wire image should be considered at each layer (as you say) with the caveat that the observer always sees everything on its "portion" of the wire; second, this implies that different observers will see different things. This also leads to a less clunky formulation of what I think you mean by "extent" below. We'll work on this.

> "cannot" is incorrect.

I'd argue that protocol-level anti-analysis features due to chaff data etc are features of some aspect of the protocol other than the ciphersuite, but I admit I may not be up to date on what the scope of a ciphersuite can be.

> Padding and cover traffic are generally

See above -- I think this is an aspect of this definition being fuzzier about layering than it should be, and we should definitely be more explicit about it.

> endpoints. I guess the same is true whenever there are any

I think this statement is a tautology when taken together with the definition of Shannon entropy, but I take your point that the exchange visible in the wire image of a given set of packets (which will often be grouped by 5/6-tuple flows, as flows are generally how forwarding works) may be less than the total end-to-end operation. Since an observer may not even know about these OOB possibilities, though, I'm not sure how this document should address them.

> boxen can often modify messages or spoof.

Cryptographic integrity protection in a two-party protocol that allows modification by on-path devices is, IMO, not cryptographic integrity protection, so again by definition I'm not sure I agree. We should be more explicit about our assumptions here though.

> text matches a TESLA-like scheme.

I'm not sure we understand this sentence the same way -- the intent here is to day that you cannot integrity protect the order of the packets, or the interpacket timing, since they will change as the packets go thorough the network.

I'd have to look into TESLA in order to be able to comment intelligently on it. I don't suspect I'll have a chance to do that this month.

> been considered here - was it? How about message replication

This draft concerns itself with what can be seen (at a single point, which should be made more concrete, yes). ISTM you're asking questions that are aimed at teasing out a threat model related to the thing you talk about below. I'm not sure that's this document but I could be wrong.

> - (skipping some...) 3.1.1:

I presume you mean 3.3.1 here.

> the "extent" of a wire image

I think we understand different things by "extent" here -- the text in 3.3.1 refers to the control that protocol designers have over how on-path observers can/will likely interact with a protocol's wire image, and "extent" refers only to "what portion" of the wire image will be used. You're right that this is a little weak, in that the reduction is in no way secure, and requires a rational model of the on-path observer.

What you seem to be interpreting "extent" to mean in this comment is different, and is actually more interesting. To stretch the analogy implied by "wire image", I think what you're describing is analogous to a long exposure of a wire image in motion: as an observer sees multiple packets, more information may accumulate. This is worth thinking about, but I'm not sure I have my head around it yet.

> - 3.3.2: I don't know how a protocol receiver can ever

First, it's the observer that is trying to determine whether the information in the wire image is accurate, not the receiver; this paragraph attempts to capture the fact that processes that currently treat unencrypted wire image information as genuine cannot continue to do so with engineered wire image information. For example, you can't change the meaning of the TCP SEQ and ACK fields without changing the end-to-end operation of the protocol, while an engineered wire image of an encrypted protocol can easily agree on alternate semantics end-to-end.

This text can probably be clarified; I'm open to suggestions, and pull requests are cheerfully accepted at https://github.com/britram/draft-trammell-wire-image/

> fall. But I think the IAB will look a little less wise.

The intent, of course, is to incorporate community feedback; many thanks for yours.

Cheers,

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2018 14:16:28 +1200

> IAB drafts be banished to [email-masked]:-)

I haven't changed the Cc list, but I respectfully disagree.
I don't see that list as banishment; anyone can join and it's
archived, but it doesn't suffer the noise level of [email-masked]

As a technical comment, I'd like to mention an extreme version
of wire image. The only thing needed to deliver an IP packet
to its destination is the destination address. So the minimal
wire image of a packet is the destination address followed
by some number of encrypted bits.
[Not my invention: Jon Crowcroft's unpublished article on
Sourceless Network Architecture points out that the IP source
address is redundant for the delivery of packets.]

Now this has some minor disadvantages (no diffserv field,
no flow label, no intermediate ICMP replies, etc.) but from the
privacy point of view, it's hard to do better at the single
packet level. You can still do some temporal analysis, but
most of the normal clues are missing since you have no tuple
to track, so it will be extremely hard to assign packets
to flows.

Also, with the message body being pseudorandom, you cannot
deduce anything about the protocol, ports, or payload size,
or even whether the packet is just noise to confuse temporal
analysis.

I think this sets a baseline for discussion of wire images:
you can't have *less* of an image than this. How much do we
sacrifice of this baseline privacy by not encrypting other
parts of the IP header, for example?

(I do wonder about this as RFC material. Somehow it seems
a bit more like a CCR paper to me.)

    Brian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Sep 2018 13:39:47 +0100

Hiya,

(Answering both Brian's in one mail, Brian T above
and Brian C below...)

On 06/09/18 17:51, Brian Trammell (IETF) wrote:
>> (cc'ing [email-masked] - I'm not keen that discussion of such IAB
>> drafts be banished to [email-masked]:-)
>> 
>> 
>> I don't believe this is ready. It's an interesting topic, but the
>> IAB ought do more work on this before freezing text in an RFC.
>> There is a useful RFC to be written here, but this is not yet it
>> IMO. More detailed comments below.
> 
>> Aside: as a process question - was there any indication to the
>> community that this would be an IAB draft? Neither the draft
>> filename nor content (other than acks) indicate that the IAB were
>> collectively involved in this work. It puzzles me that the IAB
>> don't ask earlier in cases like this.
> 
> Adoption on the IAB stream happened during the 11 April telechat (see
> https://www.iab.org/documents/minutes/minutes-2018/iab-minutes-2018-04-11/).
> This document transitioned to "Active IAB document" state on 19 April
> (see
> https://datatracker.ietf.org/doc/draft-trammell-wire-image/history/).
>
>  This draft, together with draft-iab-path-signals, was also presented
> as an adopted IAB draft in both tsvarea and opsec in Montreal.
> 
> So, yes, there was both an indication to the community through the
> minutes of the meeting at which the document was adopted, as well as
> through presentations at two relevant sessions of the IETF meeting
> following said adoption. I'm not sure what more we should have done
> here, but I am open to suggestions.

For this topic, a mail to the ietf-announce or ietf@ietf maybe.
(I'm fine that we drop ietf@ from the thread after this - now
that the topic has popped up there, following up on arch-d is
grand.)

>>> The document is being considered for publication as an
>>> Informational RFC within the IAB stream, and is available for
>>> inspection at: 
>>> The Call for Comment will last until 2018-10-03. Please send
>>> comments to [email-masked] and [email-masked].
>>> 
>>> Abstract
>>> 
>>> information available to an on-path non-participant in a
>>> networking protocol.  This abstraction is intended to shed light
>>> on the implications on increased encryption has for network
>>> functions that use the wire image.
>>> 
>> 
>> - Why does section 1 only have references to things that call out
>> difficulties with more confidentiality and has no references to
>> things that explain why that's needed or potential benefits? Seems
>> unbalanced to me. (And not in isolation - ISTM there's a real trend
>> that folks primarily interested in transport protocol issues "sin"
>> like this. I'm not casting aspersions, it's entirely understandable
>> to focus on the issues that are of most concern, but better to be
>> more balanced I think? For other examples, see the evolution of
>> Gorry's header encryption draft, and text contributed by various
>> folks to versions of Kathleen and Al's RFC.)
> 
> I note you couch this objection, accurately in my opinion, in
> religious terms, though I am admittedly a little confused at how one
> can openly accuse a whole area of IETF participants of committing
> sins without casting aspersions. :)
> 
> I *think* the ask here is a sentence in the intro about how awesome
> encryption is, which IMO is not really what this document is about.

Sure. But isn't it the move to encrypt more that's motivating
this and other drafts? If so, then I think ack'ing that there
are valid and pressing motivations for that move is needed. If
there are other motivations, those aren't clear to me at least
and therefore probably also deserve a mention. We've seen (with
Kathleen and Al's draft), that some people (not the authors here)
do quote drafts like this when arguing against more confidentiality,
so I think this draft, and similar ones, really ought say that
we do need more use of confidentiality, and not just assume that
that's accepted by all readers. Yes, that only needs to be a
sentence or two and some reference, but I do think it needs to
be there.

> This document is a discussion of the view an on-path observer has
> about (any) stack of protocols in the Internet, and what changes when
> encryption moves down that stack. Section 3.3, especially, takes this
> movement as a given.

Right. My comment is that taking that movement as a given likely
means someone somewhere will mis-interpret the draft as being an
argument against more confidentiality, whereas what we're (I hope)
trying to do is to better understand the consequences of the
necessary introduction of more use of confidentiality services.

> 
>> - Section 2 & 3: you're right! the definition *is* so vague as to
>> be useless:-) In particular that definition doesn't seem to reflect
>> RTT, which I guess would affect inferences that can be derived from
>> packet timing.
> 
> I'm not sure I understand this comment -- what aspect of RTT is not
> covered by "In particular, interpacket timing, packet size, and
> message sequence information can be used to infer other parameters of
> the behavior of the protocol, or to fingerprint protocols and/or
> specific implementations of the protocol" (section 3 para 2)?

The quoted text is fine. I don't believe the definition is though,
given the things mentioned below (e.g. not being able to identify
APDUs, and multi-path issues).

> 
>> Similarly, the definition doesn't reflect message sizes correctly
>> (referring to a "sequence of messages" or "bits") which seems to me
>> to ignore the possibility that APDUs are mapped to ciphertext
>> packets in non-trivial ways so that an observer cannot reliably
>> distinguish APDU boundaries.
> 
> Yes, this could be tightened up a bit. Since each message in the
> "sequence of messages" is a "sequence of bits" and all finite
> sequences of bits have a finite size, I'd argue that it does reflect
> message sizes, but yeah, this is probably not the most readable way
> to do so.

Hmm. I'm really not sure you have the abstraction right here.
Any ciphertext seen at layer N might reflect any set of parts
of protocol messages (or chaff) at some higher layers and you
can't tell for sure at layer N. So I think you need to not say
"message" as if there's a visible mapping from higher layers
to the layer at which you're observing.

> 
>> Also, I think you need to explicitly include protocol headers at
>> the levels below the one at which the last confidentiality service
>> was applied as those also expose information and are not clearly
>> "protocol messages" for the protocol that is of concern to the
>> analyst.
> 
>> Information leakage may also depend on the observer knowing about
>> machine details, e.g. if the bad actor is to take advantage of
>> inter-packet timing to infer higher lay protocol features.
> 
> In practice, everything about the wire image can be correlated with
> everything else the observer knows (note that we explicitly avoid
> assigning intent to this observer, because this document is scoped to
> the properties of the *image* itself, agnostic of threat model,
> though this lack of pejorative terminology should not be taken as a
> value judgement). We can add a note to this effect to the last
> paragraph of section 3.

Again, I'm not sure that we have the right abstraction. An
observer who knows more about the endpoint machinery can infer
a lot more from the bits they observe.

> 
>> Lastly, (for now:-) and as reflected below (and in your text),
>> related protocols (like DHCP or port 53 DNS) can expose
>> information, so I think the useful concept here involves more bits,
>> timing, flows and peers than your definition.
>> 
>> - "From the point of view of a passive observer, the wire image of
>> a single protocol is rarely seen in isolation." To me that implies
>> that you're considering the wrong abstraction but perhaps that's
>> debatable. Was that debated? If so, are there records of that
>> debate? (This partly replicates one of the points above.
> 
> I don't think that the issue is that we're using the wrong
> abstraction, but I do think we need to dig into it a bit deeper:
> first, the wire image should be considered at each layer (as you say)
> with the caveat that the observer always sees everything on its
> "portion" of the wire; second, this implies that different observers
> will see different things. This also leads to a less clunky
> formulation of what I think you mean by "extent" below. We'll work on
> this.

Grand. (Mind you I do think that means the current draft does
have the wrong abstraction, but let's see how it develops.)

>> information in the wire image." Not sure that's correct, even with
>> your (IMO-broken:-) definition - the "it" there being cryptography,
>> one could define a ciphersuite so that it adds chaff messages and
>> not only padding, so I think the "cannot" is incorrect.
> 
> I'd argue that protocol-level anti-analysis features due to chaff
> data etc are features of some aspect of the protocol other than the
> ciphersuite, but I admit I may not be up to date on what the scope of
> a ciphersuite can be.

For the purposes of this draft, I figure you want to be thinking
not just about current (e.g. TLS) ciphersuites, but rather about
what higher layers could do in future as well. E.g. maybe it'd
help if you think about the higher layer using Tor and not just
QUIC or HTTPS?

> 
>> Padding and cover traffic are generally a matter of relative
>> efficiency and not absolute. I think AEAD ciphers may also
>> contradict this statement as there is nothing to prevent a layer 4
>> AEAD using layer 3 or 2 headers as part of the additional data.
>> (Might be unwise, but could be done, so "cannot" isn't right I
>> think.)
> 
> See above -- I think this is an aspect of this definition being
> fuzzier about layering than it should be, and we should definitely be
> more explicit about it.

Grand.

> 
>> - "While packets cannot be made smaller than their information
>> content,..." - I'm not sure if this is correct and perhaps again
>> reflects a problem with definitions. With MPTCP the packets visible
>> to some observers may be smaller than the information content of
>> the exchange between the endpoints. I guess the same is true
>> whenever there are any OOB possibilities.
> 
> I think this statement is a tautology when taken together with the
> definition of Shannon entropy, but I take your point that the
> exchange visible in the wire image of a given set of packets (which
> will often be grouped by 5/6-tuple flows, as flows are generally how
> forwarding works) may be less than the total end-to-end operation.
> Since an observer may not even know about these OOB possibilities,
> though, I'm not sure how this document should address them.

I suspect you need to say what kind of observer we're dealing
with - could be omniscient, could be limited to one layer N
path, could be assumed to see all paths involving one layer N
endpoint etc.

> 
>> - 3.2: "impossible" isn't correct. We do know there are MITM boxen
>> in the real world for example. I think that may invalidate the
>> subsequent "solely" conclusion, as those boxen can often modify
>> messages or spoof.
> 
> Cryptographic integrity protection in a two-party protocol that
> allows modification by on-path devices is, IMO, not cryptographic
> integrity protection, so again by definition I'm not sure I agree. We
> should be more explicit about our assumptions here though.

I'm not sure what's the right thing here myself tbh. It may make
sense to say that one cannot derive any reliable conclusions from
the concept (of a wire image) in the presence of a MITM? Not sure
though.

> 
>> - "Integrity protection can only practically be applied to the
>> sequence of bits in each packet," seems incorrect. I once wrote
>> code that signed the first N bits of an N byte message and have
>> seen similar bugs, so integrity can clearly be applied to subsets
>> of those bits. I'm also not sure your text matches a TESLA-like
>> scheme.
> 
> I'm not sure we understand this sentence the same way -- the intent
> here is to day that you cannot integrity protect the order of the
> packets, 

Sure you can. If some of the bits in the wire image are a
digitally signed email for example, split into multiple
packets at the observer's layer, then changes in ordering
could be detected. Again, I think the issue here is down to
the current definition assuming that the ciphertext packets
are more like HTTPS or QUIC ciphertext, when they could be
more exotic.

> or the interpacket timing, since they will change as the
> packets go thorough the network.
> 
> I'd have to look into TESLA in order to be able to comment
> intelligently on it. I don't suspect I'll have a chance to do that
> this month.

No probs. It's a bit of an outlier I guess but worth thinking
about.

> 
>> - Since I mentioned TESLA, IP multicast seems not to have been
>> considered here - was it? How about message replication at other
>> layers?
> 
> This draft concerns itself with what can be seen (at a single point,
> which should be made more concrete, yes). ISTM you're asking
> questions that are aimed at teasing out a threat model related to the
> thing you talk about below. I'm not sure that's this document but I
> could be wrong.

Not so much a threat model, I'm more wondering here what would
be the wire image of e.g. MPTCP, or say if I had a DTN where
bundle agents do spray and wait or something. (The latter being
a much more theoretical concern admittedly.) In such cases, I'd
say that a useful definition of wire image would depend on where
and when an observer can see bits going by.

>> the "extent" of a wire image seems to me to deserve an equally
>> precise definition as the wire image itself. I'm not sure which is
>> really more interesting - given that I disagree with aspects of the
>> current definition of the latter, and there's no definition of the
>> former at all, I'm not sure if we can easily argue this. (Could be
>> that the idea of defining invariants is a good approach. Not saying
>> it isn't, just not sure.) I think there may be an interesting thing
>> to define here that's like what I think you mean by "extent." 
>> Intuitively it seems there should be a useful thing to define that
>> encompasses all of the bits sent anywhere due to the playing a
>> protocol-role and emitting a (minimally defined) "wire image" of a
>> specific layer-N protocol.
> 
> I think we understand different things by "extent" here 

Yeah, I think I'm asking for something new here.

> -- the text
> in 3.3.1 refers to the control that protocol designers have over how
> on-path observers can/will likely interact with a protocol's wire
> image, and "extent" refers only to "what portion" of the wire image
> will be used. You're right that this is a little weak, in that the
> reduction is in no way secure, and requires a rational model of the
> on-path observer.
> 
> What you seem to be interpreting "extent" to mean in this comment is
> different, and is actually more interesting. To stretch the analogy
> implied by "wire image", I think what you're describing is analogous
> to a long exposure of a wire image in motion: as an observer sees
> multiple packets, more information may accumulate. This is worth
> thinking about, but I'm not sure I have my head around it yet.

Yep, something like that. Or some concept like the closure of
a set.

>> Again I think the broken definitions render this moot, but this
>> seems to conflate ideas about "invariants" with the "wire image" in
>> ways that assume both are much more well-defined than I think is
>> the case.
>> 
>> - 3.3.2: I don't know how a protocol receiver can ever handle
>> "veracity"
> 
> First, it's the observer that is trying to determine whether the
> information in the wire image is accurate, not the receiver; 

Fair enough. You're right I should've said observer.

> this
> paragraph attempts to capture the fact that processes that currently
> treat unencrypted wire image information as genuine cannot continue
> to do so with engineered wire image information. For example, you
> can't change the meaning of the TCP SEQ and ACK fields without
> changing the end-to-end operation of the protocol, while an
> engineered wire image of an encrypted protocol can easily agree on
> alternate semantics end-to-end.

I'd say just not using terms like "veracity" would help:-)

> 
> This text can probably be clarified; I'm open to suggestions, and
> pull requests are cheerfully accepted at
> https://github.com/britram/draft-trammell-wire-image/

I suspect I'd need to have a f2f chat/beer with you before
a PR would be so useful but let's see where we end up with
this thread.

> 
>> - There's a bunch of text that seems sensible but where I'm not
>> sure, given the definitional issues. Most of it, looks ok though.
>> 
>> - Lastly, if the IAB published this as-is, the sky won't fall. But
>> I think the IAB will look a little less wise.
> 

On 11/09/18 03:16, Brian E Carpenter wrote:> On 2018-09-06 14:01,
Stephen Farrell wrote:
>>
>> Hiya,
>>
>> (cc'ing [email-masked] - I'm not keen that discussion of such IAB
>> drafts be banished to [email-masked]:-)
>
> I haven't changed the Cc list, but I respectfully disagree. I don't
> see that list as banishment; anyone can join and it's archived, but
> it doesn't suffer the noise level of [email-masked]
>
> As a technical comment, I'd like to mention an extreme version of
> wire image. The only thing needed to deliver an IP packet to its
> destination is the destination address. So the minimal wire image of
> a packet is the destination address followed by some number of
> encrypted bits. [Not my invention: Jon Crowcroft's unpublished
> article on Sourceless Network Architecture points out that the IP
> source address is redundant for the delivery of packets.]
>
> Now this has some minor disadvantages (no diffserv field, no flow
> label, no intermediate ICMP replies, etc.) but from the privacy point
> of view, it's hard to do better at the single packet level. You can
> still do some temporal analysis, but most of the normal clues are
> missing since you have no tuple to track, so it will be extremely
> hard to assign packets to flows.
>
> Also, with the message body being pseudorandom, you cannot deduce
> anything about the protocol, ports, or payload size, or even whether
> the packet is just noise to confuse temporal analysis.
>
> I think this sets a baseline for discussion of wire images: you can't
> have *less* of an image than this.

Not sure I quite agree that this is the minimal wire image. ISTM
that e.g. running Tor over MPTCP with a observer that can't see
all paths seems like it results in a less complete wire image.
But as I argued above, I think that's down to needing a better
definition of wire image for it to be a more generally useful
concept.

Cheers,
S.

> How much do we sacrifice of this
> baseline privacy by not encrypting other parts of the IP header, for
> example?
>
> (I do wonder about this as RFC material. Somehow it seems a bit more
> like a CCR paper to me.)
>
> Brian
>
>
>
>
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Sep 2018 15:55:18 -0700

i am less comfortable with hiding this critical discussion off in some
obscure mailing list.  we already have enough problems with closed iab
discussions.

> Sure. But isn't it the move to encrypt more that's motivating this and
> other drafts? If so, then I think ack'ing that there are valid and
> pressing motivations for that move is needed. If there are other
> motivations, those aren't clear to me at least and therefore probably
> also deserve a mention. We've seen (with Kathleen and Al's draft),
> that some people (not the authors here) do quote drafts like this when
> arguing against more confidentiality, so I think this draft, and
> similar ones, really ought say that we do need more use of
> confidentiality, and not just assume that that's accepted by all
> readers. Yes, that only needs to be a sentence or two and some
> reference, but I do think it needs to be there.

extremely much so, tyvm.  to me, this is *the* critical issue here.

the other issues we can ietf to death, like trains to maastricht or
visas to bangkok.  but making clear that strong encryption is here to
stay and that is a good thing is principle.

randy

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 Sep 2018 21:04:58 -0400

--On Friday, September 14, 2018 15:55 -0700 Randy Bush
<[email-masked]> wrote:

> i am less comfortable with hiding this critical discussion off
> in some obscure mailing list.  we already have enough problems
> with closed iab discussions.

+1 

> but making clear that strong
> encryption is here to stay and that is a good thing is
> principle.

Yes, I certainly hope so.   However, I also think we need to be
aware that, while I hope history doesn't repeat itself in this
case, the historical trend ("historical" = centuries, not
Internet time) has been that, if whatever passes for strong
encryption at the time starts becoming sufficiently intrusive,
governments have often responded by banning encryption entirely
and trying to enforce those bans.   That potentially provides a
new way to fragment the Internet with a boundary between those
who use strong encryption and those who are put at considerable
risk by trying to do so.   I'm still prepared to believe that
strong encryption is a good thing in principle, but we should
also all be careful what we wish for.

   Cassandra

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Sat, 15 Sep 2018 10:49:40 +0200

> On 15 Sep 2018, at 00:55, Randy Bush <[email-masked]> wrote:

>> also deserve a mention.
>> We've seen (with Kathleen and Al's draft),

Ok. The motivation for this draft is indeed he increasing deployment and coverage of encryption down the stack, which we take as a given. A few sentences to make this context clear could be useful.

> stay and that is a good thing is principle.

The whole point of this line of work is to define a solution space for the (technical) problems that arise when “strong encryption is here to stay”, and follows from its statement that weaning various communities off an addiction to clear text is an important part of moving the Internet to a default-confidential stance (see https://www.iab.org/documents/correspondence-reports-documents/2014-2/iab-statement-on-internet-confidentiality/). 

Cheers,

Brian

---

From: Randy Bush <[email-masked]>
Date: Sat, 15 Sep 2018 09:55:13 -0700

> Ok. The motivation for this draft is indeed he increasing deployment
> and coverage of encryption down the stack, which we take as a given. A
> few sentences to make this context clear could be useful.

i kind of liked just saying that strong encryption is becoming
ubiquitous, is here to stay, and the ietf thinks that is a good thing.
this has consequences for applications and middleboxes that have grown
used to being able to see the traffic in cleartext.

> The whole point of this line of work is to define a solution space for
> the (technical) problems that arise when “strong encryption is here to
> stay”

for some of the consequences, there is no "solution."  this may not be a
bug.

randy

---

From: Christian Huitema <[email-masked]>
Date: Sat, 15 Sep 2018 10:08:31 -0700

> for some of the consequences, there is no "solution."  this may not be a

We discussed that a lot when reviewing Kathleen's draft. There is a grab bag of stuff that have been put under the "network management" umbrella, from monitoring whether a given path is still working to being able to insert or replace ads. There is no doubt that some of that is legit and useful. The question then is where to place the line between "yes that's useful" and "forget about it". And then, how to best accommodate the useful part when most of the packet is encrypted.

-- Christian Huitema

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 15 Sep 2018 17:21:25 -0500

On Sat, Sep 15, 2018, 12:09 Christian Huitema <[email-masked]> wrote:

> We discussed that a lot when reviewing Kathleen's draft. There is a grab
> bag of stuff that have been put under the "network management" umbrella,
> from monitoring whether a given path is still working to being able to
> insert or replace ads. There is no doubt that some of that is legit and
> useful. The question then is where to place the line between "yes that's
> useful" and "forget about it". And then, how to best accommodate the useful
> part when most of the packet is encrypted.
>

Speaking as the AD who approved the SPUD BOF[1], the ACCORD BOF[2], and the
PLUS BOF[3], and speaking only from a TSV perspective, I believe the status
is unchanged today from the day that we walked out of the PLUS BOF, which
is that the IETF is deadlocked and will remain deadlocked until one of two
things happens.

   - Either we deliver the kind of transport performance we want to achieve
   for QUIC, using only end-to-end mechanisms, with no involvement from
   network elements, which leads us in one direction, or
   - We can't do that, which leads in a different direction.

I see no reason to debate this further until one of those two things
happen, from a TSV perspective. Your mileage may vary, of course,
especially if you're traveling at another level of the protocol stack ...

It's also worth pointing out that Nomcom has issued their third call for
nominations for the IESG, IAB, and IETF Chair positions, if someone has a
different plan ...

Otherwise, enjoy your weekends, of course. And make good choices ...

Spencer, the eternally outgoing TSV AD

p.s. For those in other rooms at the time, so who have useful alibis,

   - [1] SPUD was https://www.ietf.org/proceedings/92/spud.html.
   - [2] ACCORD was https://www.ietf.org/proceedings/95/accord.html.
   - [3] PLUS was https://www.ietf.org/proceedings/96/plus.html, but
   honestly, must be seen at
   http://oldrecs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_PLUS&chapter=chapter_1
   to be appreciated.

-- Christian Huitema
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Sep 2018 23:54:30 +0100

Hiya,

> is that the IETF is deadlocked and will remain deadlocked until one of two

I don't think deadlock is the right way to think about this.
That sort of implies there are two reasonable positions that
are at loggerheads. I think there are more moving parts than
that. More optimistically, I don't see good reasons to be at
loggerheads at all - there clearly is some work to do figuring
out the consequences of more confidentiality, and hopefully
this draft, if well done, will help inform such analysis.

S.