Michael StJohns <> Thu, 26 March 2015 14:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 128961ACEF6 for <>; Thu, 26 Mar 2015 07:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lSGG_Pb-8ZDP for <>; Thu, 26 Mar 2015 07:53:00 -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 D05001A03B3 for <>; Thu, 26 Mar 2015 07:51:33 -0700 (PDT)
Received: by wgra20 with SMTP id a20so66853521wgr.3 for <>; Thu, 26 Mar 2015 07:51:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yjx6906FHZa8Rd4mns8s4cP1kSrvWKZiBTFPx3LCtPI=; b=W2pglY8cyttZGhRpwmuu3FLYwUNmi1li4l2tFT3GyXoK7DL0nHgdC8BqZVwDP4XzHA MvzGuwxXr0ql+5PpwL9egyz9rtwrMxpfx7kdrbYEws0tX0baKTOxG9zf+823rpdR2RlS pyOfgJalxBgujm9AlM502FDYhMh651ciaTyE8obWSEv5K1G4Vr7PL0TF+kB2K7WkbJ6z nPUvVqemSyWEeWzT98zLrQZ6BbNPtVoFmq/YgwgXQDdo7LtAu1iTs+TyW4p53eA1Fmen WaPbksMBQeb1+QPshBPRXn2AFs5adibJ9w84iM/eHnAZWuacpEfOiIPhE0gr6waPpcEb Km+g==
X-Gm-Message-State: ALoCoQmEn7mP/1B5EtEpfsEAUlWQ2ErVL5BeVRads7wYg5L40C0C8L4/vgqOImqhKfXVxyI666hj
X-Received: by with SMTP id cj2mr28370066wjc.93.1427381492400; Thu, 26 Mar 2015 07:51:32 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:176:f157:b8d9:3dde:b6b4? ([2001:67c:370:176:f157:b8d9:3dde:b6b4]) by with ESMTPSA id nd15sm9314350wic.8.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 07:51:31 -0700 (PDT)
Message-ID: <>
Date: Thu, 26 Mar 2015 10:51:41 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
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 14:53:10 -0000

On 3/25/2015 10:36 PM, Brian Smith wrote:
> 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.

Not exactly.  On the encrypt side, there's a desire that the IV/Nonce be 
produced and controlled by the crypto module, but doing that is actually 
pretty hard given the large number of different ways of forming said 
nonce proposed by different protocols and usages (e.g. compare what TLS 
is doing to what Zigbee or other IOT protocols are doing).

On the decrypt side, you *must* provide the input IV/Nonce as an input - 
it can't be generated internally for the reasons mentioned above and 
there are also issues with lost or ignored (untimely) messages (general 
crypto issue, not typically a TLS one)
> 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.

But doing that requires that the module have yet another TLS specific 

The general contract (going back to probably the first version of PKCS11 
and others) for encrypt/decrypt APIs is a per-message IV. AEAD modes 
such as CCM and GCM are trying to modify that contract to make the 
encrypt dependent on a per-session value concatenated with a per-message 
value (with a counter for the per-block part).  I'm no longer working 
with the PKCS11 folks at Oasis, but a year ago what we were looking at 
was some form of PKCS11 mechanism that might be called an IV generator.  
The set of those mechanisms was not small.

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

My personal goal is to be able to build a crypto module that has NO TLS 
specific tweaks - where I can provide as inputs (safely in that doing 
this doesn't adversely affect security) that allow the module do TLS, 
but where doing that or allowing that doesn't prevent the module from 
doing say IPSEC, Zigbee, etc also securely.

Moving to a "standard" KDF is a good start.  Removing the first message 
IV/per-session Nonce generation from the master key expansion is even 
more helpful.


> Cheers,
> Brian
> [1]
> _______________________________________________
> TLS mailing list