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

Dave Garrett <> Wed, 23 December 2015 19:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2149C1A1A14 for <>; Wed, 23 Dec 2015 11:54:40 -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 yPowxVoI39yK for <>; Wed, 23 Dec 2015 11:54:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A6511A1A0C for <>; Wed, 23 Dec 2015 11:54:38 -0800 (PST)
Received: by with SMTP id k189so164255095qkc.0 for <>; Wed, 23 Dec 2015 11:54:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=s4yAYLHR4EcN35LFE5NhZoMnf0WdhK1GAXM/rzesg1k=; b=kxZE0CakvIAxQVZhcwiqK+eLSA7ukM8AbWksWN4Zf44aDVe6Hs6mTd28w/VyjqENP8 8TLFoBknWLakheWd4knpqEXgWH3pjSaEmzPrIloW6SuV4//MJ0DEiBmk/Y0YmuYvcT+N F46+and1DY9QPSKC06/nbNvJbDlrlWDMVRTYs1vt5FoGyW4Iu+znGoPwJ6PuyhNQ4H1x oqYXfwIGwn4qCh1vGqnw0n2/QTQNfBRKh2GXIVqhwQKLO7z26j5K7Gy9TlIlixCgcJZA Ice60TWZWncEmbpm3ATYNwY+B9eOmO7E5TkTYmQdfYUSOdelPLGdHqbGH1+jzCvTZl46 IEGg==
X-Received: by with SMTP id e126mr42341948qkb.17.1450900477784; Wed, 23 Dec 2015 11:54:37 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id g132sm18560453qhc.46.2015. (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 23 Dec 2015 11:54:37 -0800 (PST)
From: Dave Garrett <>
To:, Hannes Tschofenig <>
Date: Wed, 23 Dec 2015 14:54:35 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
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: Wed, 23 Dec 2015 19:54:40 -0000

On Monday, December 21, 2015 02:35:11 pm Hannes Tschofenig wrote:
> On 11/20/2015 03:16 PM, Stephen Farrell wrote:
> > - 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.

You need to reduce the max size of hash_value by two now, too. Now that CachedInformation is a max of 255 bytes, hash_value+type has to be a max of 255, thus hash_value can have a max of 253 with CachedInformationType being one byte and the length of hash_value being another byte.

Reading the design in full, I think it might be a better idea to just set a fixed size for hash_value instead of using a variable size vector. Your design only relies on collision resistance of the hash and are truncating to 32-bit. I would simply set the hash_value size to a fixed 4 bytes and state that future hash algorithms used MUST NOT have a collision resistance worse than SHA256 when truncated to 4 bytes, which seems like a perfectly reasonable requirement to me. Switching to a fixed size structure has a few benefits:
1) Smaller, as you don't need to send lengths anymore.
2) Simpler to iterate through a client's CachedInformation if needed, as all entries are of the same size.
3) More clear spec, as the struct definition directly reflects how things are actually going to be used, rather than over generalizing.