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

[Eric Rescorla <[e-mail]>]

On Wed, Aug 4, 2021 at 10:56 AM Kenneth Vaughn <[e-mail]> wrote:

> 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.
>

Just to clarify, this is not a "cipher suite" but rather a "signature
scheme". TLS cipher suites consist of the pair of AEAD and hash algorithms.


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.
>

Yes, that's correct.


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
>

I don't understand this point. There's no dependency here on TLS 1.3 at
all. You're just using the registry. In fact, nothing stops you from using
hash algorithms which TLS 1.3 doesn't support at all.

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)
>

I don't see how you can use either of the TLS 1.3 registries that include
hashes (signature scheme or cipher suite) as both have multiple entries for
the same hash algorithm (e.g., RSA and ECDSA with SHA-256, AES_128_GCM and
Chacha20Poly1305 with SHA-256). This is going to create an enormous amount
of confusion.


> 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.
>

I don't think continuing to maintain this registry will constitute an
appreciable amount of work for IANA. However, you could also just clone the
registry.

-Ekr


>
>
> 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]>
> wrote:
>
>> I would like to present 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]
>> www.trevilon.com
>>
>> _______________________________________________
>> Secdispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/secdispatch
>>
>
>