Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD

Michael StJohns <msj@nthpermutation.com> Tue, 27 May 2014 16:03 UTC

Return-Path: <msj@nthpermutation.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 44BBC1A0487 for <tls@ietfa.amsl.com>; Tue, 27 May 2014 09:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1wUrpzjD3boK for <tls@ietfa.amsl.com>; Tue, 27 May 2014 09:03:57 -0700 (PDT)
Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4611A04C8 for <tls@ietf.org>; Tue, 27 May 2014 09:02:59 -0700 (PDT)
Received: by mail-pb0-f47.google.com with SMTP id rp16so9431144pbb.6 for <tls@ietf.org>; Tue, 27 May 2014 09:02:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=ILeIubBhfKHoxQjQTHAEdPxcbG9LfhQS3h0KknwhzsI=; b=Cc1VK3V3DZbl+lQGaK4IBG89gh6uGSkhkBABJ4JDbl5FUG8QFVbTPLsj0U50gI9BFY G8qnDpVFgoKEgO88RQEJ0ZWnFcSvkPVVSq5u8zzrVYOcaHUaQmbLbNVTN5YKB5/D2jQt pYdiW9SaJVPAinPB+UmmKZQmuwQqJmCB6CZUoLb0ZJsdMnSwXfvKk90/A5RVTLrHT9pZ DDWwBmSue7cDZIX1yOTfkditw/A67swzbNgpjXkeyUC+XPonUHlc24J2WSrY4MSBNv8Z jGXRAUUK2S73W2zyVuXiJnfKj2JPTsXlb44vFZlihtUtaKzG6tlRlpuZO41olU///gN5 3P3A==
X-Gm-Message-State: ALoCoQmG0dNzTqBhjPktOST0tBMCewjKNwHte7vl7hcTDC2vVx+wVGi013qzUyEJfDG7dJTZqhPF
X-Received: by 10.66.189.226 with SMTP id gl2mr37681532pac.65.1401206575068; Tue, 27 May 2014 09:02:55 -0700 (PDT)
Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id iq10sm24018215pbc.14.2014.05.27.09.02.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 09:02:54 -0700 (PDT)
Message-ID: <5384B735.3090904@nthpermutation.com>
Date: Tue, 27 May 2014 12:03:01 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>, Eric Rescorla <ekr@rtfm.com>
References: <5383F02F.4050706@nthpermutation.com> <CABcZeBPU8gQtpVOyD5KO28bv3Ggjf-7p1wj8uU8NztnFMfPJ6Q@mail.gmail.com> <53840318.10902@nthpermutation.com> <CABcZeBNCjddKRR=ayBr1LmOeMCv93aYZAquOHhqKHGLnDO81xg@mail.gmail.com> <CFAA0D03.15C36%uri@ll.mit.edu>
In-Reply-To: <CFAA0D03.15C36%uri@ll.mit.edu>
Content-Type: multipart/alternative; boundary="------------080706060208040100080804"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kJIGQYIV_37ckTlSiH5OWjo-vLM
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD
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: Tue, 27 May 2014 16:03:59 -0000

On 5/27/2014 9:39 AM, Blumenthal, Uri - 0558 - MITLL wrote:
>
>>             Does it also result in changing the output of the "key
>>             expansion" phase as only "client_write_key" and
>>             "server_write_key"s will be needed for AEAD?
>>
>>
>>         I don't believe so, since AEAD still at least potentially
>>         requires an IV.
>
>         Right - but we really need to get IV material in a way where
>         it isn't derived from the master secret.
>
>
> s/isn't derived/is cryptographically separated/
>
> And everything will be fine. ;)

No.  The key material and IVs produced by the current TLS1.2 KDF are 
"cryptographically separated" from the master secret - that's sort of 
the definition of what a KDF is.

You want cryptographic isolation between the key material produced from 
the master secret and the iv material produced from the IV, and the 
current spec doesn't do that.  See my last message to EKR.  One way to 
create this isolation is to derive the random IV data from a key that is 
different from the master secret - either a subkey derived from the 
master secret, or from a second key derived from the premaster.    A 
second way to create the isolation is to not generate the IV data from a 
key value and instead simply use an entropy expansion function on the 
client_random and server_random to generate the IVs.

There are other approaches, but most end up with a single function 
producing both public and private data and that makes securing the 
process difficult.

Mike




>
>     I don't agree with this claim. As I understand the constraints,
>     they merely
>     need to be derived in a way that is isolated from the keying material.
>
>
> Yes.
>
>     Is there a reason that it's unsafe to generate the IVs from the MS
>     provided
>     that this condition is met?
>
>
> IMHO, no. :-)