Re: [TLS] Pull request for session hash

Eric Rescorla <> Wed, 24 December 2014 18:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A28021A1A1D for <>; Wed, 24 Dec 2014 10:30:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wsFwB-IsiD19 for <>; Wed, 24 Dec 2014 10:30:15 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 057641A09C9 for <>; Wed, 24 Dec 2014 10:30:15 -0800 (PST)
Received: by with SMTP id l18so11920191wgh.2 for <>; Wed, 24 Dec 2014 10:30:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WNCpCXxTYAP8GUoDkHh/vPaO0yabYOiHFw9XnMsbtLQ=; b=OElbJJYBnau42MyuyxO8kVJYflvy0cVsFFYKWmxPShfn4F6gTDNIllnabAywQNr6nY PxtFxyenSZncbP40Tm+eUB926gIEKvr1xT9DeOpzoj5V4ONQWxNSQDjwCKe69WhSmRHf EDKWAK9YTkU4saz0m20EgyptAhjKJMNY3M/Ez8e+0ZQ2SDkj8GxOJ1taumDk1spbUaoD HzoF0AEbRpn1Unsj3HeAICMrnO53Tx4+8U28P0PxKuB7RmQnjsHKB4bYMQ3tsqACbejw xKO9AiyyyaqcrWfNco+RxZe3FK3FVj/ppCFNPOJYH57OhS/IGLXyXKM4fkWabSnGwsMc FB8Q==
X-Gm-Message-State: ALoCoQnttBHX9ykVHaWAfRzoXI6DZ2A2HDUY5nK+THXJaUBvxwGqBEf4MrW29Jm2K9kCWiX+iT0T
X-Received: by with SMTP id 9mr66438539wjt.115.1419445813796; Wed, 24 Dec 2014 10:30:13 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 24 Dec 2014 10:29:33 -0800 (PST)
In-Reply-To: <20141223142648.GA11149@LK-Perkele-VII>
References: <> <> <20141223142648.GA11149@LK-Perkele-VII>
From: Eric Rescorla <>
Date: Wed, 24 Dec 2014 10:29:33 -0800
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary="047d7b3440ee82773f050afa7bf9"
Cc: "" <>
Subject: Re: [TLS] Pull request for session hash
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: Wed, 24 Dec 2014 18:30:18 -0000

On Tue, Dec 23, 2014 at 6:26 AM, Ilari Liusvaara <> wrote:

> On Mon, Dec 22, 2014 at 01:33:13PM -0800, Eric Rescorla wrote:
> > I've posted an updated PR at:
> >
> >
> >
> > Note that I did not restore the ChangeCipherSpec message as my sense of
> > the WG discussion and private conversations was that people preferred to
> > have it gone. If you feel strongly about this change one way or the
> other,
> > and haven't already posted to the list about it, please do so now, as I'd
> > like to resolve this and merge this PR this week.
> >
> (General philosophical note: I'm in favor of more complicated protocol if:
> - It fixes something that is just plain nasty to analyze, or
> - It causes bad implementations to break fast instead of being security
> timebombs.)
> Regarding CCS removal, I'm very much in favor.
> Reading through this, some comments:
> "At this point, the handshake is complete, and the client and server may
> exchange application layer data, which is protected using a new set of
> keys derived from both the premaster secret and the handshake transcript
> (see {{I-D.ietf-tls-session-hash}} for the security rationale for this.)"
> AFAIK, I-D.ietf-tls-session-hash doesn't really contain security rationale
> for this. It only has security rationale for hashing exchange keys (which
> are included in the first keying anyway) and says about including
> certificates (paraprhased): "Compliant with NIST recommediations" and
> "SSH does this" (actually, it only does that for server key, not client
> key).
> Now, if EncryptedExtensions contains extensions that twiddle with some
> critical parameters, there is very much reason to rekey after that.

In conversations with the INRIA guys, the general consensus seemed to
be that hashing more was more conservative. I'll work with them to get
some text around this either here or in the session hash draft.

> "[[OPEN ISSUE: Should we restart the handshake hash?

> I regard restarting the hashes as very dangerous (not that I think that
> the whole HRR is a good idea, but I don't say more about that).

The expectation in the current draft is that you do not restart the
hash, but I know there are different opinions about that, hence the open
issue. Let's discuss this separately, since the only change in this area
in this PR is to add the issue marker.

"This master secret value is used to generate the record protection
> keys used for the handshake, as described in {{key-calculation}}. It is
> also used with TLS Exporters {{RFC5705}}."
> Wasn't there an idea for giving TLS Exporter its own master secret?

That would stop applications from exporting important system keys.

I suggested that, but  upon reconsideration it seemed a bit
over-complicated. What's the threat model you have in mind

> "If the server does not request client authentication, the master
> secret can be computed at the time that the server sends its Finished,
> thus allowing the server to send traffic on its first flight (see
> [TODO] for security considerations on this practice.) If the server
> requests client authentication, this secret can be computed after the
> client's Certificate and CertificateVerify have been sent, or, if the
> client refuses client authentication, after the client's empty
> Certificate message has been sent."
> Server can't send data on first flight (to anonymous recipient) if
> it requests client authentication? E.g. HTTP/2 settings blocks,
> protocol banners or various other protocol capability negotiations.

That's correct. This is obviously not ideal but the alternative with this
design is to have an even more complicated key schedule. The idea
behind PR 95 ( is to
address this, though that's of course not the only way. What are
your thoughts here?

> Obviously, generating the resumption premaster secret has to wait for
> client finished (otherwise one can run into trouble with just
> transport glitches, no attackers required).
> Looks like for the resume case, the ClientHello and ServerHello are
> hashed into keys. I think this should be done (I don't se attacks
> otherwise, but that doesn't mean there could not be one... This
> is another of those "I don't want to analyze that" places).

If I am reading this correctly, you are happy with this piece, or are you
suggesting a change?