Re: [TLS] Consensus for AEAD IV
Brian Smith <brian@briansmith.org> Sun, 26 April 2015 18:44 UTC
Return-Path: <brian@briansmith.org>
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 A09C61B2C45 for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 11:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7whwP-tsdfo8 for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 11:44:45 -0700 (PDT)
Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (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 15D851B2C41 for <tls@ietf.org>; Sun, 26 Apr 2015 11:44:45 -0700 (PDT)
Received: by obcux3 with SMTP id ux3so69357829obc.2 for <tls@ietf.org>; Sun, 26 Apr 2015 11:44:44 -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: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 10.60.94.165 with SMTP id dd5mr7055473oeb.53.1430073884426; Sun, 26 Apr 2015 11:44:44 -0700 (PDT)
Received: by 10.76.90.97 with HTTP; Sun, 26 Apr 2015 11:44:44 -0700 (PDT)
In-Reply-To: <553D27D0.7040209@nthpermutation.com>
References: <CAOgPGoC14uhjrZAQvDHFQrJoyoVNELpNNd4+Hh==zwf9ipyY5g@mail.gmail.com> <CABkgnnU50pvH+LFsN3BL9LfvYhZOxmJV1JYzODeC=-JpZSh8Lw@mail.gmail.com> <CAOgPGoDNuhmnNpZ7ELCfBHS4rKuj+3j1+YiuxLkST+z1J+tOKQ@mail.gmail.com> <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com>
Date: Sun, 26 Apr 2015 08:44:44 -1000
Message-ID: <CAFewVt6GQPt5AvpdWtpbupuUn7K8GPst5oZZskU_JD3FsRZC+A@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary="089e01228218e258770514a505f0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/yWDx95z5RPZEBGVZlKIpeGZ_pkE>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Consensus for AEAD 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: Sun, 26 Apr 2015 18:44:46 -0000
Michael StJohns <msj@nthpermutation.com> 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 pass-in-the-handle-to-material-that-can-be-*PROPERLY*-maintained-by-the-module 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. Cheers, Brian
- [TLS] Consensus for AEAD IV Joseph Salowey
- Re: [TLS] Consensus for AEAD IV Martin Thomson
- Re: [TLS] Consensus for AEAD IV Joseph Salowey
- Re: [TLS] Consensus for AEAD IV Martin Thomson
- Re: [TLS] Consensus for AEAD IV Russ Housley
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Yoav Nir
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Ilari Liusvaara
- Re: [TLS] Consensus for AEAD IV Brian Smith
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Ilari Liusvaara
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Yoav Nir
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Yoav Nir
- Re: [TLS] Consensus for AEAD IV Michael StJohns
- Re: [TLS] Consensus for AEAD IV Eric Rescorla
- Re: [TLS] Consensus for AEAD IV Yoav Nir
- Re: [TLS] Consensus for AEAD IV Nikos Mavrogiannopoulos