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

[Brian Trammell (IETF) <[e-mail]>]

hi Stephen,

> On 6 Sep 2018, at 04:01, Stephen Farrell <[e-mail]> wrote:
> 
> Signed PGP part
> 
> Hiya,
> 
> (cc'ing [e-mail] - I'm not keen that discussion of such
> IAB drafts be banished to [e-mail]:-)
> 
> 
> 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.

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

> 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.

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.

> 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
>> [e-mail] and [e-mail].
>> 
>> 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.)

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.

> - 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)?

> 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.

> 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.

Yep, this is a good point.

> 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.

> 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.

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.

> - "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.

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
> 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.

> - "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.

> - 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.

> - "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, 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.

> - 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.

> - (skipping some...) 3.1.1:

I presume you mean 3.3.1 here.

> 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 -- 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.

> - "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"

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/

> - 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.

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

Cheers,

Brian