Regarding
> so where 1.2 uses { hash, sig } 1.3 uses values equivalent to { sig, hash
}.
While some TLS 1.3 SignatureScheme enum values might appear to have the sig
in the upper octet and hash in the lower octet, that is not the case and
SignatureSchemes for TLS 1.3 only exist as combinations with all parameters
specified. (Some SignatureSchemes, e.g. ed25519 and ed448 don't decompose
into a separate sig and hash.) It does not make sense to think about
decomposing the on-the-wire representation of a SignatureScheme into a
separate sig and hash.
> 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?
I don't think an erratum or PR is necessary. A TLS 1.2 server can process
the extension as specified in RFC 5246 (and the TLS 1.3 values will be
ignored as {unknown hash, unknown algorithm}). A TLS 1.3 server can process
the extension as values from the TLS 1.3 SignatureScheme enum, even if TLS
1.2 is negotiated. There's no incompatibility here.
On Thu, Jul 15, 2021 at 7:53 AM David Benjamin <david...@chromium.org>
wrote:
> 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 <e...@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 <pgut...@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
>>
> _______________________________________________
> 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
