Subject: Re: [Curdle] [Spasm] Chunking ciphertexts

From: Wei Chuang <[email-masked]>
Date: Fri, 2 Sep 2016 09:56:17 -0700

Cross posting to Curdle as I think this is more of a general problem than
just S/MIME.

Support for chunking could be done at CMS, and would require updating
RFC5652.

I also wanted to point out that there was a similar discussion in the cfrg
earlier
<https://www.ietf.org/mail-archive/web/openpgp/current/msg08331.html> on
this topic though I don't know what the outcome was.

-Wei

On Thu, Sep 1, 2016 at 5:22 PM, Adam Langley <[email-masked]> wrote:

> Since the WG is currently considering changes to S/MIME, I'd like to
> mention the benefits of chunking ciphertexts. (Or, rather, the
> problems with not chunking them.)
>
> As I understand it, S/MIME and associated standards typically encrypt
> payloads as a single ciphertext (i.e. RFC 5084). Since the plaintexts
> might be quite large, this encourages implementations to decrypt these
> ciphertexts in a "streaming" fashion, i.e. they return plaintext
> before it's authenticated.
>
> Encouraging APIs that return unauthenticated plaintext is an ecosystem
> cost since such APIs are dangerous. One similarity is with the
> MAC-then-encrypt constructions used in TLS, which caused many problems
> by processing unauthenticated ciphertext. At a higher level, it's not
> hard to find people on the internet suggesting things like:
>
> gpg -d your_archive.tgz.gpg | tar xz
>
> because the gpg command also provides a "streaming" interface.
> (http://askubuntu.com/questions/95920/encrypt-tar-gz-file-on-create)
>
> With constructions like AES-GCM it's, of course, very easy to
> manipulate the plaintext at will if the application doesn't
> authenticate it before processing. Even if the application is careful
> not to "release" plaintext to the UI until the authenticity has been
> established, a streaming design exposes more program attack surface.
>
> By normalising large ciphertexts and thus streaming APIs, the next
> protocol that comes along is more likely to use them without realising
> the issues and thus the problem persists.
>
>
> Preferably, plaintext inputs would be chunked into reasonably large
> parts (say 16KiB) and encrypted separately. The chunks only need to be
> large enough that the overhead from the additional authenticators is
> negligible. With such a design, large messages can be incrementally
> processed without having to deal with unauthenticated plaintext, and
> AEAD APIs can be safer. (Not to mention that larger messages can be
> processed since AES-GCM, for one, has a ~64GiB limit for a single
> plaintext.)
>
> Some thought is needed to ensure that the chunks are in the correct
> order (i.e. by counting nonces), that the first chunk should be first
> (i.e. by starting the nonce at zero) and that the last chunk should be
> last (i.e. by appending an empty, terminator chunk with special
> additional data). But that's not hard.
>
>
> Even with such a design it's still the case that an attacker can cause
> the message to be detectably truncated. If you want to aim higher, an
> all-or-nothing transform can be used, although that requires two
> passes over the input and I understand if it's sufficiently
> problematic that you don't want to do that.
>
>
> Cheers
>
> AGL
>
> --
> Adam Langley [email-masked] https://www.imperialviolet.org
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 2 Sep 2016 14:40:56 -0400

As I just said on the SPASM mail list: In thinking about the problem that you raise, I think that a chunking would be needed at the CMS layer, which could then be used at the S/MIME layer.

This problem is not one that belongs in the CURDLE WG because it involves much more than new algorithms.

Russ

On Sep 2, 2016, at 12:56 PM, Wei Chuang <[email-masked]> wrote:

> Cross posting to Curdle as I think this is more of a general problem than just S/MIME.  
> 
> Support for chunking could be done at CMS, and would require updating RFC5652.
> 
> I also wanted to point out that there was a similar discussion in the cfrg earlier on this topic though I don't know what the outcome was.
> 
> -Wei
> 
> 
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle