Re: [TLS] CH padding extension

David Benjamin <> Tue, 12 June 2018 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E534E130E91 for <>; Tue, 12 Jun 2018 11:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.95
X-Spam-Status: No, score=-9.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qwFCnBwO54wz for <>; Tue, 12 Jun 2018 11:32:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85763130E90 for <>; Tue, 12 Jun 2018 11:32:30 -0700 (PDT)
Received: by with SMTP id j80-v6so15667410qke.9 for <>; Tue, 12 Jun 2018 11:32:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ysR+ex4TYf7Pn2EjPJpYDWl3Qv/LIvVTbEFBgjoBwIk=; b=j27VsupqlP5kP2IolHsadG470h5uuD+r3haxqwu23H6pqNSyF+9RfX1VwdeekyI+2l OKdpDVkiwkcJbWXypJNwwNDS/7HKBcbgyo7cN93KpHan2bXuEmUiT1qsrWUiL8WI4ym1 Y24uwdOcvGkc9EQzUilDyxaGstIthvjHyf/QI=
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=ysR+ex4TYf7Pn2EjPJpYDWl3Qv/LIvVTbEFBgjoBwIk=; b=Ys3F1s7WmssyFCyUD2uH0K66/yw6Hoo9hMNQdOaXiJ2lJPlfttD+mZ2BYhDzPCuYoO OWrtfZYZqE8xpNI0HcN55eDDtdp+YtSdgS5kObpf9oCUed7+g1uy4mRleUznWChCkMcs HymxofUM7CUGny7vQ1VaVjyRXXyzec8DGGogvKU3GbvVRxNq3M4Gh/Xwkp5rtK1QX8Zc HtvmcciIOP24ZJaep+AQs2G6WZWZg2G8ue7hp83IK4sDMH6blTo1KA3u6NgHTF4IX1We fnRq4nc9+pKyBcxnaEnefPhjGn3yhpGFCDFL0nCfG4ph+Rmj5sM6N1aLelNrR67nC9KW XFQg==
X-Gm-Message-State: APt69E30ysKOERpm2MXxBhyWiXHoC2BUvn0Fduy10p4kTXpVtpAocbR8 s1IpEvIHWtY9mnte8Uie4EdKUOLgCZgXtoRRAKh7JhQ=
X-Google-Smtp-Source: ADUXVKJvHapaY5tSa82IaUkFP+GRNmsKe7SGngbqfnTza60Cz5Ez0U3cRG2150AM2Sr/ZdaCqkiQIdpCpYDXSIA4X/E=
X-Received: by 2002:a37:285e:: with SMTP id o91-v6mr1555901qkh.129.1528828349196; Tue, 12 Jun 2018 11:32:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 12 Jun 2018 14:32:16 -0400
Message-ID: <>
To: Christopher Wood <>
Cc: Kyle Nekritz <>, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000ae2e46056e7616d1"
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:32:34 -0000

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

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.