Re: [Stackevo] Fwd: New Version Notification for draft-hardie-path-signals-02.txt

[Eliot Lear <[e-mail]>]

Hi and happy new year to all,

On 02.01.18 00:14, Martin Thomson wrote:
> I also think that we should explicitly identify not encrypting as an
> option.  We could still have integrity protection.  Of course, we
> should then make it clear that rampant misguided inference is why we
> are encrypting.  I'd put something in the introduction to Section 4
> there.

Speaking as someone who works with a company that has done some of that
interference, I am aware that some of it was misguided, but when it
comes to writing this down, let's mind the tone.  There are reasons that
firewalls came to be, and continue to be important.  We've now in the
last two months had two major examples of how endpoints aren't in a
position to protect themselves on their own, and probably never will
be.  I'm not suggesting that we replay that entire discussion this
document, but much of the "interference" is precisely what the
administrator intends, and it is not misguided.

>
> I have one consideration to add, probably to security considerations
> (more on that below).  Explicit signals can be disconnected from the
> protocol signaling machinery.  Doing so might be necessary to avoid
> path entities inferring more from the signal than is intended.  If
> QUIC takes a spin bit, that's a clear example of where we take RTT
> information and signal that, but we separate that signal from all of
> the rich acknowledgment information the protocol really needs.
> However, this split creates a potential for those signals to be
> incorrect or even for them to be falsified, presumably with the intent
> of manipulating path entities in some way.
>
> I don't think that we need any specific mitigation, but we should
> recognize that this is a natural consequence of the recommendations in
> the draft.  That isn't strictly a negative outcome either.  One
> conceivable - but actually highly unlikely - outcome of designing
> explicit signals is that intermediaries might insist on a certain set
> of signals before a packet is allowed to pass ("give me SNI or I kill
> your flow").  A signal that isn't directly coupled to the actual
> protocol machinery can be falsified to appease a middlebox, even in
> cases where the endpoint might otherwise prefer not to provide the
> information.  I wouldn't include all that exposition though, just note
> that falsification is possible, without affecting the e2e protocol
> operation.

I think it's probably worth expanding this point.  Falsification of
signaling means that middleboxes will not trust it.  To what degree that
holds true will depend on circumstances, but if it becomes the general
case, one has to ask what the point of including it was in the first
place?  That way lies dragons.

Eliot