Re: [TLS] AD review of /draft-ietf-tls-cached-info-20

Hannes Tschofenig <> Mon, 21 December 2015 19:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 510871AC416 for <>; Mon, 21 Dec 2015 11:35:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wBGD3D5Ry4yz for <>; Mon, 21 Dec 2015 11:35:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 983CA1AC417 for <>; Mon, 21 Dec 2015 11:35:14 -0800 (PST)
Received: from [] ([]) by (mrgmx003) with ESMTPSA (Nemesis) id 0M0xbD-1aSV3i2OUx-00v8Nl; Mon, 21 Dec 2015 20:35:10 +0100
To: Stephen Farrell <>, "" <>
References: <>
From: Hannes Tschofenig <>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Mon, 21 Dec 2015 20:35:11 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sbs2XAI29fI3PrqKPkwfsBinJLElEH0c1"
X-Provags-ID: V03:K0:BClusRdVLxWLGJTvltKtw2pPteMYldHa7JXQ9v1+jPpRiBZ2u/9 yWvzpQnSSRyWsmKkeDpHnylNPpZBZZ1HZ8954TSRersX1+XJFRfYo1tbY94Y9cQju0fXf1A a+YWdnyoN5HK9aVWeX2XiZX/8jX1k1+JUCxIQaEvM1vF5uuAaDCHpK0541vvv3p+duDtoFh 5N5XcR1Spgbs5yblJssuQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:UlU+3G5+AdQ=:ihxvmv6mwBWdlzSVsJc8g8 2ajqNuePhvaNT//8urkrueUaU999dmxcWJhMw+wpAb3Vo7664tTZ3994R8UNuvhnoyPOJE8/a fmVmEKaRa+1QtruDgCp06w4OhAwtRF0p+M5EqgGVlh5pAvLQN1gczuVJEmyQNEMbiUN45IKRX XOdIRGUUx4lWQdhP35sWMc/vmiDbC04c5eLviwloZm6zXIt6K0BIHlamCfK6qrmQQAA6Jb029 I4xBrfqVbPVNa+bG8aVtnIu8IMeIUtZehgRsvzn9pHt5Ly9F2lzIYSiCMyXgJ9DQJivyNuLkt pNxZKyuswPqE9Ip47CepN2jjoKps0BihXIYYPoitJ7dbpzFryk1MyOV66G5dMcxH7gxC5jywq vyQMMo9MhnZMWrjOWhXTY1uAginY2g/99vI1SfCsux/naMnY/4vc+/NZ4SqIF6Yx+R/yMWiSR +Pj/Osxlf9nCxGd+pgljcO9VY2n813EAKMBOICaWZJd+kTriPAS6EJJHcJ0UcEzE4XI0nrZbc M5hkhnTFoaHIWNGxRNxum0wY3C3yuHBx0NmSlC10y2wEKwc/FJazLtoMA+AWNHHb/W1VkFHAg 25RaPaL9b8U9Hicwujil//CozHPe4lVNMmyVDQvOkA/uedNhoRhw3WELdSNvM+PoENKmN6MYt 9fBc2n9Kz6W3QwhGI0I+4xIK+hDo26xvCGKWJlNWIRfqK7sV4Xml7/KZFdLJl1W6qjZYxriKl G2eIC5qh5kNDwSUz6KDsJeqiLGH+zLPf86rUjNgwvr0vP3RcWAWuqshmz1w=
Archived-At: <>
Subject: Re: [TLS] AD review of /draft-ietf-tls-cached-info-20
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: Mon, 21 Dec 2015 19:35:16 -0000

Hi Stephen,

thanks for your review comments.

On 11/20/2015 03:16 PM, Stephen Farrell wrote:
> Hiya,
> I've requested IETF LC for this one. (Sorry for being slow
> getting to it.) Please treat my comments below along with
> any other last call comments.
> - You probably thought about this but I forget the argument.
> Wouldn't it have been better to include the cached info that is not
> sent within the transcript? I can't see an attack myself, but then
> we didn't get the triple-handshake problem even after the initial
> double-handshake attack was known.

You are actually describing the problem we were having: We had both
versions throughout the history of the document. There is this feeling
that there could be an attack (somehow) but nobody knows how it works
and so it is hard to decide for one or the other approach.

> - ID nits complains that 6234 has obsoleted 4634, and indeed so it
> has:-) I'll note that in the LC announce.


> - 2^16-1 CachedObject instances makes no sense at all, that would be
> bigger than the full handshake. Why not pick a sensible value?  Even
> if you don't put such a value in the syntax, you could at least say
> that e.g. N instances will likely be pointless, for whatever N
> (10-ish?) would make the h/w bigger overall.

That's indeed a bit large. I reduced it to 1..2^8-1.

> - page 6: wrt 7250 do you need to say that the server can tell which
> thing (cert or SPKI) the client has cached from the hash value? I
> think it can only work that way, but it might be worth saying that.
> If it works some other way, then I didn't get that, so probably some
> other bit of text would be needed.

I added a note. I do indeed assume that the server is able to select the
right certificate/SPKI from the received hash value.

> - typo: consideratios



> Cheers,
> S.
> _______________________________________________
> TLS mailing list