Werner Koch wrote:
On Wed, 27 Oct 2004 12:30:37 +0100, Ian Grigg said:
When was this feature introduced? I suspect enough time has
passed, and enough implementations are doing it that we can
move this to a MUST. It is certainly the standard that these
days, protocols should be MAC'd or MDC's in some fashion.
About summer 2000 after a predecessor version in spring 1999.
problem. Likewise, the absence of an MDC packet, or an MDC
packet in any position other than the end of the plaintext,
also represent message modifications and MUST be treated as
a security problem. These events SHOULD be reported to the
It is a possible security problem. There is far too many encrypted
data without the MDC packet in use. A strong warning is okay, but a
severe error won't be good.
If we would flag that as an error, the implementation should not even
output the decrypted messages which clearly is not acceptable to most
users trying to restore their backup or reading an archived mail. An
implementation may still decide what to do but the standard should not
enforce it.
Backups .. a good point. Hold on though.
If I have created a backup in pre-MDC times, I will
have used the previous packet layout, Tag 9. So
I can read it as is, as a Tag 9.
Nothing I am suggesting should be taken to say
that Tag 9 should be phased out or made deprecated.
Rather, what I am suggesting is that implementations
MUST be able to read Tag 18s and when they come across
them, they MUST follow the security rules.
(Even if were to make sending/encrypting a MUST, I
don't think we are at the point of saying that an
implementation MUST NOT send out Tag 9s.)
OTOH, are you suggesting that some implementations
created Tag 18s without correct MDCs? That seems to
be an error, and those should be treated as failures,
as described, no?
Does that make it clearer?
iang
PS: 5.7. Symmetrically Encrypted Data Packet (Tag 9)