Re: [TLS] PR#1091: Changes to provide middlebox robustness

Watson Ladd <watsonbladd@gmail.com> Wed, 08 November 2017 00:25 UTC

Return-Path: <watsonbladd@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 787EE129BF8 for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 16:25:52 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bFloFiZ4ucdk for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 16:25:51 -0800 (PST)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 225FD129B16 for <tls@ietf.org>; Tue, 7 Nov 2017 16:25:50 -0800 (PST)
Received: by mail-vk0-x233.google.com with SMTP id v3so673672vkb.8 for <tls@ietf.org>; Tue, 07 Nov 2017 16:25:50 -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=WB6rKf9EvQ6+/CyuZXLIY3m5u53dQO52ZlqKQHUI4qU=; b=SVDqh4xepc1aVZnTSjcj40NB/UblIM3KKbxU3unmRvt2zGg4xC4W15LO+891pFVNgo wthlLidUeX372LwiqhAvHnGtJ83iQ0NkB0axlt5oPtow7N9aNIstcub0pMtqe5XS7caY n5SjYpuGNKiIVGhyuRiN0ur/HkU3llPPkUU/p6BiCJRO85RxOh16NcMmtrkmcA1Hjb4I jY15ufF5AAQMbIKz2HrJZTSmbM5JT6dkK2OgsiSGHork6dSYXtl040TMq+FHPtTEW6FC HledYKvRJHNEdAC8zOvZZ0YJ+VY9/g0j244Io5GgbBFaPpdBIu8+7op//QNGCrI+D9UF Q53A==
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=WB6rKf9EvQ6+/CyuZXLIY3m5u53dQO52ZlqKQHUI4qU=; b=WQQraz68wq2EfUi70/ppCx4D/pj8cZe8sLINkS2goJE45BX9WW7dW20bcL8iU1Va4h l9v3rv/vl2bgJDfhavm+g9bnD9HeL+Kpa2pyJjJ8FVmlgg45wnyD6NK+93dX1e4tQe3e 8sVR1VQTC8e5qgSQ4q/JzbP7CFZLgxU+LEZXK6TDxLx1PyIkSX3TJ/3LsVosotczfKjc CZ35TCnah8NBjLflrdtrvDCA/i/ro/vt54swWh+Sx5X0DbZwKdcRxYE/iQYrOoVku4wT i9EFOvJKu83d6EP9kHjMnexy7itC0pbNwAy8JwBBQNxdtTsf4z1+s6tGovM6j42cuBfL Nzvg==
X-Gm-Message-State: AJaThX53UDTtHwHtqVBqduEUTy56yDhgT8JhegEJFgCLZECRhNYtQJW+ wk9xYVIRcbrAVvKy63WNuOqN1N9ijVFwadkT88c=
X-Google-Smtp-Source: ABhQp+QW7uWfM2vS0ogDRWv/vpMUvzjCeawr3BGWFKRSSOTj6Mh75XzxTEWTYWcem9pQ01aikrXCtTngewlbMIClN5Y=
X-Received: by 10.31.226.3 with SMTP id z3mr364951vkg.193.1510100748961; Tue, 07 Nov 2017 16:25:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.11.132 with HTTP; Tue, 7 Nov 2017 16:25:48 -0800 (PST)
In-Reply-To: <CAGD1bZaBOC-adMAOkBohGoVqf3RbGeLDxgPdqaV0a4OOttqAiw@mail.gmail.com>
References: <CABcZeBNm4bEMx0L6Kx-v7R+Tog9WLXxQLwTwjutapRWWW_x9+w@mail.gmail.com> <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <CABcZeBOxEAVUAq6+cSD9P+e0VHvgJHvrgj6uENbvf9aWnZooKg@mail.gmail.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> <CABkgnnWt4NYuGKOoCfH3x6oSHXbC90ubJM64ArYiNG+9qhXQWw@mail.gmail.com> <D517CEA4-AF57-4F87-9D66-4A2D0299ED17@akamai.com> <CABcZeBNkgO2efWJL4bNDqVnCVr9+Hpg_D+b8ebNukf=HpHnujA@mail.gmail.com> <CAGD1bZaBOC-adMAOkBohGoVqf3RbGeLDxgPdqaV0a4OOttqAiw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 07 Nov 2017 16:25:48 -0800
Message-ID: <CACsn0cnfV1G0PSPZzbFDkKGd-1a3BhFh3UY3o0Xr529ht=Lg8w@mail.gmail.com>
To: Jana Iyengar <jri@google.com>
Cc: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/drTr1gYPEpiRUk8VS1MUWnG0LCA>
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 08 Nov 2017 00:25:52 -0000

On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <jri@google.com> wrote:
> FWIW: In my experience middleboxes don't ossify based on what the spec says,
> they ossify based on what they see on the wire. So, if common
> implementations send CCS in a particular way, that's what will get --- and,
> I'll argue, what has gotten --- ossified. I also agree with David and Eric
> that compatibility mode shouldn't be required because QUIC doesn't need it.

What does compatibility mode mean here? If we end up with having two
slightly different versions of TLS 1.3, one that looks more like TLS
1.2 and the other that does not, that doesn't seem like a good thing
to me.

My understanding is we already have ossification here and the debate
is what to do about it.


-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.