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

[Stefan Santesson <[e-mail]>]

Simon,

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.

/Stefan



On 10-02-26 10:22 AM, "Simon Josefsson" <[e-mail]> wrote:

> Stefan Santesson <[e-mail]> 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