Return-Path: 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 ; 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 ; 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 ; Tue, 12 Jun 2018 10:41:28 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id x36-v6so8240773ybi.0 for ; 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 Date: Tue, 12 Jun 2018 10:41:15 -0700 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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