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

Michael StJohns <msj@nthpermutation.com> Thu, 29 May 2014 19:34 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 566251A04F1 for <tls@ietfa.amsl.com>; Thu, 29 May 2014 12:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ye_hVEQSSGSC for <tls@ietfa.amsl.com>; Thu, 29 May 2014 12:34:19 -0700 (PDT)
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E541A0225 for <tls@ietf.org>; Thu, 29 May 2014 12:34:19 -0700 (PDT)
Received: by mail-pb0-f45.google.com with SMTP id um1so836619pbc.18 for <tls@ietf.org>; Thu, 29 May 2014 12:34:14 -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 :content-transfer-encoding; bh=gjJz6l847JL9FpW7mYnS9WhlKUU0eVQfTdhBFXouGRQ=; b=WIODgPDZa4ub27GrPchX9aEXz7x+X5vFuC0vgAAcN1h0VjnXm4PXMLjzmNAQ2BP5EY 5jgVCm7SB+o9YV1GveeQcEm+u6RkK9v5BSQsRYWDQ7PLtvwc95IStZSC1Iitsf9ANIvi CTHjsgMWwfzF/m86uVcTRbA2GKP/if+A5FpVOLMaDS9hXPxml/TVKv8UoAQNMLbcCWk0 goUv8U+V7qP5/jY13iaF5P2RpK9gHuaHrjGbjXm3CYd66YXcGfezzYwCt01GkCRxOB0V DLx4wivkzdtu5Le68ELgwCiMmbypgjyBfln/itK8s/wo3b8ZfwPTLnPLTD1qYLEZWD4v l8jg==
X-Gm-Message-State: ALoCoQkCbTBWQcRwML02Sl32tCuB8L+ElN2fH8N9zMPUpCoCwU58zeHeoqi8JhspY1YhHhe+57KQ
X-Received: by 10.68.125.164 with SMTP id mr4mr11512056pbb.27.1401392054137; Thu, 29 May 2014 12:34:14 -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 ue3sm2548582pbc.49.2014.05.29.12.34.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 12:34:13 -0700 (PDT)
Message-ID: <53878BBE.8020606@nthpermutation.com>
Date: Thu, 29 May 2014 15:34:22 -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: mrex@sap.com
References: <20140527212125.17AF81AD1D@ld9781.wdf.sap.corp>
In-Reply-To: <20140527212125.17AF81AD1D@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dCa9wi8U9LHMsnygNpZ41x8NPrE
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] IV Generation was: 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: Thu, 29 May 2014 19:34:20 -0000

On 5/27/2014 5:21 PM, Martin Rex wrote:
> Michael StJohns wrote:
>>
>> Continuing, the master secret *is* used explicitly as a MAC key
>> (finished message) and as a master key for a KDF (key expansion).
> Unless you're using a NULL encryption ciphersuite, the Finished
> messages _are_ encrypted, rather than exchanged in the clear,
> and there is a reason why the Finished message is truncated.
>
> For the two communication peers that are involved (TLS client and
> TLS server), the master secret is a shared secret.  For any attacker,
> the finished messages are not visible (encrypted).

Not really sure why this is relevant.  Are you arguing that the finished 
MAC isn't actually a MAC or the finished MAC isn't necessary if the 
handshake is encrypted, or isn't necessary if these messages are 
encrypted? Or that the key for the MAC isn't actually a key?

As a general comment, the security of the TLS handshake protocol 
shouldn't a) depend on the encryption of the handshake messages, or b) 
depend on the security of any part of the negotiated cryptographic suite 
except that specifically required for the handshake (and right now, 
that's only the PRF).  (e.g. I can't assume that the cipher suite isn't 
NULL for encryption when designing the security).

Encryption of the handshake is "nice to have" and "provides privacy for 
some elements of the handshake (e.g. certificates)", but isn't actually 
critical for the security (integrity/source authentication/key 
agreement/correctness/prevention of MITM attacks) of the protocol.


>
>> Seriously though - no.   Basically if you share it, it's no longer an
>> entropy pool, but a key.
> There is a necessity to share the master secret with your communication
> peer so that both can derive the same new secrets from it.
>

Hence my point that the master secret is a key, and not an entropy pool.

You've made a claim about the master secret (and the PRF) being more 
like an entropy pool.  Is there any literature to support your view?

Later, Mike