Re: [TLS] CH padding extension

Christopher Wood <christopherwood07@gmail.com> Tue, 12 June 2018 19:08 UTC

Return-Path: <christopherwood07@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC6D130E7C for <tls@ietfa.amsl.com>; Tue, 12 Jun 2018 12:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV5suo7E8jLX for <tls@ietfa.amsl.com>; Tue, 12 Jun 2018 12:08:01 -0700 (PDT)
Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1540F130E77 for <tls@ietf.org>; Tue, 12 Jun 2018 12:08:01 -0700 (PDT)
Received: by mail-pl0-x236.google.com with SMTP id c23-v6so16011plz.12 for <tls@ietf.org>; Tue, 12 Jun 2018 12:08:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=jl8w81GWu6111ibzbNTLMS/jlO3eZLqz2Kzb9N4XhwY=; b=YC/Pzlvza0GTXi30pNT8ytGH47ZhZsqKtDdnJRXaJ9l4dPMcF9fnkeHF9wOa3yWWly NoX8TJgNoi4Omva7hdaAF4mBbdCZBaukGTCDNPJuobs+rFk6R/hisH4+za4cRPPi/YVO MSYKsR957ThWHsoUrUcvwtM3vHXvGiSIsZREJulusE6REnExvSOXWBNBiwqfkH0tPrT8 3dBVPdEVNulBFHRIX+JJGMzlNGopDcXp11P2ZqWLG/dJAgHskMcLz50uzeqWAsUUX22X /+0AS+p9oeEk+OxsSOtG4IR1MWxiMLTslqLCuvh9Q0HiHzobkCiesAf315qrbY52dVxI FQhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=jl8w81GWu6111ibzbNTLMS/jlO3eZLqz2Kzb9N4XhwY=; b=DCM4i1uFqXFSV+RAaYd3adPcCwBUbcT7oTnBIS0guNKJolENe9Knn+GqcU6CVD++0N Z7UzOooy93fiPzFM8ZauN2b/IuEX9WXNJrWZ1Mw8f9gOTvIGicKqMpQ6Lt5MPreR6j/H b99LldCJXW4G3dA0QWAsGq83umt0upoeoT3aQO0Vq33/qx0nCbyTKSTDH3vmwxwDoF8q CSxDgI5SOj3G2ZajeCtrUqzngYE9kotHd9yT/zgI7d7o2O4Lxkg6eAp7YA32c+WrpBCM +VfyYtrWL8z3nCajNz4ErzSmJPDEXK16qXa0yi2NyXay8J6hgTtc5A83HWJ1MDEtxPec scTQ==
X-Gm-Message-State: APt69E10qjK0z5u6BZi60ie3Fyj37a8WtVlAd8aCfIPhTtpA7meZhxcs xjuNDnGhmodR4EbtIg0QQ5A=
X-Google-Smtp-Source: ADUXVKIv9I4R+h2PE5sB2VQZSukpeXC8MkuQROD9gdpemFOGspm8qCk5upTWSNuug4AgpKqz6gZa+Q==
X-Received: by 2002:a17:902:7888:: with SMTP id q8-v6mr1755656pll.79.1528830479727; Tue, 12 Jun 2018 12:07:59 -0700 (PDT)
Received: from [2600:1010:b01d:a8c0:1::] ([2600:1010:b01d:a8c0:7544:76d2:9562:4160]) by smtp.gmail.com with ESMTPSA id y18-v6sm965228pfl.122.2018.06.12.12.07.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 12:07:59 -0700 (PDT)
Date: Tue, 12 Jun 2018 12:07:31 -0700
From: Christopher Wood <christopherwood07@gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: Kyle Nekritz <knekritz@fb.com>, "=?utf-8?Q?<tls=40ietf.org>?=" <tls@ietf.org>
Message-ID: <020e7b24-1015-4b6a-817c-0c12d754875d@Spark>
In-Reply-To: <CAF8qwaBFWiN6bZkOhYoYoSC+O6xvFpDFVH9hPB8po5DMwdYAAw@mail.gmail.com>
References: <CAO8oSXmMY6JzKrbBqqRp2KvW1qET9qTjfNhwNQ_M3PAFSBbeuQ@mail.gmail.com> <MWHPR15MB1504272D9A44F7D361DF54D2AF7F0@MWHPR15MB1504.namprd15.prod.outlook.com> <CAO8oSXnnXfo0U1vhN40bm87Riy726hgXMD_XF0aS2FqvXmz7Pg@mail.gmail.com> <CAF8qwaC5F1MY3sE=Ri9475n2aSxtii77xHONoTE3SRQCTqGzNA@mail.gmail.com> <CAO8oSXnASznQe0zk6nwBhBk1oMSk50+DXWJg=9uy4uQwiqOkmw@mail.gmail.com> <CAF8qwaBFWiN6bZkOhYoYoSC+O6xvFpDFVH9hPB8po5DMwdYAAw@mail.gmail.com>
X-Readdle-Message-ID: 020e7b24-1015-4b6a-817c-0c12d754875d@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5b201a05_625558ec_45b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QORDkoHCObUDIg_JhHP79n7optA>
Subject: Re: [TLS] CH padding extension
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2018 19:08:04 -0000

Got it — thanks for the clarification! I agree with your conclusion assuming we do not want to make an incompatible wire format change. However, if we’re willing to budge on that, I think it’s worth including. I’m curious to hear what others think.

Best,
Chris
On Jun 12, 2018, 11:48 AM -0700, David Benjamin <davidben@chromium.org>;, wrote:
> > On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood <christopherwood07@gmail.com>; wrote:
> > > On Tue, Jun 12, 2018 at 11:32 AM David Benjamin <davidben@chromium.org>; wrote:
> > > >
> > > > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <christopherwood07@gmail.com>; wrote:
> > > >>
> > > >> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <knekritz@fb.com>; 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.)
> >
> > Sorry, that was probably unclear. What I meant was: I agree that record-level padding is pretty difficult to use in general, but this particular instance is probably(?) not too bad, so it seems sufficient to use the existing mechanism rather than make a wire-incompatible change (unsolicited Certificate extensions are forbidden) at this stage.
> >
> > Though I otherwise don't particularly object to jamming the padding extension into more places, the compressed certificates point aside.