IETF Logo Mail Archive

Re: [TLS] HSM-friendly Key Computation

Brian Smith <brian@briansmith.org> Fri, 17 April 2015 21:18 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 1CFE91B2EB1 for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 14:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY4LMN2N3duo for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 14:18:13 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (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 5A2911ACEA7 for <tls@ietf.org>; Fri, 17 Apr 2015 14:18:13 -0700 (PDT)
Received: by obbeb7 with SMTP id eb7so80330010obb.3 for <tls@ietf.org>; Fri, 17 Apr 2015 14:18:12 -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 :content-transfer-encoding; bh=wzCrRIMJXWfpysNPSSXRvKNnwSGhob687Aq3b8O4xoI=; b=CazYTZig9t37sbInFB7bZL60zAhfxGvWjZSR4JIxuWsq9n9zO7Ht12vE4hR4V2ZGpI LSknmXMq7+Vs6J8w+zDLJ5WvkYM1KEwyj2dMUmDIb8zqu4BLK79D8H42If7888Y0zQJ8 D014imTLHNDae+bFjEUX4Vh22SJsciRcQfzXxvLZSnaa17/OzCQsTlnr/pdT/LMKPOJC L0jb3bssbSynD1WnEjxyHwDk5CeiFhYGXhkXmsx5fomaw4D3trw0yA6X6X+W0VuGucgK r6ookVzsAsG3EBoIxnbViIaZaz2HGqTU8jf1TMOr8fIow5Y0+SRC+6F/9IMecz/UMo4s Lq3w==
X-Gm-Message-State: ALoCoQkMZ7VQNJuFiQrBSoYxxf2mcPEz764xa567I1TwEK+a3vhqobzGY3JJeDum7u43E45L5UEj
MIME-Version: 1.0
X-Received: by 10.202.210.194 with SMTP id j185mr4492585oig.68.1429305492674; Fri, 17 Apr 2015 14:18:12 -0700 (PDT)
Received: by 10.76.20.146 with HTTP; Fri, 17 Apr 2015 14:18:12 -0700 (PDT)
In-Reply-To: <A1051B9F-8186-4151-A209-D1B9808CEE43@gmail.com>
References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <CABcZeBOh08+8bz3Wk+xXYp9myVHpk6R70QMWdRjs1h7Y7ghEeQ@mail.gmail.com> <A1051B9F-8186-4151-A209-D1B9808CEE43@gmail.com>
Date: Fri, 17 Apr 2015 11:18:12 -1000
Message-ID: <CAFewVt4ERdQmWrvPooZ2X4TVLAw62Hzs=0JqCqdzvRBzivds=Q@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/foyeG7ViLvsNTSqkQYPfSAxEC5I>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] HSM-friendly Key Computation
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: Fri, 17 Apr 2015 21:18:15 -0000

Yoav Nir <ynir.ietf@gmail.com> wrote:
>> On Apr 17, 2015, at 10:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> We should defer this issue until we know whether we are generating an IV
>> at all.
>>
> The client_write_iv and server_write_iv are needed, and I’m not aware of any contention about them. In AES-GCM they are used for the “salt” value, and the chacha20-poly1305 draft uses the same terminology for a 32-bit fixed part of the nonce that is derived from the key buffer.
>
> This is not the same as the per-record IV that we *are* considering dropping.

I think you're misunderstanding what is being discussed. As far as I
know, nobody objects to using the record sequence number in a way that
turns the nonce into a counter. The only thing being debated is
whether client_write_iv and server_write_iv are used. See the actual
pull request [1]. The proposal put forth in that pull request is that
the nonce will consist *only* of the per-record sequence number,
padded with zeros, and without the part that was comprised of
client_write_iv and server_write_iv.

Cheers,
Brian


[1] https://github.com/ekr/tls13-spec/commit/0c610a9453ca10bd12d3b979d2faa014a0b12251

v2.23.0 | Report a Bug | By Email