[TLS] CH padding extension

Christopher Wood <christopherwood07@gmail.com> Tue, 12 June 2018 17:41 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 9F34C130F83 for <tls@ietfa.amsl.com>; Tue, 12 Jun 2018 10:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 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_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 THrxyzUdDq-L for <tls@ietfa.amsl.com>; Tue, 12 Jun 2018 10:41:28 -0700 (PDT)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 0FBF0130F73 for <tls@ietf.org>; Tue, 12 Jun 2018 10:41:28 -0700 (PDT)
Received: by mail-yb0-x234.google.com with SMTP id x36-v6so8240773ybi.0 for <tls@ietf.org>; Tue, 12 Jun 2018 10:41:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nBIXkIcRVypUDj5saRGSEloXn/7HCspJ7o2g3pBZCoo=; b=ZKjzSjeYkmxyH+8vyJ/XJEA/paqn0QzgsY9Sd9n20Mkxf+6pLzIFFGXDdwMN3Q8oGl HIFk5JYXcU2TcKSnWnctLKQYTHLXznvUf/dXPJHC+uTtXLSECOtRZLxqO4a9EdXVWqOM rfi4r8aqooXSWonQsHaw0G+s1+DC/GTLrWx0UE5V8rwdre+17eQOnor9crmPISACGiBl 9Tl2UDfVoE7wDOKc3+COd7BIp19GBP1ak8KeAA0t/13yAHFqd9nXysT9C8akYCLnsoCx 9JSLVeGtlPXeIS8DKvkfEDCcidw5L2E0Wh80IqS2BA8IFrPIth9GOdz7KyHzXSgtQmca eLtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nBIXkIcRVypUDj5saRGSEloXn/7HCspJ7o2g3pBZCoo=; b=LkmVJF5jL93a99T1o1SdFYJ6YZYdlyrTGq5MThm4yrq8CtzK/EAEoAmyOeFCdCsRoS 5UOKP7p8lOJUdNlQRgx6OAFoSe9Low56fSrfrvMWX7taBpkCTkYSXoTdO5I1UKEtrMwT 64FhtHW+1emVjOjD9hOEYlWiW5CUaxmNdt2t2Ef0Zbr0EKYggA17k8eG6aYz3eIAqKi4 tX1CfsbSRbOSJLQKh7hs99AD9CH/iEqhNhDZp9Vh9YWGWoOvD2jP26KpLql6Kwj3jrOY 6wk+GUpNUqsGN98ZcJUhullVx6pX6kFzzWbZNjtXboknGrCOgsP+MKBHAjPZ7wghlnL8 qhxA==
X-Gm-Message-State: APt69E3ABcjO9O0KI9Bp8BeadkxQqRY6cDfj151IhR0sQJisQEwoq/qq pYaSmrs5QhZKUCsteeCmR+kBvM9ebUSOZE6I+xp29/Oe
X-Google-Smtp-Source: ADUXVKIh/s3ysIgY4y0i9SBbBLTAbKKtIaf0ujzEJRfP4pbkfa6TbaT2qvKRDWAAGokrQBxChaHRNBXXnMZmAgvF76Q=
X-Received: by 2002:a25:888e:: with SMTP id d14-v6mr670305ybl.506.1528825287003; Tue, 12 Jun 2018 10:41:27 -0700 (PDT)
MIME-Version: 1.0
From: Christopher Wood <christopherwood07@gmail.com>
Date: Tue, 12 Jun 2018 10:41:15 -0700
Message-ID: <CAO8oSXmMY6JzKrbBqqRp2KvW1qET9qTjfNhwNQ_M3PAFSBbeuQ@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2Lyxodyz0lCWaburCTfSqGuDM4E>
Subject: [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 17:41:32 -0000

Hi folks,

In Section 4.2 of the latest TLS 1.3 draft [1], the padding(21)
extension is restricted to the CH and no other handshake messages.
Another plausible spot for this extension is in the Certificate
message. Specifically, although we're encrypting this message, we may
not want to reveal its length. Adding a padding extension seems to
address that problem. Granted, RFC7685 [2] clearly indicates that this
padding is for the CH, and that server "MUST NOT echo the extension."
However, I don't think that rules out server-chosen padding for the
Certificate.

What do others think? Is this worth a change?

Best,
Chris

[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.2
[2] https://tools.ietf.org/html/rfc7685