Re: [TLS] Pull Request: Removing the AEAD explicit IV

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Thu, 19 March 2015 20:31 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 771B41A906D for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 13:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 OzFbuRhfQ6bm for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 13:31:43 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F451A9067 for <tls@ietf.org>; Thu, 19 Mar 2015 13:31:42 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 2F8B781807; Thu, 19 Mar 2015 22:31:41 +0200 (EET)
Date: Thu, 19 Mar 2015 22:31:41 +0200
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Brian Smith <brian@briansmith.org>
Message-ID: <20150319203141.GA10457@LK-Perkele-VII>
References: <CABcZeBPfasM5HmJaATLUHQKRgiSGCreJt1T=UoDBGCbcuzyW8Q@mail.gmail.com> <CAFewVt7_+oqy0EczdaxVpgS9gkzp8EMjLCgjXj+DE7S-e94Q7A@mail.gmail.com> <CABcZeBMN=0GUsqDMnLM5eTg54t6Sn0ME9213ts75OXLKZxr9+w@mail.gmail.com> <CAFewVt4Jq7S_oV8jetz+PxNg9zJ+J0WLWvDt4V+iHQJ87enuCQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAFewVt4Jq7S_oV8jetz+PxNg9zJ+J0WLWvDt4V+iHQJ87enuCQ@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/vS_XL1ohyWByVFv4zpkLqjyr3_I>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV
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: Thu, 19 Mar 2015 20:31:45 -0000

On Thu, Mar 19, 2015 at 10:11:40AM -1000, Brian Smith wrote:
> Eric Rescorla <ekr@rtfm.com>; wrote:
> > On Thu, Mar 19, 2015 at 12:53 PM, Brian Smith <brian@briansmith.org>; wrote:
> >> It seems like it would be better, instead, to require that the initial
> >> nonces to be calculated from the keyblock established during key
> >> agreement,
> >
> > Is there any reason why these should be derived from the keyblock
> > as opposed to from purely public information such as the random
> > values?
> 
> Intuitively, I expect the attacker to have more difficulty if they
> don't know the nonce than if they do. In general, we should not
> divulge more than the minimum amount of information in cleartext. And,
> in particular, one of the design goals is to encrypt as much of the
> handshake as possible, and the nonce selection is part of the
> handshake.
> 
> I wouldn't be surprised if somebody pointed out a good reason to avoid
> deriving them out of the key block, though I don't know of one now.

As to what other protocols do with GCM, both SSH and IPSec do derive
initial nonce out of key block (like TLS 1.2 does).

As to supporting "hardware", there are values in TLS that are both
public and have to be derived from key block, so any HSM has to know
about TLS to be able to know what should be exportable and what isn't.

And if the HSM accepts arbitrary nonces, one can break the encryption
fast.

> >> and then have them incremented as counters (with
> >> wraparound) in the same fashion as being proposed.
> >
> > Can you explain why you think they need to change? I note that TLS 1.2
> > currently does not behave in this fashion.
> 
> I think you interpreted my suggested as <initial-nonce> || <record
> sequence number>. I just mean that the per-record nonce should be
> calculated as <initial-nonce> + <record sequence number>. It seems
> better to start all the initial bits of the nonce in a randomly-chosen
> state, instead of just a prefix, if there's no conflicting
> considerations to do otherwise.

As to what other protocols do with GCM, SSH derives a full block and
increments that. IPSec derives just a prefix (like TLS 1.2).


-Ilari