[p2p-hackers] amicima's MFP - preannouncement

[Matthew Kaufman]

> Matthew,
> 
> Thanks for a detailed reply. I guess my main concern with 
> security portion of your protocol is that it does not follow 
> certain design properties found in nearly all commonly used 
> transport protocols like SSL/TLS, SSH2, ESP as well as a 
> handful of others like IKE, JFK, etc.

It is best to compare this against IPSEC, rather than something like SSL,
because we are operating without the ordered-and-reliable delivery that
something like SSL depends on. (For instance, we can't have an internal
sequence number that is not transmitted that must match at the far end, like
SSH2 has, because we expect out-of-order delivery and lost packets to occur,
and we can't just run all the hypothetical sequence numbers through an HMAC
algorithm)
 
> Few I can think of off hand are -
> 
> * the use of MACs. Relying on validity marker in plaintext 
> payload to detect corrupted packets is expensive 
> computationally-wise in a worst case scenario, while 
> HMAC-based authentication costs pennies.

Not true. See appendix B of rfc3723 (or other equivalent sources). For a
1024 byte packet, AES-CBC takes 27.97 cycles/byte and HMAC-SHA1 takes 24.71
cycles/byte. And we need good performance in the "not being attacked" case
as well, so the real comparison is:

HMAC in use: 24.71 cycles/byte when being attacked (discard after HMAC,
before decrypt),
             24.71 + 27.97 = 52.68 cycles/byte when not being attacked (the
"expected" case).

HMAC not in use: 27.97 cycles/byte when being attacked,
                 27.97 cycles/byte (the same) when not being attacked.

Summary is that if you run SHA1 HMAC and AES, you save about 10% on cycles
when you're being attacked and you pay for that small savings by using
almost 90% more cycles when you're not.

> It also 'not good' from cryptographical perspective, but I 
> cannot comment on that (note though how SSH was switched to 
> using MACs in v2). Besides MACs are also required for implementing -
> 
> * replay protection, which involves tagging packets with 
> unique sequence numbers after the encryption but before the 
> authentication.

Replay protection can also be placed inside the encryption in a similar
fashion... The real question is, does putting it outside and using HMAC save
you cycles in the being-attacked case (so that you can discard replays prior
to decryption cost)? And the answer is "not enough, especially given the
penalty in the non-attack case".

Our flows have sequence numbers which prevent replay while a flow is active
(and once a session is torn down, replay is ineffective), and we also can
use the timestamp field for some additional replay protection. Because the
attacker cannot "see inside" other packets in order to guess at good
sequence numbers, we are better protected than TCP in this way, though not
quite as protected as the anti-replay provisions of IPSEC. We might add more
if we were convinced that it was necessary.

Modified packets can of course be detected not only by the checksum being
invalid, but also because it is unlikely that valid chunks would be found
and decoded, even if a valid checksum were accidentally generated by a
change to an encrypted packet.

> This way replayed or duplicate packets can be discarded 
> without wasting any time on decryption or authentication at all.

Well, you can't use the non-encrypted sequence number that you see until you
check the HMAC... And that has non-zero cost, as described above.
 
> * session key being derived in 'symmetrical way', when both 
> parties contribute to the key in equal degree.

This is a valid argument, and we have previously discussed this internally
and will again. The single issue that is caused by the asymmetry is that an
attacker who has compromised one host's private RSA key can (about half the
time, in a P2P environment... more or less in a client-server environment)
use that information to extract the session key that is chosen, whereas it
would require compromising both ends in order to extract a session key that
was chosen with symmetry. The difficulty is putting everything in the small
number of startup packets we have, and fitting those into non-fragmented
datagrams, but this is probably something that will be addressed because it
is a valid security concern in some threat cases.

> Basically security component of your protocol looks very 
> different from existing mature protocols. And I would suspect 
> that this will not facilitate adoption of MFP .. at least not 
> in its secured form.

It actually looks quite like IPSEC ESP without AH... Consider the session ID
as the security association identifier and go from there.

In reality, though, in order to determine if a secure network protocol is
right for your application, you must consider the threats that you are
protecting against, and compare that to the benefits. Is this as secure as
some other protocols? Probably not. Does it have numerous advantages for
certain applications? Absolutely. Will bugs be found in the first release of
the implementation? I sure hope so, so that we can fix them!

Matthew