Re: [TLS] HSM-friendly Key Computation

Eric Rescorla <ekr@rtfm.com> Fri, 17 April 2015 22:15 UTC

Return-Path: <ekr@rtfm.com>
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 9A6DC1B309C for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 15:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 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] 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 DpQXS7lOtr4J for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 15:15:09 -0700 (PDT)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (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 C038F1B309A for <tls@ietf.org>; Fri, 17 Apr 2015 15:15:08 -0700 (PDT)
Received: by wgsk9 with SMTP id k9so126335557wgs.3 for <tls@ietf.org>; Fri, 17 Apr 2015 15:15:07 -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:from:date :message-id:subject:to:cc:content-type; bh=VEPJwmm4mkirffepMArWVJBJFGWW9uM8JTRp4kuzbro=; b=fOHAXU9CvTHwJ3N1fqWf8+qSLSyLmF7A95VbhczD+gASiqoMoHxCrZDOtTz1JEHw2H yW7uZei+S96z37YRtZ7CxLSGkSW07JQa1696rXC95R5qnjlqqWKPMeN+X5DjvBOZTT/y o7lg/VRWBsTyGi1Wd/37xJvAymjVCCYrv2+VCeBN4clQT4ra7wBfmhaltnsFTJjF6bfA 1yeyo71d3VprkLIdeggSa+0yOC3vjieaeL6vPtVhed+Blih2gVFZmDrFUwX1dmT1xKhs e9wF4HPb0QNAKn156pTYToF/TZNbtLoMUkpWws02VYTdH8Xiq8EoQz+H1VW0VSQA3o1E mwaQ==
X-Gm-Message-State: ALoCoQkWhDncif3NKyErGzRqL2UsUWwQAeyMHy4dw4hRKUqhr+AN4N6W3CfSm4u8CLVPjMrgoVaG
X-Received: by 10.180.82.135 with SMTP id i7mr5106337wiy.68.1429308907506; Fri, 17 Apr 2015 15:15:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.205.87 with HTTP; Fri, 17 Apr 2015 15:14:27 -0700 (PDT)
In-Reply-To: <CAFewVt4ERdQmWrvPooZ2X4TVLAw62Hzs=0JqCqdzvRBzivds=Q@mail.gmail.com>
References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <CABcZeBOh08+8bz3Wk+xXYp9myVHpk6R70QMWdRjs1h7Y7ghEeQ@mail.gmail.com> <A1051B9F-8186-4151-A209-D1B9808CEE43@gmail.com> <CAFewVt4ERdQmWrvPooZ2X4TVLAw62Hzs=0JqCqdzvRBzivds=Q@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 17 Apr 2015 15:14:27 -0700
Message-ID: <CABcZeBM2iMO3BU9VN5pivHRKv++iHWDgkTS4U2ULVcAB9PY_HA@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary=f46d04428da2b4e07a0513f2e90a
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/SYX8ev7KmVVUfIVAzvbp4W4wwLQ>
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 22:15:10 -0000

That's correct. Yoav, if you're sad about that, then now is the time to say
that :)

-Ekr


On Fri, Apr 17, 2015 at 2:18 PM, Brian Smith <brian@briansmith.org> wrote:

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