Brian Smith <> Thu, 26 March 2015 02:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D7701A6F1D for <>; Wed, 25 Mar 2015 19:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VoRglbbwCQzz for <>; Wed, 25 Mar 2015 19:36:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9C8F1A6F0E for <>; Wed, 25 Mar 2015 19:36:02 -0700 (PDT)
Received: by oier21 with SMTP id r21so38377762oie.1 for <>; Wed, 25 Mar 2015 19:36:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XlaIIzyPbvYtHcV1tGkM/DV65uoVQen2LHbvqXB63+k=; b=NypYytK82R5RDJSi48tiUw3U6/gZrQegzvZe3sq3ruWMXkaA8KdCEV4pJWf5meG6ve C9AWmJElJM4Y/UrJm5UV9tRJHI8UcDCb83lYZyNwbzKPQC8vzMSItUxWh5goObDEjH7Q sv2GwA5lOsqI4LrpviKnLUNuILhf2i8hbM7o6IXGRM3HybhruxiR62e259bd/EUdhMaY W3NWlGKBn1tZo9Wi+HebCc3OuZgBlkK3ifMJ8B1gdJ01hJAT273eGvE+WYrylsgjGsn0 nJPngNGa1sVwILwTv2v9AgeExEfQsyI416xtvfD2nFmLECErBz3v0FBzhb//cyxExRFP PARw==
X-Gm-Message-State: ALoCoQmc4+urGyw2NNciWz990KxZ4/Qq8eghzvUy5YkwJTSzwhxWBm2UskXz1sX6xMGcDtlthNfA
MIME-Version: 1.0
X-Received: by with SMTP id b128mr9539760oif.80.1427337362119; Wed, 25 Mar 2015 19:36:02 -0700 (PDT)
Received: by with HTTP; Wed, 25 Mar 2015 19:36:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 25 Mar 2015 16:36:02 -1000
Message-ID: <>
From: Brian Smith <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] HKDF
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Mar 2015 02:36:04 -0000

Eric Rescorla <> wrote:
> On Wed, Mar 25, 2015 at 1:47 PM, Brian Smith <> wrote:
>> If the IVs are secret (only shared between the two peers) then I don't
>> see the need to change how they are calculated from the keyblock.
> The issue is that in many cases the IV will be handled outside the crypto
> module, and the keys should stay inside the crypto module. The traditional
> slice and dice makes that hard.

When the implementation cares about this, won't it also care that the
nonce/IV is completely managed within the crypto module too?
Otherwise, for certain things like AES-GCM, the application could
attack the crypto module reusing a nonce in order to learn the key.
Using the design I suggested in [1] allows the crypto module to
completely manage the nonce/IV in a way that makes such abuse
impossible. In fact, with that design, the crypto module doesn't even
need to tell the application what the nonces/IVs are. And that can
happen without changing how the nonces are derived from the keyblock.

Conversely, if the crypto module *doesn't* work like that, then it
isn't clear to me that it is actually offering a useful amount of
protection of the key material. It doesn't seem useful to make things
more complicated in order to support that kind of design, which seems