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

[Stephen Farrell <[e-mail]>]

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.

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

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