Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

Stefan Santesson <> Fri, 26 February 2010 12:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29D133A877B for <>; Fri, 26 Feb 2010 04:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.939
X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Go4ReAr9w52o for <>; Fri, 26 Feb 2010 04:04:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 415ED3A86C3 for <>; Fri, 26 Feb 2010 04:04:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AAFEA35F924 for <>; Fri, 26 Feb 2010 13:06:02 +0100 (CET)
Received: (qmail 56629 invoked from network); 26 Feb 2010 12:05:58 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <>; 26 Feb 2010 12:05:58 -0000
User-Agent: Microsoft-Entourage/
Date: Fri, 26 Feb 2010 13:05:57 +0100
From: Stefan Santesson <>
To: Simon Josefsson <>
Message-ID: <>
Thread-Topic: draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
Thread-Index: Acq23A2OBqBkcR6/S0W+TVZafeTOSA==
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "Kemp, David P." <>, "" <>
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
X-Mailman-Version: 2.1.9
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: Fri, 26 Feb 2010 12:04:05 -0000


I have to admit that it bothers me that this to me is so much a non problem
and that you and others insist that it is a problem.

IETF have tons of RFCs where the implementer can choose an arbitrary format
or type of value (like cipher suite, signature algorithm, etc). It is
perfectly understood that not everyone will implement every possible format
or value type, so RFCs often list one or a few formats or types that
implementers must support. If you want to be sure to interoperate, then
choose one of the mandatory to support options.

If you have a reason to use another value, then use that.

The negotiation mechanism is classic. The client provides a number of
alternative variants it can produce and the server chooses the one it
prefers. The client is free to remember this. This is already possible
through the current draft.

I can agree that it would be wise to include (as suggested by Martin) a way
for the server to indicate already in server hello which of the hash types
offered by the client that server prefers. I don't think it is necessary,
but if it can be done without too much problems, I will not object.


On 10-02-26 10:22 AM, "Simon Josefsson" <> wrote:

> Stefan Santesson <> writes:
>> Simon,
>> Note that the requirement is MUST support, it is not MUST use.
>> It is perfectly allowed to use SHA-256.
>> Does that solve your concern?
> My concern is to get algorithm agility working here, and that involves
> some form of negotiation.  Either explicitly in the protocol or
> implicitly through normative statements in the document.
> Saying 'you MUST support SHA-1 and MAY use SHA-256' without explaining
> how the choice is negotiated would not solve my concern -- if that
> wording is the only alternative to hard-coding SHA-1, I would actually
> prefer the latter.
> /Simon