The concept of automatically registering new hash algorithms was discussed 
during a May e-mail thread. Jürgen objected to the automatic recording of 
values and Tom Petch argued for the automatic registration. 

While I don't think we ever achieved "agreement" on the position, we concluded 
with consensus (i.e., no sustained objections) on the wording in the current 
draft due to the fact that there was agreement that there was no requirement 
for our fingerprint to use the same hash as used by the TLS layer (and thus no 
technical requirement to link the two registries). From that point, we 
concluded that if anyone wanted a value, they "would find the energy to 
register it" and we would not clutter the registry with unnecessary values.

Personally, I see the argument on both sides and am fine with the consensus. 
However, I could perhaps see softening the expert review statement to 
automatically approve the request to add any hash algorithm that is already 
approved for any version of TLS or DTLS rather than fording a consultation with 
the TLS WG.

I've made the other changes, but will hold off on implementing them until we 
resolve this issue..

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-571-331-5670 cell
[email protected]
www.trevilon.com

> On Sep 27, 2022, at 10:36 AM, Joe Clarke (jclarke) <[email protected]> wrote:
> 
> I am reviewing -07 of this draft ahead of the shepherd review.  I have found 
> a few nits, but at a larger level, I think more text might be needed for IANA 
> around how to handle the new TLS hash registry.  Currently, the draft talks 
> about a sync to “IANA TLS HashAlgorithm Registry”, which is good.  But what 
> if new values get added to the cipher suites registry?  For example, what 
> about GOST variants?  I would think if the TLS 1.3 spec (and their experts) 
> allow for these algorithms would this registry not just take them?  What 
> would the expert review consider when adding new algorithms here?
>  
> In terms of nits:
>  
> Search for “ciphersuites” and change to “cipher suites” as that is more 
> consistent with other documents (and I think you use both in this document).
>  
>  
> Section 2.1:
>  
> s/Values zero through 2/Values 0 through 2/
>  
>  
> Section 2.3:
>  
> s/stated that TLSTM/states that TLSTM/
>  
>  
> Section 3.1:
>  
> s/request, offer or use/request, offer, or use/
>  
>  
> Section 7
>  
> Add a period to the end of the section.
>  
> Joe

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to