Re: [TLS] Consensus call on Implicit IV for AEAD

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Sat, 04 April 2015 19:53 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AB31A1AFC for <tls@ietfa.amsl.com>; Sat, 4 Apr 2015 12:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DzPSk8FBO-q for <tls@ietfa.amsl.com>; Sat, 4 Apr 2015 12:53:31 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E621A1AD3 for <tls@ietf.org>; Sat, 4 Apr 2015 12:53:29 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id B02D31887DE; Sat, 4 Apr 2015 22:53:26 +0300 (EEST)
Date: Sat, 04 Apr 2015 22:53:26 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Brian Smith <brian@briansmith.org>
Message-ID: <20150404195326.GA2392@LK-Perkele-VII>
References: <CAOgPGoCW-znnh5VFobCFjZafxEOcwsaHZ_eByTwpCpmqfgX=6Q@mail.gmail.com> <CAFewVt6fL2sty8E=kOaykynhH8i0Mf52Aqypt-iFS8F_SWZMaQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAFewVt6fL2sty8E=kOaykynhH8i0Mf52Aqypt-iFS8F_SWZMaQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/38c-Zt7kp_Sy8ExOKVnfnWsN6r8>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Consensus call on Implicit IV for AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Apr 2015 19:53:33 -0000

On Fri, Apr 03, 2015 at 05:17:04PM -1000, Brian Smith wrote:
> 
> Conversely, there is a clear record of my objection to the
> zero-padding mechanism on the mailing list, and there seems to be at
> least some mild support for my suggested alternative of deriving the
> initial nonce from the keyblock. I think I provided a good
> justification for moving to the randomized initial nonce. I think that
> the concerns about it being more work to support a randomized nonce in
> crypto modules that attempt to enforce a cryptographic boundary are
> valid,m but those concerns outweigh the security benefits of starting
> with a randomized nonce. I would be happy to work with the people who
> expressed that concern to show that a randomized initial nonce can
> work well and isn't unreasonably burdensome even in such products.

The stated reason for not deriving IV from keyblock is to support
"hardware modules" that don't know about TLS.

I do not think such support is actually possible without
severe restrictions: One major problem (and there are others) is
interaction of resumption and TLS-unique (which is needed for
e.g. token binding). TLS-Unique value is public. But on resumption,
it needs to depend on resumption key, which is secret (resumption
key can be abused to misuse client certificates).

Second problem: If TLS-Extractor is to be supported, those values
are keying and publically binding at the same time (I have seen
examples of both in various widely used protocols). Keying means
there is no choice but to derive from secret values. Publically
binding means the values are public.

Deprecating either of TLS-Unique or TLS-Extractor or changing properties
thereof does not seem to be an option, so full TLS 1.3 needs to derive
public values out of private ones anyway.

Also, exposing nonce generation to "untrusted" code seems pretty
dangerous, given how fragile most fast AEAD ciphers are (it is difficult
to even imagine worse nAEAD in this regard than *-GCM).

> I've also thought of another reason why it seems useful to start with
> a randomized initial nonce: As mentioned previously on this list, in
> reality many AES-GCM implementations are far from being constant-time.
> As far as I can reason, AES-GCM with predictable nonces, combined with
> predictable plaintext and/or chosen plaintext, seem more likely to
> attack via side channel attacks than AES-GCM with randomized nonces.
> This is another significant advantage of randomization.

As a datapoint about (lack of) hardware support for AES-GCM: When
Cloudflare turned Chacha ciphers on, it took about one fourth
of the AES-GCM connection count (other ciphers didn't bulge).

> It seems like zero padding would be a regression from what
> TLS 1.2 does, in terms of security. I find that concerning.

As brought up in the meeting, 128 bit ciphers are suspectable
to multi-key weakening (it is an generic attack against
symmetric ciphers). The answer was to use 256-bit ciphers, but
AES-256 isn't that widely supported (I think Chrome is planning
to deprecate it[1]).

Then when it comes to cipher-specific weaknesses (and we know
that ciphers have annoying tendency to stay in use way past
the best before date, *cough* RC4 *cough*), it depends on type
of weakness if having a known nonce significantly helps breaking
or not.


BTW: SSLv3 applied special handling for EXPORT ciphers: The
initial IV was derived in public way[2] (instead from keyblock
like non-export ciphers). Of course, didn't matter much,
given that all IVs were for CBC modes.



[1] Also on some security-oriented forums, one frequently
hears remarks about AES-256-CBC being worse than AES-128-GCM.

[2] I think this was a due to a restriction on export
ciphers that disallowed hiding the nonces.


-Ilari