Re: [Secdispatch] Requesting agenda time for draft-vaughn-tlstm-update

[Kenneth Vaughn <[e-mail]>]

Correct, TLS 1.2 provided separate one octet identifiers for the hash and signature algorithm. TLS 1.3 replaces the two identifiers with a single, two-octet cipher suite identifier that indicates a unique combination of hash and signature algorithm. The former method provided for 255 hash algorithms and 255 signature algorithms - apparently, it was determined that some combinations did not make sense so the values were combined - meaning all 65535 values can be assigned to meaningful combinations but also meaning that we can no longer assume that the first octet uniquely identifies the hash algorithm by itself.

If the IANA continues to maintain the TLS 1.2 hash algorithm registry, I agree that there could be an easier fix for RFC 6353; but there does not seem to be any guarantee at present that this will happen as TLS 1.2 ages. This results in two possible paths forward:

Option 1 is that we require the IANA to continue the maintenance of the 1.2 registry AND we create an update to RFC 6353 that clarifies that the 1.2 hash algorithm registry should still be used for the fingerprint, even when using TLS 1.3 (the update is needed as the mapping for 1.3 is ambiguous otherwise) OR 

Option 2 is that we update RFC 6353 with a new fingerprint algorithm that uses the 1.3 registry (and then there is no additional requirement on IANA)


Our proposal was based on the concept that, if we are updating RFC 6353 anyway, we might as well decrease long-term maintenance issues for IANA (but recognizing that this is a bigger change on the standard and on implementations). But I agree that the work load could be shifted to IANA, which would simplify other issues. What is important is that we reach consensus on the approach to be followed and document the decision so that it is unambiguous. It's largely a question of who has to do the work.



Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
[phone]
[phone] cell
[e-mail]
www.trevilon.com

> On Aug 4, 2021, at 12:01 PM, Eric Rescorla <[e-mail]> wrote:
> 
> Hi folks,
> 
> I'm trying to follow the change in S 2.1 about the TLSTM fingerprint.
> 
> In TLS 1.2, one represented signature algorithms as:
> 
>       struct {
>             HashAlgorithm hash;
>             SignatureAlgorithm signature;
>       } SignatureAndHashAlgorithm;
> 
> We found in TLS 1.3 that it was not really possible to mix-and-match
> them and so changed this to a two-byte SignatureScheme that represented
> the pair of hash and algorithm as well as any other values but without
> any other internal structure. E.g.,
> 
>           rsa_pss_pss_sha256(0x0809),
> 
> As I understand it, 6353 used the TLS 1.2 HashAlgorithm identifier to
> indicate which hash was used to make a fingerprint, and you're changing
> this because TLS 1.3 deprecated this field? If so, I don't think this
> is necessary: you're not referring to anything in TLS, you're just
> reusing the code point. So, I would probably not make any change
> here.
> 
> -Ekr
> 
> 
> 
> 
> 
> On Sun, Jun 27, 2021 at 7:31 PM Kenneth Vaughn <[e-mail] <mailto:[e-mail]>> wrote:
> I would like to present https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/ <https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/>, a new version of the proposed update of RFC 6353 (TLSTM). Based on feedback from this group, and the recent IETF decision to finalize DTLS, the ITS community decided to keep support for DTLS in the update. The result of that decision was to reverse a number of changes in the text and it made more sense to write the proposed new version 01 as an update to RFC 6353 rather than a replacement of RFC 6353. The result is a shorter document where the changes are more evident.
> I would like to request 10-15 minutes at IETF meeting of the Security Dispatch group to discuss the possibility of launching an effort to continue the development of this document as an official IETF document.
> Regards,
> Ken Vaughn
> 
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 77354
> [phone]
> [phone] cell
> [e-mail] <mailto:[e-mail]>
> www.trevilon.com <http://www.trevilon.com/>
> _______________________________________________
> Secdispatch mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>