Hi Neal,
On Tue, 2019-03-19 at 11:09 +0100, Neal H. Walfield wrote:
Can you please explain
how the MDC helps protect against ciphertext modification in the
streaming case, as that it still not clear to me.
RFC 4880 currently states in § 5.13:
Any failure of the MDC indicates that the message has been modified
and MUST be treated as a security problem.
Further down in the security section (§ 14):
An implementation MUST treat an
MDC failure as a security problem, not merely a data problem [...]
Consequently, it is important that:
1. Implementers treat MDC errors and decompression failures as
security problems.
There the MDC, if the spec is followed, indicates a security problem. I
guess that conversely, applications using OpenPGP thus ought to exercise
care when using that data which was flagged as having a security
problem. So that's how the MDC protects against modification of the
ciphertext.
Is that clear to you now?
Obviously, that didn't prevent consumers from ignoring that reported
security problem. But the spec cautions the use of the unauthenticated
data. That's arguably too weak and it should probably say to not use
unauthenticated data at all. And implementations probably shouldn't have
released plaintext early. Or, if the application really needs to access early
plaintext, because, say, it's running out of buffering capacity, then it needs
to be able to deal with the fact that the data may turn out to be bad.
AFAIU, the MDC itself is not the most elegant or efficient construction,
but works just about well enough to detect modified ciphertext.
As an aside which you all of you are probably aware of: The other,
bigger, problem with SEIP packets is that they it can be downgraded [1]
which then, AFAIU, served as a another motivation to move to AEAD [2].
While "authenticated prefixes" (if used correctly) would render certain
ciphertext modifications powerless, they still leave an application
susceptible to attacks if it is not prepared to defend against them.
Spontaneous examples that I can come up with are the script in the
backup that does "cp /foo /bar" where the attacker manages to cut off
the "bar" and causes havoc or a PDF with multiple xref tables where the
attacker manages the remove the last one. I'm sure there are more and
better examples. I appreciate that the bar is higher for an attacker to
mount this attack if you can only cut off at the end rather than modify
anything at free will.
At the end of the day, though, the application layer has to be able to
defend against such an attack. Now the question becomes whether
applications using OpenPGP are in such a position. Assuming that most
of them are would make things easy, but may be a bit far fetched. Yet,
forcing streaming onto every user and encouraging the release of
plaintext while the whole message has not yet been authenticated seems
to make that assumption. I thus dislike the proposed removal of the
option of not dividing a message into separately authenticated pieces.
I appreciate that the authenticated prefixes reduce the attack surface
of Efail style attacks when you really can't hold all of the message.
But they don't prevent the root cause of those attacks. Not using
unauthenticated plaintext (or parts thereof) would.
To that end, I like Vincent's idea of moving the discussion towards
fixing a chunk size for chunked mode but leaving support for a non-
chunked mode.
Cheers,
Tobi
1: https://mailarchive.ietf.org/arch/msg/openpgp/JLn7sL6TqikUf-cD34lN7kof7_A
2: https://mailarchive.ietf.org/arch/msg/openpgp/9uJYltQjfOaTKlnarJoDYnLXNzc
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp