Re: [openpgp] Need to publish bis-05

[Marcus Brinkmann <[e-mail]>]

The new wording for the AEAD chunk size makes it logically impossible to
write a conforming implementation that guarantees to never output or
process unauthenticated plaintext.  This is a serious security concern,
which is addressed by state of the art standards like TLS 1.3, and for
which there was rough consensus on this list.

Here is the reason that it is impossible for conforming implementations
to always be secure:

* The draft requires implementations to support chunks up to 4 Exibyte
("An implementation MUST support chunk size octets with values from 0 to
56").
* It is impossible to buffer 4 Exbyte on any device or system that is
not planet-scale.

Thus, any conforming implementation must have a chunk size that must be
supported for which it can not buffer the whole chunk.  For that chunk
size, the implementation must either abort (resulting in non-conforming
behaviour) or output unauthenticated data (resulting in non-secure
behaviour).

This is in stark contrast to the original proposal, which had valid
chunk sizes between 64 Byte and 64 KiB, all of which can be supported
securely on a wide range of devices.  Multiple people expressed support
for that approach.

On 07/24/2018 09:33 AM, Werner Koch wrote:
> Hi
> 
> -04 is about to expire.  These will be the changes in -05:
> 
> --8<---------------cut here---------------start------------->8---
> ** New key flag:
> 
> #  The second octet:
> 
> +  0x04 - This key may be used as an additional decryption subkey (ADSK).
> 
> # The idea is that implementations will also encrypt to a second subkey
> # which for example is used on a second device.  I am not sure whether
> # this is suitable solution and makes much sense so this is intended as a
> # bait for discussion.
> 
> ** Deprecation of Symmetrically Encrypted Data Packet
> 
> + This packet is obsolete.  An implementation MUST not create this
> + packet.  An implementation MAY process such a packet but it MUST
> + return a clear diagnostic that a non-integrity protected packet has
> + been processed.  The implementation SHOULD also return an error in
> + this case and stop processing.
> 
> ** Limit the chunk size of  AEAD packets:
> 
>   An implementation MUST support chunk size octets with values from 0 to
>   56.  Chunk size octets with other values are reserved for future
> + extensions.  Implementations SHOULD NOT create data with a chunk size
> + octet value larger than 21 (128 MiB chunks) to facilitate buffering of
> + not yet authenticated plaintext.
> 
> ** Explict warning reading the AEAD IV:
> 
>   A new random initialization vector MUST be used for each message.
> + Failure to do so for each message will lead to a catastrophic failure
> + depending on the used AEAD mode.
> 
> ** More pressure to use AEAD:
> 
> -    This attack can be defeated by the use of Modification Detection,
> +    This attack can be defeated by the use of modification detection,
>      provided that the implementation does not let the user naively
> -    return the data to the attacker.  An implementation MUST treat an MDC
> -    failure as a security problem, not merely a data problem.
> -
> -    In either case, the implementation MAY allow the user access to the
> -    erroneous data, but MUST warn the user as to potential security
> -    problems should that data be returned to the sender.
> +    return the data to the attacker.  The modification detection is
> +    prefereabble implemented by using the AEAD Encrypted Data Packet
> +    and only if the recipients don't supports this by use of the
> +    Symmmetric Encrypted and Integrity Protected Data Packet.  An
> +    implementation MUST treat an authentication or MDC failure as a
> +    security problem, not merely a data problem.
> +
> +    In either case, the implementation SHOULD NOT allow the user
> +    access to the erroneous data, and MUST warn the user as to
> +    potential security problems should that data be returned to the
> +    sender.
> 
> and changed the following suggestion to read
> 
>     permits someone to trick a user to decrypt a message.  Consequently,
>     it is important that:
> 
>       1.  Implementers treat authentication errors, MDC errors,
>           decompression failures or no use of MDC or AEAD as security
>           problems.
> 
>       2.  Implementers implement AEAD with all due speed and encourage
>           its spread.
> 
>       3.  Users migrate to implementations that support AEAD
>           encryption with all due speed.
> 
> 
> ** Clarify / cleanup OCB section, add EAX and OCB test vectors
> --8<---------------cut here---------------end--------------->8---
> 
> 
> See also [e-mail]/openpgp-wg/rfc4880bis
> 
> 
> Shalom-Salam,
> 
>    Werner
> 
> 
> --
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
> 
> 
> 
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp
>