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: > hi Stephen, > >> On 6 Sep 2018, at 04:01, Stephen Farrell >> <stephen.farrell@xxxxxxxxx> wrote: >> >> Signed PGP part >> >> 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. > > 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. 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.) > >> 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.) > > 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. > > 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. 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. > > 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. Grand. (Mind you I do think that means the current draft does have the wrong abstraction, but let's see how it develops.) > >> - "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. 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. > >> - (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 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. > >> - "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; 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. > > The intent, of course, is to incorporate community feedback; many > thanks for yours. On 11/09/18 03:16, Brian E Carpenter wrote:> On 2018-09-06 14:01, Stephen Farrell wrote: >> >> Hiya, >> >> (cc'ing ietf@xxxxxxxx - I'm not keen that discussion of such IAB >> drafts be banished to architecture-discuss@xxxxxxxx:-) > > 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 ietf@xxxxxxxx > > 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 > > > > >
Attachment:
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
