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
- [TLS] Consensus call on Implicit IV for AEAD Joseph Salowey
- Re: [TLS] Consensus call on Implicit IV for AEAD Martin Thomson
- Re: [TLS] Consensus call on Implicit IV for AEAD Daniel Migault
- Re: [TLS] Consensus call on Implicit IV for AEAD Brian Smith
- Re: [TLS] Consensus call on Implicit IV for AEAD Dave Garrett
- Re: [TLS] Consensus call on Implicit IV for AEAD Eric Rescorla
- Re: [TLS] Consensus call on Implicit IV for AEAD Ilari Liusvaara
- Re: [TLS] Consensus call on Implicit IV for AEAD Tom Ritter
- Re: [TLS] Consensus call on Implicit IV for AEAD David Leon Gil
- Re: [TLS] Consensus call on Implicit IV for AEAD Eric Rescorla
- Re: [TLS] Consensus call on Implicit IV for AEAD Yoav Nir
- Re: [TLS] Consensus call on Implicit IV for AEAD Tom Ritter
- Re: [TLS] Consensus call on Implicit IV for AEAD Yoav Nir
- Re: [TLS] Consensus call on Implicit IV for AEAD Daniel Migault
- Re: [TLS] Consensus call on Implicit IV for AEAD Martin Thomson
- Re: [TLS] Consensus call on Implicit IV for AEAD Daniel Migault
- Re: [TLS] Consensus call on Implicit IV for AEAD Ilari Liusvaara
- Re: [TLS] Consensus call on Implicit IV for AEAD Martin Thomson
- Re: [TLS] Consensus call on Implicit IV for AEAD Ilari Liusvaara
- Re: [TLS] Consensus call on Implicit IV for AEAD Michael Hamburg
- Re: [TLS] Consensus call on Implicit IV for AEAD Brian Smith
- Re: [TLS] Consensus call on Implicit IV for AEAD Yoav Nir