[TLS] Possible TLS 1.3 erratum
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
Re: [TLS] Possible TLS 1.3 erratum
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
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
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 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
> 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] Heads up on Netdev conf 0x15 - not too late to attend!
Hi, For those that have not already attending Netdev, Netdev conf 0x15 has been running since July 7 but it runs for 3 weeks but the talk sessions don't start until Monday. As usual a lot of IETF relevant talks. See: https://netdevconf.info/0x15/accepted-sessions.html The fee is USD $50. Students(proof required) are 50% off. The first 2 weeks was keynote, workshops and tutorials. You can replay all the sessions you missed by entering the conference platform (registration required). The keynote was by Hari Balakrishnan, see: https://netdevconf.info/0x15/session.html?keynote-balakrishnan On Monday as well there will be an industry perspectives panel on smartnics which will involve 6 vendors and an industry veteran moderating the session. For registration go here: https://netdevconf.info/0x15/virtual.html Yours, Daniel -- Daniel Migault Ericsson ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible TLS 1.3 erratum
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
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 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
>> 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
