Re: [TLS] Pull request for session hash

Watson Ladd <> Wed, 24 December 2014 19:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 45D191A1A56 for <>; Wed, 24 Dec 2014 11:21:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SS_xM3sYoQjD for <>; Wed, 24 Dec 2014 11:21:42 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8FD81A1A60 for <>; Wed, 24 Dec 2014 11:21:42 -0800 (PST)
Received: by with SMTP id z6so4241023yhz.30 for <>; Wed, 24 Dec 2014 11:21:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9A2w0QCkCZxh0HUVaKsoYhSAZ/m/smp9tI8n8sCm7lg=; b=WodSLSCiRvzm2eIQ+gSiklkI18rJnw6i0Axot4g06LtqBILDkU9i3d/NrHDcsNg/HT RjExE4TRNAN7kVsn48cE7MpXvsBT4SQmtUxNxKaWUqgLFFGq3s80uzFbSIDoSBU26Ek6 /kZMJhC1zjmrumikV29UjoytHha8fQrql9dx2SzmxgvLZZaUawr+GFRSCxkU0T4gyFPE OTmepv2ROhcrpmiEuZOJqLoRkWRUtk9UlKM3ONRWtUHN6Zeg+bVDLIPJ5WK/vTKAT+pi Gu2ij5bJT9p2afWruOeephkRm9zKRX1SACN8B/UuTSYke6++59yIcKkIzlaVdYhO65w+ 4wVw==
MIME-Version: 1.0
X-Received: by with SMTP id g124mr30958362yka.24.1419448901673; Wed, 24 Dec 2014 11:21:41 -0800 (PST)
Received: by with HTTP; Wed, 24 Dec 2014 11:21:41 -0800 (PST)
In-Reply-To: <>
References: <> <> <20141223142648.GA11149@LK-Perkele-VII> <>
Date: Wed, 24 Dec 2014 14:21:41 -0500
Message-ID: <>
From: Watson Ladd <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
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 19:21:45 -0000

On Wed, Dec 24, 2014 at 1:29 PM, Eric Rescorla <> wrote:
> 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.

I don't know why it existed in the first place, so I feel compelled to
ask what that reason was and why it doesn't still apply.

>> >
>> (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
> handshake
> 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
> here?

Application authors shouldn't depend on magic details for their
applications to be secure. So long as the exporter is capable of
generating keys used to encrypt or authenticate data, the application
author has to ensure that they don't accidentally do that. By making
it impossible to mess up, we make the application author's job easier.

I'm strongly in favor of making it easy to make secure systems.

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

I think we can deal with a more complicated implementation, so long as
exposing the feature isn't that complicated. Transporting data ahead
of checking who the person is that it is being sent to is very simple
to expose: a function to accept data and send it, and one to check if
the authentication is complete and who it is. Applications that can't
meaningfully deal with this can be written as normal. But I'm still
thinking about the right way to do this.

Watson Ladd

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin