On Mon, 18 Mar 2019 20:51:32 +0100,
Tobias Mueller wrote:
On Mon, 2019-03-18 at 11:53 +0100, Neal H. Walfield wrote:
For me, a plaintext is authenticated if the whole ciphertext could
be
successfully authenticated. Which seems to be very well in line with
the
definition you've linked to.
4880bis defines a chunking mechanism based on AEAD: the message is
split into multiple chunks. In 4880bis, AEAD operates on a per-chunk
basis. The chunking algorithm provides mechanisms for ensuring chunks
can't be reordered, detecting the end of the message, etc. Using AEAD
to decrypt a chunk authenticates that chunk's ciphertext; for a given
chunk, the decryption operation will either return the correct
plaintext, or it will return an error. This is exactly what RFC 5116
requires.
I beg to differ. Because, as you mention:
RFC 5116 doesn't discuss chunking; chunking is not AEAD.
Chunking is not AEAD. It's a protocol on top of AEAD messages that you
have to come up with. And then you have to implement it correctly. The
security guarantees that AEAD gives you, do not automatically apply to
your chunking scheme.
As you've said: Chunking is not AEAD. Hence, it cannot automatically be
in line with what RFC5116 demands.
The chunks use AEAD. So 5116 applies to the chunks. That means, for
a given chunk, either authenticated plaintext is returned or failure.
I don't see a contradiction.
You seem to think that AEAD's guarantees must apply to the whole
message. I disagree.
I'm glad you're saying this.
And yes, I think that proper AE means that the full message enjoys the
security guarantees of AE. Also because I am not aware of definitions
covering partially authenticated plaintext.
TLS is used by a few billion people. Let's just do what they do...
And I think that RFC5116
leans more towards full messages rather than trying to define security
guarantees for partial plaintext.
RFC 5116 only talks about AEAD. But these trade-offs are specifically
addressed by David McGrew, the author of 5116, here:
https://mailarchive.ietf.org/arch/msg/cfrg/_iVbSmVLW7nY82k8xZmuVFIX6cs
Fragmenting the plaintexts before applying AEAD requires that each
AEAD message be independently authenticated, and thus this technique
has more data/encapsulation overhead.
In his terminology, fragmentation is approximately the same as
chunking in our terminology. It seems to me, the he says AEAD is
applied to fragments/chunks, not the whole message, which is the
terminology that I've been using.
The whole thread, starting here,
https://mailarchive.ietf.org/arch/msg/cfrg/-lj3IEm9agpfgUOb2yX9JNrtrm8
is an interesting read. And, I think it generally supports my
position.
I further think getting as close to
proper AE as possible is a goal worth pursuing.
I think that if we accept your position, OpenPGP will have less
practical security.
You've repeatedly said that if an implementation doesn't want
authenticated plaintext, it is free to release unauthenticated
plaintext (e.g., "you are free to release unauthenticated plaintext as
much as you want",
734216a3ee1c0e252ecf0ad297be2cfdcb049c2e(_dot_)camel(_at_)cryptobitch(_dot_)de).
That's much, much worse than a possible truncation attack. And, David
McGrew agrees:
https://mailarchive.ietf.org/arch/msg/cfrg/_iVbSmVLW7nY82k8xZmuVFIX6cs
robustness against decryption misuse is a valuable property for an
AEAD algorithm to have. Nonetheless, it would be better if the
protocol using AEAD actually performed some sort of plaintext
fragmentation, if it can accommodate the overhead, because the
security would be better.
I agree it is useful, but it is not possible
when streaming.
If you absolutely must stream, then there is no way that you can buffer
the whole message, otherwise you wouldn't stream. I claim, however,
that in the vast majority of use-cases you don't have the requirement of
having to stream. As in, purely from a functional perspective, not from
an implementation perspective. Hence, imposing the concept of streaming
onto everybody somehow does not feel right.
Let's consider email, which is a common use case for OpenPGP. I like
that K-9 just downloads the first few kilobytes of each message. I
want K-9 to be able to continue to do that even when everyone is
encrypting their email. For that, I need an authenticated prefix.
Likewise, with a dropbox-like application, I'd like to be able to
preview the content. Again, I need an authenticated prefix.
I want to be able to stream archives and backups.
Pretty much the only case that I can think of that chunking is not
useful is for verifying software updates.
I'd like to note, though, that it is possible to not reveal the
plaintext no matter how large the message is, though. You can mask the
output you release, e.g. XOR it or apply CTR mode, and provide the key
to remove the mask only when the ciphertext has checked out correctly.
I don't see how that helps with streaming. Basically any further
processing needs to wait until the whole message has been decrypted a
second time...
From the proposal you made it seem you think we should not even try to
provide a format for a non-streaming message. Would you describe that
as correct?
We should provide exactly one variant. Additional variants must
justify their existence, and I don't see the huge value add for
"proper AEAD". In fact, it seems dangerous as I think it will
encourage decryption misuse.
I think that even if we add a bit that says: "don't stream",
implementations will ignore it.
Hm. I'd classify this as a wilful violation of the spec rather than an
accident while implementing it.
Once you assume that implementations are doing things wilfully wrongly,
it gets messy.
I mean... where do we stop making compromises in the security of the
spec because we believe someone will wilfully ignore the spec? We rely
on the client not actively misinterpreting the spec. Like.. not making
secret key material available.
It's a simple question of: "can I use the software to get my work
done"? If the security is in the way, then the security will be
disabled. "Proper AEAD" will be in the way often enough that it will
get disabled, and decrease the security of the whole system.
Sorry,
Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp