[openpgp] Need to publish bis-05

[Werner Koch]

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 ***@gitlab.com/openpgp-wg/rfc4880bis


Shalom-Salam,

Werner


--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

[Hanno Böck]

Hi,

On Tue, 24 Jul 2018 09:33:21 +0200

Post by Werner Koch
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.

This does not seem to reflect the lessons to be learned from efail.

I think it is very important to hard-restrict the chunk size to a
manageable size, also manageable for small devices (i.e. even 128 mb is
far too much), so that authenticating before any output is produced is
always feasible.

I.e. I propose to change it to a MUST NOT and to have a smaller
maximum chunk size (I think something in the kilobyte range is a good
choice).

[Werner Koch]

Post by Hanno Böck
This does not seem to reflect the lessons to be learned from efail.

Sorry, that remark does not make any sense. We have explained in detail
why it was bot possible to hard fail on MDC and we can do this only know
with the “support” of EFFail. The major points of Efail are bad
integration and in-correct use of tools. You can shoot into your foot
even with simple standard toools like cat.

Post by Hanno Böck
I think it is very important to hard-restrict the chunk size to a
manageable size, also manageable for small devices (i.e. even 128 mb is
far too much), so that authenticating before any output is produced is

If you have a small device you don't have a way to store large amounts
of data and thus even a lower limit does not make sense because it won't
be reached. The only option an implementation hast to trow up the hands
and say : message too large to decrypt. That is even before checking the
message.

Post by Hanno Böck
I.e. I propose to change it to a MUST NOT and to have a smaller
maximum chunk size (I think something in the kilobyte range is a good

A kilobyte is - sorry I have no other words for this - stupid. We are
talking about gigs and not a single memory page. I think 128 MiB is a
good compromise - in particular for small device which suffer more for
the expensive steps of the chunk processing. For large amounts of data
that is acceptable high.


Salam-Shalom,

Werner

[Marcus Brinkmann]

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.

Post by Werner Koch
Hi
--8<---------------cut here---------------start------------->8---
+ 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.
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.
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.
- 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,
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---
Shalom-Salam,
Werner
--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
https://www.ietf.org/mailman/listinfo/openpgp

[brian m. carlson]

Post by Marcus Brinkmann
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
* 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.

I agree that we should lower this. I happen to think the overhead
involved in 64 KiB chunks isn't that significant, but if that's a
concern, we could raise it to 1 MiB. I'd like to point out, though,
that I suggested a smaller chunk size because that's what TLS has
traditionally done: most TLS implementations don't allow the full 16 MiB
chunk size for DoS reasons.

Even if we do allow large chunk sizes, I expect most implementations
will limit them for security and DoS reasons, in which case we'll end up
with the same effective behavior, but poorer interoperability.

On almost any reasonable system with AES acceleration, encryption
throughput is faster than disk or gigabit network, so I hardly think the
encryption overhead is painful here, even for smaller ARM systems.

[Benjamin Kaduk]

Post by brian m. carlson
I agree that we should lower this. I happen to think the overhead
involved in 64 KiB chunks isn't that significant, but if that's a
concern, we could raise it to 1 MiB. I'd like to point out, though,
that I suggested a smaller chunk size because that's what TLS has
traditionally done: most TLS implementations don't allow the full 16 MiB
chunk size for DoS reasons.

Can you expound on this more? It does not match my understanding of the
TLS ecosystem. (Also, isn't it 16K?)

Thanks,

Ben

Post by brian m. carlson
Even if we do allow large chunk sizes, I expect most implementations
will limit them for security and DoS reasons, in which case we'll end up
with the same effective behavior, but poorer interoperability.
On almost any reasonable system with AES acceleration, encryption
throughput is faster than disk or gigabit network, so I hardly think the
encryption overhead is painful here, even for smaller ARM systems.

[brian m. carlson]

Post by Benjamin Kaduk

Post by brian m. carlson
I agree that we should lower this. I happen to think the overhead
involved in 64 KiB chunks isn't that significant, but if that's a
concern, we could raise it to 1 MiB. I'd like to point out, though,
that I suggested a smaller chunk size because that's what TLS has
traditionally done: most TLS implementations don't allow the full 16 MiB
chunk size for DoS reasons.

Can you expound on this more? It does not match my understanding of the
TLS ecosystem. (Also, isn't it 16K?)

Ah, I believe I was misremembering. The chunk size for encryption is
indeed 2^14 bytes; I think I was remembering the handshake messages,
which are 2^24 bytes. OpenSSL at least does limit the size of the
handshake messages, although, as you pointed out, not encrypted
messages.

Regardless, my (mistaken) impression was the reason for the original
decision. I think we should pick values that are safe for all
reasonable implementations, including smaller ones, and where possible,
be willing to see what other protocol specifiers have done and learn
from their wisdom and mistakes.

[Benjamin Kaduk]

Post by brian m. carlson

Post by Benjamin Kaduk

Post by brian m. carlson
I agree that we should lower this. I happen to think the overhead
involved in 64 KiB chunks isn't that significant, but if that's a
concern, we could raise it to 1 MiB. I'd like to point out, though,
that I suggested a smaller chunk size because that's what TLS has
traditionally done: most TLS implementations don't allow the full 16 MiB
chunk size for DoS reasons.

Can you expound on this more? It does not match my understanding of the
TLS ecosystem. (Also, isn't it 16K?)

Ah, I believe I was misremembering. The chunk size for encryption is
indeed 2^14 bytes; I think I was remembering the handshake messages,
which are 2^24 bytes. OpenSSL at least does limit the size of the
handshake messages, although, as you pointed out, not encrypted
messages.

Thanks for clarifying (and looking it up!).

Post by brian m. carlson
Regardless, my (mistaken) impression was the reason for the original
decision. I think we should pick values that are safe for all
reasonable implementations, including smaller ones, and where possible,
be willing to see what other protocol specifiers have done and learn
from their wisdom and mistakes.

FWIW, I agree that we should have values safe for all reasonable
implementations.

-Ben