Re: [TLS] Consensus for AEAD IV

Brian Smith <> Sun, 26 April 2015 18:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A09C61B2C45 for <>; Sun, 26 Apr 2015 11:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7whwP-tsdfo8 for <>; Sun, 26 Apr 2015 11:44:45 -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 15D851B2C41 for <>; Sun, 26 Apr 2015 11:44:45 -0700 (PDT)
Received: by obcux3 with SMTP id ux3so69357829obc.2 for <>; Sun, 26 Apr 2015 11:44:44 -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=1mdzs3RaI+mtf0mmHNrtUgKHPdKbnUDByzL6w801/2Y=; b=IknjhXtGf6redtT+r/wOHo3KeW30Pwifd1ojwG7YYtdkJjWRh1quI4+bdog5PsamJ9 6TuAFKbvCC80RTBu3LHgaRb4ZF16iWqPfujZkcHSxphSCZqPWz/LV9KV7XdkVUU7vcXP rMoXuMnLLYa7mrwyNU8eFGVBHAJ42eVlt5uGqeT6n2SNwpvsrAZdFElWXtZkZUTqeDTc my3Rxn1eA5ST6JKNvrOpg2ui6banyn2/9h+zz4+Z3dOQAtNXnGOa/acSNUcCfZ4jjdDz jq1/TiB03AYMzq9oJW5ZKjhd3oRX8cra1Vq9V0aRhY1CRulR+/dQbbehoBbkF6nHKcBc +TGA==
X-Gm-Message-State: ALoCoQmjl1cxCrRZ7dKhGhHkrxgmeLeDGmbYCKPZyjBkKkMTgzzme9xqeB0Vd9Bw4XeXdlCvxtwt
MIME-Version: 1.0
X-Received: by with SMTP id dd5mr7055473oeb.53.1430073884426; Sun, 26 Apr 2015 11:44:44 -0700 (PDT)
Received: by with HTTP; Sun, 26 Apr 2015 11:44:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Sun, 26 Apr 2015 08:44:44 -1000
Message-ID: <>
From: Brian Smith <>
To: Michael StJohns <>
Content-Type: multipart/alternative; boundary="089e01228218e258770514a505f0"
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] Consensus for AEAD IV
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: Sun, 26 Apr 2015 18:44:46 -0000

Michael StJohns <> wrote:

> So what you're suggesting is requiring each cipher mode that uses TLS have
> both the generic - pass in the IV etc - and the TLS specific - pass in a
> handle to material that has to be retained within the HSM and managed in
> some way to make sure that you delete when your done?

No, it isn't TLS-specific. As others noted, SSH can use it too. And, future
protocols can use it as well. Regardless of the particulars if the TLS
discussion, the pass-in-the-IV approach is terrible because the module
cannot guarantee the uniqueness of the IVs. So, actually, everybody should
be using the
approach. The FIPS 140 implementation guidance agrees, as far as I
understand it.

> You're actually going to make it impossible to use TLS1.3 with generic
> hardware modules.

No, one can still create a generic module that doesn't know anything about
TLS, that can provide this type of interface. And, one should do so.

> There is no reason to treat the 96 bit quantity as secret and no one else
> does.

Others already refuted the "no one else does." As for there being "no
reason to treat the 96 bit quantity as secret," there's also no reason to
make it public. The working group already decided when there is no
compelling reason to make a handshake value public, then it should be made
private. (The charter says "Develop a mode that encrypts as much of the
handshake as is possible to reduce the amount of observable data to both
passive and active attackers.")

Further, I believe you actually mean "there is no *known* reason" to treat
the IV as secret. That doesn't mean there aren't *unknown* reasons for
doing so.

> TLS should use generic interfaces rather than inventing stuff that can't.

Again, this can use a generic interface. It can't use the generic
interfaces that are currently exposed by certain crypto modules, but that's
a problem with those crypto modules' interfaces, not with what is being
proposed here.