Re: [TLS] encrypted content type and padding

Jeffrey Walton <noloader@gmail.com> Mon, 21 September 2015 07:19 UTC

Return-Path: <noloader@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F441A8870 for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 00:19:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 hdROCLpqny31 for <tls@ietfa.amsl.com>; Mon, 21 Sep 2015 00:19:31 -0700 (PDT)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 131AD1A886B for <tls@ietf.org>; Mon, 21 Sep 2015 00:19:31 -0700 (PDT)
Received: by igcpb10 with SMTP id pb10so72460840igc.1 for <tls@ietf.org>; Mon, 21 Sep 2015 00:19:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8s0ceITEBpsjI+yi+HBN385Cazl3SMAxuOEwYqQfEmA=; b=V+B6EoRnMJOYwus3ckeL9YyLT5L2Zu8NCcsFwjFju63JzK3NWRzpBa88+y2R2a+dKR VGsEUrkZfvkI+BizGb6GT2PM1r+WKoVCLPU9CTyxVqiwcHFfW2NfX1ZkScTYOaah7Nke BmCHsUwRgF/BvWxs0zZ7lWYS4TRkFAe2+qIkRYkaMVCaMAF8r0SCnR15mdzVH7EJ4nc6 qeCznzWeou8WCzCsHYHgbG2AJr6+Q3fpqpV6sJ4VyAcZUf/WQzqPE5n+D5hFsE5qo0uS NMafwoIm/M7D4Kv6srPJG88sbTqqyWscdz458jnF1YGnsSG5oLx4zrMiovjyzPaz0Egc 6kgw==
MIME-Version: 1.0
X-Received: by 10.50.102.4 with SMTP id fk4mr9813037igb.46.1442819970426; Mon, 21 Sep 2015 00:19:30 -0700 (PDT)
Received: by 10.36.123.131 with HTTP; Mon, 21 Sep 2015 00:19:30 -0700 (PDT)
In-Reply-To: <87bncw1ch4.fsf@alice.fifthhorseman.net>
References: <87bncw1ch4.fsf@alice.fifthhorseman.net>
Date: Mon, 21 Sep 2015 03:19:30 -0400
Message-ID: <CAH8yC8=tNRp_hp8CBhsUwRq6WhZPXmgn4MnoHh-vcqtGSWWqnw@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/15aRT2HRCYhIraPRNkbHbMUYR0E>
Cc: IETF TLS Working Group <tls@ietf.org>
Subject: Re: [TLS] encrypted content type and padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
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: Mon, 21 Sep 2015 07:19:33 -0000

On Mon, Sep 21, 2015 at 3:02 AM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> Hey TLS folks--
>
> apologies for the delay in sending these pull requests.
>
> encrypted content type:
> -----------------------
>
> https://github.com/tlswg/tls13-spec/pull/51
>
> This should be uncontroversial, and just needed freshening against the
> current draft.

:)

> padding:
> --------
>
> We're now proposing that handshake padding should be offered by
> introducing a new HandshakePadding message.  I've avoided any sort of
> padding negotiation in the handshake in favor of making padding always
> available in TLS 1.3 and up.  Life is simpler this way.

Padding can create oracles and complicates proofs.

When sending data that needs to be padded during key exchange, then
fill it up with random data and digest it in HKDF- like fashion.

When sending data that needs to be padded during bulk transfer, then
don't do it. Use GCM, CTR, etc.

Why make life more complicated then it needs to be?

Jeff