Re: [TLS] WGLC: draft-ietf-tls-cached-info

Adam Langley <> Tue, 29 July 2014 17:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C00611B2949 for <>; Tue, 29 Jul 2014 10:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wa5acV6bHBMD for <>; Tue, 29 Jul 2014 10:37:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0CF71B293E for <>; Tue, 29 Jul 2014 10:37:19 -0700 (PDT)
Received: by with SMTP id ty20so6755528lab.4 for <>; Tue, 29 Jul 2014 10:37:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oTuajWWGUBbzWsVqhYlmNkmi4itTtu1i/galbEME48E=; b=euD/u13q2T3JekoxBYtuFRdZmxfAw+BJA3j/UsuiHBgn/iOtp90542FF3ZcSsg388p MZu4fFYw7J5aFcydF3FLFousRWGYsmdxF+OZYPU1ajRMlgXsG7zDyXdmzbGqmV1wspfE /0+UuMsmotl2/t3A9mA6/HEbmn+2gP8eUblfjMmvbok39FVX83iQcz1auixU1JOAjE4a 5FtQvomc3g5G/L85lbxFAlr+e5Cx5WbZAteFcpTKDgndVbNUdzbTKFOs9/2btmAVdMV7 ijI1MK8b1uB2wowh7XFhH5G36b+7whEsmKDI0eCAYVyVPQ97V7za4pn+1KLgXbuO8hO6 KCSw==
MIME-Version: 1.0
X-Received: by with SMTP id h8mr3641383lbs.69.1406655437509; Tue, 29 Jul 2014 10:37:17 -0700 (PDT)
Received: by with HTTP; Tue, 29 Jul 2014 10:37:17 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 29 Jul 2014 10:37:17 -0700
X-Google-Sender-Auth: hgOt_KcfMzLpBPwM42inEXlqyaQ
Message-ID: <>
From: Adam Langley <>
To: Sean Turner <>
Content-Type: text/plain; charset="UTF-8"
Cc: " (" <>
Subject: Re: [TLS] WGLC: draft-ietf-tls-cached-info
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: Tue, 29 Jul 2014 17:37:24 -0000

On Tue, Jul 29, 2014 at 5:48 AM, Sean Turner <> wrote:
> This is the working group last call for draft-ietf-tls-cached-info:
> Please send comments on this draft to the TLS list before August 19, 2014.

It's been quite a while since this has appeared!

As an implementer, I still think there are ambiguities in the draft,
although I might just be dumb. If I'm not being dumb then I don't
think this draft is ready.

Can I send multiple CachedObjects with the same CachedInformationType?
Nothing seems to forbid it and the draft hints that it's expected:

> Note: If clients make use of the Server Name Indication [RFC6066]
>  then clients may need to cache multiple data items for a single
>  server since servers may host multiple 'virtual' servers at a single
>  underlying network address.

That's cool, but if I offer multiple certificate_chain CachedObjects,
how do I know which the server is using if it omits it? Does it echo
the one that it wants to use in its CachedObjects? In that case, I
assume that it's invalid for a server to send multiple CachedObjects
with the same CachedInformationType? The draft suggests otherwise

> By
> returning the "cached_information" extension the server indicates
> that it supports caching of each present CachedObject that matches
> the specified hash value.

That suggests to me that the server's CachedObjects are just
indications about what types it supports. (But then why do they
include hash values? Does a client have to echo the CachedObject
exactly? I.e. with the same HashAlgorithm and hash value?)

The draft also says:

> Following a successful exchange of the "cached_information"
> extensions in the client and server hello, the server omits sending
> the corresponding handshake message.

But it doesn't actually seem to. E.g. if the handshake is using cached
certificates then the Certificate message isn't *omitted*, it's just

> How information is omitted from
> the handshake message is defined per cached info type.

Lastly, I think there are Triple Handshake worries in here:

> The Finished message MUST be
> calculated over the actual data exchanged in the handshake protocol.

The triple handshake fix works by extending the master secret over the
full handshake, including the server's identity. However, if the
server's identity is being replaced with an MD5 hash (and MD5 is a
value of HashAlgorithm[1]) then I think that might reintroduce the
Triple Handshake problem. The draft says:

> There is no requirement that this hash algorithm must
> have strong collision resistance.

I fear that this might be incorrect in the light of the Triple Handshake work.




Adam Langley