Re: [TLS] Application Data payload

Martin Thomson <martin.thomson@gmail.com> Mon, 06 March 2017 22:52 UTC

Return-Path: <martin.thomson@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 EB4B1129A69 for <tls@ietfa.amsl.com>; Mon, 6 Mar 2017 14:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 NYCGvUKM5l49 for <tls@ietfa.amsl.com>; Mon, 6 Mar 2017 14:52:39 -0800 (PST)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 D9E22129547 for <tls@ietf.org>; Mon, 6 Mar 2017 14:52:38 -0800 (PST)
Received: by mail-qk0-x235.google.com with SMTP id p64so61547482qke.1 for <tls@ietf.org>; Mon, 06 Mar 2017 14:52:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5yJzGqlS0R/Z82Jrkr++DpqSWddQWoDr6g6LZabqzWY=; b=Hu61EhvM9GGnbc3j1Xvn5y1ZD7PUuz5N9uHoJVTQ/6+c5r6yJeqNrp+SEozWw6jkOm Jx/EvJE3spx3N2nM4+m+PIJ06cKnQr2rAFcNQSQzA1s2Xwl5tk/9b/QZVMpM4kBhNBWS jTcrGEPkFqufAfmraMhWWi+KOmW573mi4aXk9kINlUi+LdunoHq3BqlLLAjN1CtqAFR4 Zu29bjU+BOu/lNhj6v5eOxD1BbP3OOo37E0iLzmPajgJ26P/JX7cDJRdZgYfN+8jnKOy 1XQZltDJD1lmbYGf7NYkT6jziglQEM1eGBBwjRrP8sm1oPyGM77QpOf+c/GZR/hNY7IK 0rzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5yJzGqlS0R/Z82Jrkr++DpqSWddQWoDr6g6LZabqzWY=; b=OM4lqXJoK/ob/6R42vNhFq+1653tmy0b/WSZWzc4Zu/lEafSclV7FLt5io04Qf5MmT OhyJW4ZUBzUpi9BSKx/+LJ166/2aNogycC+21dG25xFt0iJy13PjPc2gLAhwWSA86Q85 vfYiCXph6u54dsMTgYMYv0R3wN8GRJnQleytxYDTHuDuc45o/JuSGNOaFPicbReVZzRF 7I7dXsCoGbjuDFZRQ39AmfRnJ0UtU0s+abd30wcRjLhuYbpLNEjPXQk0EK+WaWYYBYMz FqSYTVOqze+NSU+lyy5fmRXsLrypeZJwx/XZ1GSVJM79tH2Ln3N+7O4gtqkywagpM5wl wXcQ==
X-Gm-Message-State: AMke39kPQ7M5o9KjrlKMEqhtWdWnfqxvDNzmUOgZIN8BuKdJo1gAou2Ncwk6o/2SI2gqiz2ih8vK4gLLdxvHEA==
X-Received: by 10.237.41.100 with SMTP id s91mr19453568qtd.143.1488840758028; Mon, 06 Mar 2017 14:52:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Mon, 6 Mar 2017 14:52:37 -0800 (PST)
In-Reply-To: <CAF8qwaCHxuei3Y+W6QzwzmAg5vSFh=nJ_E1Ya62CvGTEXZdFAg@mail.gmail.com>
References: <CABkgnnXXQs0fLb0igzhwo=9Jgp5WjN49nFS00843g-WB=U0qhQ@mail.gmail.com> <CABkgnnWBb14uZis1RMJymuBGrHXBsxEQV8mHGY1WgHkJOhPVyQ@mail.gmail.com> <CAF8qwaCHxuei3Y+W6QzwzmAg5vSFh=nJ_E1Ya62CvGTEXZdFAg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 07 Mar 2017 09:52:37 +1100
Message-ID: <CABkgnnVqRCsLpkDXghKpWBMVcVpYGP8C_xbGVXdphFeYA_eXqg@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EwDVSxkYT1j3Werdgeaus46lgu8>
Cc: Filippo Valsorda <filippo@cloudflare.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Application Data payload
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 06 Mar 2017 22:52:40 -0000

On 7 March 2017 at 08:43, David Benjamin <davidben@chromium.org> wrote:
> To clarify, our interpretation of the spec was that it is the encrypted
> data, not unencrypted data.

Well, clearly we disagree.  To be clear, I don't mind much if it's the
encrypted data, though we'd need to also agree if the count included
the authentication tag (yes, probably) and the record header (I don't
know).

You appear to be conflating two things:

1. The amount of data that a server might have to hold on to when it
accepts 0-RTT.  The original reason Filippo suggested this feature was
so that it would be possible for their servers to hold 0-RTT data
until the handshake was complete.

2. Records that do nothing other than waste server time.  Into this
category we can place records with only padding or very little actual
data, extra key updates, CertificateRequest, and - the one you
highlight here - early data that is ignored.

My interpretation was that the first the only thing that needed tight
bounds, the second could be quite fuzzy and could come down to things
like current server load and DoS mitigation strategies.

We really need to agree on the right answer here.