Re: [TLS] Possible TLS 1.3 erratum

The SignatureScheme change was perhaps overly clever, but the intent is
that you can process them the same at both versions and backport
the single-enum interpretation. (That's what we do.) The key observation is
that TLS 1.3's allocations will never overlap with a defined TLS 1.2 hash
or signature value. So an old implementation will never send a value that
overlaps with TLS 1.3. More importantly, it will interpret any new TLS 1.3
value as {unknown hash, unknown algorithm} and ignore it, which is what we
want it to do anyway.

That means an old implementation will interop just fine with new values,
and we can freely recast the whole extension as SignatureSchemes in new
implementations.

On Thu, Jul 15, 2021 at 9:02 AM Eric Rescorla <ekr@rtfm.com> wrote:

> As we are currently working on a 8446-bis, the best thing to do would be
> to file a PR at:
> https://github.com/tlswg/tls13-spec
>
> Thanks,
> -Ekr
>
>
> On Thu, Jul 15, 2021 at 3:56 AM Peter Gutmann <pgut001@cs.auckland.ac.nz>
> wrote:
>
>> I've got some code that dumps TLS diagnostic info and realised it was
>> displaying garbage values for some signature_algorithms entries.  Section
>> 4.2.3 of the RFC says:
>>
>>       In TLS 1.2, the extension contained hash/signature pairs.  The
>>       pairs are encoded in two octets, so SignatureScheme values have
>>       been allocated to align with TLS 1.2's encoding.
>>
>> However, they don't align with TLS 1.2's encoding (apart from being 16-bit
>> values), the values are encoded backwards compared to TLS 1.2, so where
>> 1.2
>> uses { hash, sig } 1.3 uses values equivalent to { sig, hash }.  In
>> particular
>> to decode them you need to know whether you're looking at a 1.2 value or
>> a 1.3
>> value, and a 1.2-compliant decoder that's looking at what it thinks are
>> { hash, sig } pairs will get very confused.
>>
>> Should I submit an erratum changing the above text to point out that the
>> encoding is incompatible and signature_algorithms needs to be decoded
>> differently depending on whether it's coming from a 1.2 or 1.3 client?
>> At the
>> moment the text is misleading since it implies that it's possible to
>> process
>> the extension with a 1.2-compliant decoder when in fact all the 1.3 ones
>> can't
>> be decoded like that.
>>
>> Peter.
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>