Subject: [TLS] TLS Cached Information Extension: Hash Algorithm Indication

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2012 12:35:30 +0300

Hi all, 

I went through the review comments in an attempt to compile a new draft version by the deadline. 

Ekr explained me that the issue of hash algorithm negotiation had been discussed in the past already and it was decided not to provide support for it. 

I don't have hash algorithm negotiation in the -11 version of the draft and so I will also not add it.

Version -11 did, however, define a hash algorithm registry and Sean asked why I am not re-using the TLS hash algorithm registry, see http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-17, and to use it in the newly defined field. Rob raised a related question and suggested to re-use Stephen Farrell's work on draft-farrell-decade-ni [1], which also seemed like a good fit. 

We would need to make a decision about the direction we should go with the indication of the hash algorithm. There are at least four options:

1) No indication. Just the hash is exchanged without an indication of the hash algorithm being used. 
2) The hash algorithm is indicated in a newly defined field  and a new hash algorithm registry is defined in the document. This is the approach currently used in version -11 of the draft. 
3) The hash algorithm is indicated in a newly defined field but the existing TLS hash algorithm registry is re-used. 
4) We use Stephen Farrell's work and use the nih URI scheme.   

I think #3 and #4 are good approaches; I have a slight preference for #4.
 
What are your thoughts? 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2012 13:39:31 +0300

I made a minor mistake below: The suggestion was to re-use the Named Information (ni) URI and not the Human-speakable (nih) URI format. An example for such a URI is ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
(taken from http://tools.ietf.org/html/draft-farrell-decade-ni-09)