Hiya, (cc'ing ietf@xxxxxxxx - I'm not keen that discussion of such IAB drafts be banished to architecture-discuss@xxxxxxxx:-) 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 > architecture-discuss@xxxxxxxx and iab@xxxxxxx. > > 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.
Attachment:
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
