IETF Logo Mail Archive

Re: [TLS] Padding extension and 0-RTT

David Benjamin <davidben@chromium.org> Sun, 30 October 2016 19:52 UTC

Return-Path: <davidben@google.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 34FA1129473 for <tls@ietfa.amsl.com>; Sun, 30 Oct 2016 12:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 UPMmkz-GMo_b for <tls@ietfa.amsl.com>; Sun, 30 Oct 2016 12:52:32 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 D4B2F129408 for <tls@ietf.org>; Sun, 30 Oct 2016 12:52:32 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id 62so64614751oif.1 for <tls@ietf.org>; Sun, 30 Oct 2016 12:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=k9lgKDELG4AmlvzCztOyBC4GMCrqKFTxSJQNNUAH1Z0=; b=dJMASYBq3jI/VLUhXuH7plB+z6MZbEWwRk7CebHrfk+EnxhbVKPCc81PvJ99dupbwl yLNuL/sWn2vUEgqDSyChCy+JiEvg2Uja+ywYONG2KXC3ZePWh0iqikkG++quyo4ojXEh aouqD2p01YmR0dusPD+wuvSO9W+OeWeTfvTUM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=k9lgKDELG4AmlvzCztOyBC4GMCrqKFTxSJQNNUAH1Z0=; b=F9V4h26M9l66zi+xxSNXSU7Ff+4s492uC1edh6l+1dYGc8OEYKIzGaD4o7GtC0HSCG aaBE9w2i8FkiUK2OSY2R1frPDB5l/F0PaTHwAl1o6RG1Hc0Q2mQwb30eDPWcglYV/BR3 QBdqft8/xLB8hqyCfo2NtjCybTwIrmxQYdQmBC1biDdZR7EV42yCb2QNMLz/z27h9wk/ QhqqO3tBkYLXPApEwgVOekmM/wZUfBbheanBFHNnRmKP+pXl0UPQ5oTNguBCzn7lrJD9 XNtLj+GJdCrGrCJ7eSM5uFYaMo3i7irNRsmFjdDsnLcWSmZ397WPOWG9/+xVfHDC+gqv Cqdg==
X-Gm-Message-State: ABUngvcijwY7MwTyHnShI7NFmAseXUd8ag7sqfuDtLNIs5IfX4Xr5B7jJ93ZAmBGaajkZ2nYIs3fMJGTAn4q/USM
X-Received: by 10.107.15.146 with SMTP id 18mr20561884iop.22.1477857152022; Sun, 30 Oct 2016 12:52:32 -0700 (PDT)
MIME-Version: 1.0
References: <CABkgnnXfJ9+DLZNnF+nZ8z91ce3Hmi-gVNyypcZZpwr_gx3HPA@mail.gmail.com>
In-Reply-To: <CABkgnnXfJ9+DLZNnF+nZ8z91ce3Hmi-gVNyypcZZpwr_gx3HPA@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Sun, 30 Oct 2016 19:52:20 +0000
Message-ID: <CAF8qwaC2CBuWyiSrh2uQH7rL50u3n4mUHoEHoKacsAFKURMDFA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113ed64a938c4905401a6e6e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-7ln04EoU9CPcqjs8iVBX1noBUM>
Subject: Re: [TLS] Padding extension and 0-RTT
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: Sun, 30 Oct 2016 19:52:35 -0000

Sounds reasonable.

One concern is the F5 bug's failure mode was a timeout rather than an
error, so, if you take away padding, the allowance in C.3 will not save
heterogenous deployments where some servers do 1.3 and some are old F5
servers. But given we're talking about a straight-up server bug now, it
seems reasonable for a client to say, okay, I will try to account for
heterogenous 1.2 and 1.3 deployments because that's kinda operationally
tricky, but if you've got that F5 bug, please fix it already.

David


On Sun, Oct 30, 2016 at 6:03 AM Martin Thomson <martin.thomson@gmail.com>
wrote:

(Trivial optimization warning)

Just perusing my draft and noticed that NSS pads a 0-RTT handshake,
which is not that surprising given that it's fairly beefy (it will get
even larger in -18).  Since a 0-RTT handshake will break servers that
don't at least superficially understand TLS 1.3, maybe we could avoid
pading in this case.  Is there any reason we shouldn't include that
advice in the draft?

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email