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

[Michael D'Errico <[e-mail]>]

I think we are in agreement.

On 10/6/20 13:12, Christian Huitema wrote:
> * 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.

I recall that at least one root certificate had a
SEQUENCE encoded using BER-but-not-DER (?)  Yeah if
your software re-encoded that, it would no longer
be the same sequence of bytes.

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

This is how I did X.509 verification, though I was
late to the game and the advice was already there
to accept a BER-encoded certificate.  Not sure if
I would have done the DER re-encoding bit if that
was the current advice at the time since it seems
like the wrong thing to do, but maybe I would have.

> If we do that, then there is no reason to mandate minimal length
> encoding. And TLS already does that. For example, we do not reorder
> extensions according to some canonical rules before placing them in the
> transcript.

I was disappointed to see that the TLS 1.3 spec now
has a requirement to put one of the ClientHello
extensions in a specific place (last in the list).

We discussed this at length during the development
of either TLS 1.2 or one of the extensions (maybe
renegotiation-info?) and we ultimately came to what
I believe was the correct decision never to require
any ordering of the extensions.  Sad to see the
group capitulated to whomever said it would make
their software easier to write (which I doubt).

Mike