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

Eric Rescorla <ekr@rtfm.com> Thu, 19 March 2015 20:18 UTC

Return-Path: <ekr@rtfm.com>
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 941791A901F for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 13:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 j3n7HXAHOjdq for <tls@ietfa.amsl.com>; Thu, 19 Mar 2015 13:18:43 -0700 (PDT)
Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A74C1A1B56 for <tls@ietf.org>; Thu, 19 Mar 2015 13:18:34 -0700 (PDT)
Received: by wgra20 with SMTP id a20so72303849wgr.3 for <tls@ietf.org>; Thu, 19 Mar 2015 13:18:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lyQUgIO8dTWl4M8USFt/u/p4/IuB52rXVGRd8WMQ+Lw=; b=TH/KEeADTzahMpF5sQUpOvINPt4pYzOuQPEZXMIMmhztZ2DSLERZr8Ggt4XuferwjN k95iNVT/EMwzk0aFYGQsZOFurNUXmMsj56utxzUhbUJjgKS/jzWQAOJ95QAe8DR0R+mt pjcMkFFQP6+gpZbBCAUd2pjcO1B/ktNZlZetp+ExVIAOSne4DwFgbQ69ypKsCtFBVel4 2n/3bHAb2AzRup76XRRO5/6i9ZM5LItf3HVd6P5UiHhYwyzmJCAz5PEhXlM8ctYoWPnB NgH4w1apkqJ3l6YyXwHqwi2nmRRmQOled4SKuwni8UON7vXYVgd0OXCpdvswDjCDKLd6 56JQ==
X-Gm-Message-State: ALoCoQlZLfT+fgIVMx6qvyqdLdWaYDcRij+Rz4anWi2JtG4sZ77xstnToxPBmvcsF5U+fD6QkBYZ
X-Received: by 10.194.159.105 with SMTP id xb9mr103441512wjb.156.1426796313194; Thu, 19 Mar 2015 13:18:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.205.198 with HTTP; Thu, 19 Mar 2015 13:17:51 -0700 (PDT)
In-Reply-To: <CAFewVt4Jq7S_oV8jetz+PxNg9zJ+J0WLWvDt4V+iHQJ87enuCQ@mail.gmail.com>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 19 Mar 2015 13:17:51 -0700
Message-ID: <CABcZeBMDQ5aM-DKBDTP0bBjaw0kgZ0prwMjdGRi-887b0nTPVQ@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary=001a11c3aa586a47480511a9e761
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Z6ZS4GGz1pK3Haw-sH2lcsDMaII>
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:18:44 -0000

On Thu, Mar 19, 2015 at 1:11 PM, Brian Smith <brian@briansmith.org>; 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.
>
> >> 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 did. It doesn't help here that TLS uses '+' for concatenation :(




> 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.
>

So to be clear we would generate a random V of length
N_MIN and then for each record the nonce would be
SN + V?


-Ekr


> Cheers,
> Brian
>