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

[Watson Ladd <[e-mail]>]

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.

Sincerely,
Watson Ladd



--
Astra mortemque praestare gradatim