Re: [TLS] CH padding extension

Christopher Wood <> Tue, 12 June 2018 18:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B14C130E91 for <>; Tue, 12 Jun 2018 11:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 iRLv4I0hyXt9 for <>; Tue, 12 Jun 2018 11:44:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0779130E77 for <>; Tue, 12 Jun 2018 11:44:53 -0700 (PDT)
Received: by with SMTP id p14-v6so7854850ywm.11 for <>; Tue, 12 Jun 2018 11:44:53 -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:content-transfer-encoding; bh=O7L/eZM2dfVosrCV9qOTzrMKSbtTqCoaJzlGN4GEYoU=; b=mcz5++h0CVntM3kkSg1RzS2qB+OQnrNeQrvbTYS51p4UANCgWjUQub2zQ6v5pWpwnB e3VrBDvwrDML/Uy76xR6069w81XtAcYWgR6lyvjU3d4FHaxveNOr+iqPxCtak6JXjlg5 SfuPhQZ3kP7Ivm21a/zKo9fOxVaoOvC2vFQYIBL4l0KxEEgqi0MV5lxtDYtjiXQdJIDW ahxRDPozBn9RTZnQIiv0kXrnK7SXbmxSVhRNLXaZyvwMMlIw8wbI+U+Pl8dzW5ulBiXL IxZgwSmvgz21joShsULkA1CVa7fmIZKFGVIW8mjSwfjOZvsJ5PamELJYOKbc3WNWFVbg /mkQ==
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:content-transfer-encoding; bh=O7L/eZM2dfVosrCV9qOTzrMKSbtTqCoaJzlGN4GEYoU=; b=CrBRWTdP8qDTYMc7EF8UPA2rdFyzez55DEnWvTOyfd6i7ZVrDUnXtIeQTjNjhNmpnG UySl1DfDtnzKIGZeGdE87xKgVKZhfT7uj09hHpT6VHCqWD3hNdtyuhg4sWLEtAUdmpF2 WlBOKXkNfcj7qjlsNAvD4f5zTza6nEUXZYZ2WRuaJMmf9ri+XOdgqR9qQ+xVd5J6em7a HLt8SYEl4gQ1eKxuESi+jRREamOSNxKWhf9rNPgtiyw0CFXq4pLNkQq1IrOQi65c6+nt 6b4zIMZviAaFdbgIe8JKLScjUdcg65JHCzd60ZZk78wesLFCOOtRsY0D2qXB5cNDdF9S whzw==
X-Gm-Message-State: APt69E0wTFUHTZ7jurOvVXix17SnwFx6gXkqAAA1W0qDHOUZWVgZKv8q MwNczx/CECFxOHKg1nkOtMXQt7GJiVE5NplCKpw=
X-Google-Smtp-Source: ADUXVKLdtn9yIJLb+S0FO696OPd8xXGKEvGehQP/gUHzC2TZ9ID+ZImUIOb+CA6jCfGO5w519lgGbp4UdspWVPFzHS0=
X-Received: by 2002:a0d:e345:: with SMTP id m66-v6mr780904ywe.304.1528829092670; Tue, 12 Jun 2018 11:44:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Christopher Wood <>
Date: Tue, 12 Jun 2018 11:44:41 -0700
Message-ID: <>
To: David Benjamin <>
Cc: Kyle Nekritz <>, "<>" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] CH padding extension
X-Mailman-Version: 2.1.26
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: Tue, 12 Jun 2018 18:44:57 -0000

On Tue, Jun 12, 2018 at 11:32 AM David Benjamin <> wrote:
> On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <> wrote:
>> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <> wrote:
>> >
>> > Since the Certificate message is sent in an encrypted record, the normal record padding mechanism (section 5.4) can be used, rather than sending the padding as actual handshake data.
>> Of course, and that requires padding on the fly and some way for the
>> sender to know what is the correct amount of padding per Certificate.
>> Plumbing up that API seems non-trivial. In comparison, one could
>> imagine pre-padding wire-encoded Certificate messages a priori using
>> the extension. So I still think restricting padding to CH is a bit
>> extreme.
> Using the padding extension isn't going to mesh well with the compressed certificates draft. (Compression is perfectly compatible with hiding the length. If all your certificates compress well---they probably do---you can pad based on the distribution of compressed lengths you're trying to mask. Of course, this will leak whether compression happened, but that's not the information that's interesting to hide.)

Yep, valid point.

> Record-level padding is indeed kind of annoying to plumb properly though. I've always thought the excitement for padding at that layer was somewhat misplaced. I could imagine allowing handshake messages to be punctuated by no-op padding messages, but then it's just one layer to route through to get to the record layer here. I think it's more at higher up the stack where record-level padding really becomes impractical.

To be clear, are you suggesting that adding a padding extension to the
Certificate message is impractical? (I wouldn't consider this
record-level padding.)