Return-Path: 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 ; 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 ; 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 ; Fri, 17 Apr 2015 15:15:08 -0700 (PDT) Received: by wgsk9 with SMTP id k9so126335557wgs.3 for ; 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: References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> From: Eric Rescorla Date: Fri, 17 Apr 2015 15:14:27 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=f46d04428da2b4e07a0513f2e90a Archived-At: Cc: IETF TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 22:15:10 -0000 --f46d04428da2b4e07a0513f2e90a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 wrote: > Yoav Nir wrote: > >> On Apr 17, 2015, at 10:40 PM, Eric Rescorla 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=E2=80=99m not= aware of > any contention about them. In AES-GCM they are used for the =E2=80=9Csalt= =E2=80=9D 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/0c610a9453ca10bd12d3b979d2faa014= a0b12251 > --f46d04428da2b4e07a0513f2e90a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's correct. Yoav, if you're sad about that, th= en now is the time to say that :)

-Ekr


On Fri, Apr 17, 2015 at 2:18 PM, Brian Smith <brian@brian= smith.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=E2=80=99m no= t aware of any contention about them. In AES-GCM they are used for the =E2= =80=9Csalt=E2=80=9D value, and the chacha20-poly1305 draft uses the same te= rminology 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 dr= opping.

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

--f46d04428da2b4e07a0513f2e90a--