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

On Tue, Oct 6, 2020 at 11:37 AM Michael D'Errico <mike-list@pobox.com>
wrote:

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

Hopefully https://tools.ietf.org/html/rfc8446#section-4.2.11.2 makes it
clear why the pre_shared_key extension must be at the end of the list.

>
> Mike
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>