Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks

[Stephan Neuhaus <[e-mail]>]

On 2016-07-29 19:12, Tom Herbert wrote:
> On Fri, Jul 29, 2016 at 9:29 AM, Brian Trammell <[e-mail]> wrote:
>>
>> Nope. I don't need to touch the endpoints at all for an injection attack. I just need one middlebox near the source to rewrite packets, and (possibly) another one downstream to pick up the signals. (Okay, I might need to hack the kernel on my middleboxes. But I get to do that. They're mine. :) )
>>
> Except that middelboxes presumably do not have access to the encrypted
> data so the amount of information they can derive from the packet is
> limited. The problem is when the application or user is being coerced
> and there is a readily available mechanism that facilitates that. For
> example, it seems very possible that a rich signaling mechanism
> implemented by the user could be used to enforce a backdoor to
> encryption.

Now I'm confused. I thought that the situation that Brian was talking
about is middleboxes fiddling with the packet headers, which are in
plaintext, and not with the packet's payload which, as you say, may be
encrypted. You seem to be saying that the amount of information that can
be extracted from plaintext transport headers is limited, is that correct?

Brian is also talking about the path; you seem to be talking about the
endpoints, is that correct?

If both these assumptions are correct, then I'd like to make three
points. (If they're both wrong, please stop reading. If one is right and
one is wrong, read only half of what follows.  You choose which half :-) )

First, I do not agree that the amount of information in the transport
headers is limited, which I assume means "of limited value". It's
classic metadata and should be protected, if possible. That transport
header is seen by many more boxes than the plaintext of the encrypted
payload and thus the probability of someone siphoning it off are that
much larger, precisely because it is valuable.

Second, I'm not sure in what way "a rich signaling mechanism
implemented by the user could be used to enforce a backdoor to
encryption" or rather, I'm not sure how that is a problem enabled
specifically by PLUS. If the "user" (which I understand to be an
application running on top of a networking stack) wants to "backdoor its
encryption" (i.e., leak key material), it can already do so today. For
example, a suitably modified TLS library could stash the master secret
at the end of a TLS message (may work with many applications, even
without an equally compromised TLS library on the other end). Or it
could silently always use DUAL_EC_DRBG (always works). Or ... Many of
these would go undetected for a long time. The upshot is: once your
endpoint is compromised, all bets are off anyway.

And finally, have the impression that you think that PLUS is going to be
this gigantic free-for-all, where every Joe, Dick, and Harry can
annotate a packet in any way they please. If I understood the PLUS
proponents correctly, this will not be the case. PLUS fields will be
limited in number, space, and semantics, and they will (for the most
part) be integrity-protected so that nothing on the path can fiddle with
them without anyone noticing.

To summarise: 1) If your endpoint is compromised, you're screwed anyway.
2) The total amount space that's available for undetected fiddling by a
middlebox will perhaps not be zero, but it will be less than it is today.

Fun,

Stephan

[Full disclosure: I'm working with Brian and Mirja on the MAMI project.]