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

Watson Ladd <> Wed, 07 October 2020 04:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB6623A1050 for <>; Tue, 6 Oct 2020 21:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TY0xNM-Kdo_S for <>; Tue, 6 Oct 2020 21:30:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36E313A103F for <>; Tue, 6 Oct 2020 21:30:57 -0700 (PDT)
Received: by with SMTP id b22so698977lfs.13 for <>; Tue, 06 Oct 2020 21:30:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KugSRzX/24CciVG9xu9rQwuN19Vim3IGxzAon6y9GuE=; b=mBcWJLSYWdL0eayFQUhTZNSqzo3bblVoGmNsxUj7aRinc5iNj0ehkbykexeKhkDW1C O3RZ6+RpUqyTqtUNJHz6O4cKB9IFUlET10nw5gxJUY1gvRHno8LqU7EPwAWEVTcEh7lX IeL55QCfFXQe1fFzIUhRdeIvaojD5FDQXQVe0uQPtp0t2A0/7lsV5NYgVtpEt1TJip3v rLn63MQyPWsxmOv8vsKfKmreIGCeYJxqMYpzkbe504ZwAJXB8wNay9cRvhkYr+VVnwXL WWTXtHADsA1r/5GIHSAKrzyhjf21CIEUi68CvF47qQTPnDjhZiWCXZ0qD2birjzwmb+t AXgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KugSRzX/24CciVG9xu9rQwuN19Vim3IGxzAon6y9GuE=; b=avuWX6BV4ab4zwVOpODMBHIRj6BdPfuByzJ2dh2LswucRjflx93BBm5lTtMnP5INMJ PWR5ZmJmdjasPex0r9FduWfxLP17GE/xqmJcE8t4NS05Rj0xMwGnl7O58F0PwUFLXVB7 4f+FgnjlL7OSRrX7kMjns6ZbjDDpnBoLwo4zNDGXpRyK7Q3ZXv+e/vI35Z4j69R7A6Wd Iie+qdd3FcdzsyUCoYGWJ9+UOzo9bcySTNNcvOTU8NyAx4J1/pgq1cTktOXaupT4HT0s vzSyI1BUHz8fVM18hH8vtSMO4qeMzDOqADUi/yjxhS1dxKywo7NtLj8PwM1paadDMKJO i4kQ==
X-Gm-Message-State: AOAM530KpLQDzUYJkRQC+fKkib8CCKTczRdPieGPCfAeo36oaFPTrouQ +36RheMs1rLwjxl9r4ao5zgVGvOJVLAxTluQMeY=
X-Google-Smtp-Source: ABdhPJxAiLFzO04uppvrQYLzu/gFnauCBwLdpM+fn1Y1B9caFP2ffqeh9OSK8roKDx8znCOGXWAubTm2ucOZXmTgQnw=
X-Received: by 2002:a19:1c8:: with SMTP id 191mr288889lfb.585.1602045055264; Tue, 06 Oct 2020 21:30:55 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Tue, 6 Oct 2020 21:30:43 -0700
Message-ID: <>
To: Christian Huitema <>
Cc: "Michael D'Errico" <>, "Salz, Rich" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Oct 2020 04:30:59 -0000

On Tue, Oct 6, 2020 at 10:13 AM Christian Huitema <> 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.

Watson Ladd

Astra mortemque praestare gradatim