Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

[Anders Rundgren <[e-mail]>]

On 2020-10-07 19:47, Mohit Sethi M wrote:
> A strong +1 on the security issues of decode -> extract -> re-encode ->
> verify signature flow. The lack of canonical encoding can also mean that
> the resulting bytes can be different in different encoder/decoder
> implementations.
> 
> It would have been nice to have canonical JSON. Some implementations
> support it with flags such as "JSON_PRESERVE_ORDER"
> (https://jansson.readthedocs.io/en/2.8/apiref.html) Some specs try to
> specify things like keys should be in alphabetical order but fail to
> realize the complication with nested structures.

Hi Mohit,

Since a few months back there is an RFC (8785) which specifies a
scheme for canonicalizing JSON, albeit limited to the JSON subset
supported by ECMAScript and browsers.

It can be tested in an on-line application where it is combined with
JWS: https://mobilepki.org/jws-jcs/home

Anders

> 
> CBOR has thankfully specified canonical representation (called as
> deterministic encoding in 7049bis). Some CBOR libraries have added
> support: https://github.com/agronholm/cbor2/issues/6.
> 
> --Mohit
> 
> On 10/7/20 7:30 AM, Watson Ladd wrote:
>> On Tue, Oct 6, 2020 at 10:13 AM Christian Huitema <[e-mail]> wrote:
>>> On 10/6/2020 10:00 AM, Michael D'Errico wrote:
>>>
>>>> It matters in X.509 certificates because the basic
>>>> encoding rules (BER) allow you to specify the same
>>>> thing in different ways.  With DER, there is only
>>>> one way to encode every element, so everybody will
>>>> come up with the same string of bytes and hashes of
>>>> those strings will be the same, signatures will
>>>> verify, etc.
>>>
>>> Well, we have learned a few things since 1994. The DER rules are defined
>>> to allow a "re-encoding" workflow:
>>>
>>> * Sender side: prepare the message, encode with DER, sign the result
>>>
>>> * Receiver side: receive the message, parser with generic ASN.1 decoder,
>>> process the message using the "parsed" representation, re-encode with
>>> DER, check the signature.
>>>
>>> Experience showed that this workflow is very problematic, because the
>>> parse/reencode process may introduce subtle changes and the signature
>>> will fail.  One may argue that these changes are due to implementation
>>> bugs, but fact it that this is a rich environment for growing bugs.
>>> Based on experience, the receiver side is better done as:
>>>
>>> * Receiver side: receive the message, save it, parse and process, and
>>> when it is time to verify the signature go back to the original message
>>> and check the signature.
>> Examining signed data ahead of verification, particularly to determine
>> what should have signed it, is fraught with issues. In particular
>> parser errors that would only be exploitable by trusted parties become
>> exploitable by anyone. Furthermore, you should know the expected
>> signer ahead of time. That this isn't possible in X509 due to
>> inordinate flexibility is one of many pitfalls for implementors. This
>> sort of issue periodically leads to authentication bypasses and other
>> such fun.
> A strong +1 to this.
>>
>> Sincerely,
>> Watson Ladd
>>
>>
>>
>> --
>> Astra mortemque praestare gradatim
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>