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

Nikos Mavrogiannopoulos <nmav@redhat.com> Wed, 08 November 2017 09:12 UTC

Return-Path: <nmav@redhat.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 A3A3E13183C for <tls@ietfa.amsl.com>; Wed, 8 Nov 2017 01:12:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.421
X-Spam-Level:
X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 K3Eq6dBsejX6 for <tls@ietfa.amsl.com>; Wed, 8 Nov 2017 01:12:13 -0800 (PST)
Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) (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 DFA82131878 for <tls@ietf.org>; Wed, 8 Nov 2017 01:12:12 -0800 (PST)
Received: by mail-wm0-f65.google.com with SMTP id z3so9161942wme.5 for <tls@ietf.org>; Wed, 08 Nov 2017 01:12:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=IV2vyjcMK00uRLFSMv4heXK5wt4K5IgmUL3dUmM1nlU=; b=SxQa0CBBI8MtQEhbqGk3m//FsTsgEHJNdYb5tQk0JQ8j9ovKkhbZ6qq4E/kSR+/UiW oB6oXRwBPXNo55B1SBslxhFnLmZd6Ox3jCUoOaSqpSMZXb0vg0OHtobcBLMT0R2kKGvh 6g4Bchys4dIPinH32HY00asrLJlAMea0pWQ0y8CPPrsSPW4b6CmXXIShfKSUaHFkXtkP i17XQa0gJOrjipHSWeiRwr3ZJP3o40mAuzIDZO/+0ynCIUeWaFwYj98PLAizWtmdp0J8 ei4zdEy/I/c1GyxTLtpjTddJIWa2+JAq+52Ill5JdOPX52vLXOGZkePL2SB78z3rQ8oZ fuZQ==
X-Gm-Message-State: AJaThX6XiNcDCpg4aDfc1mFgA4G/alN/0aiuV2SZy+A3lOe7Kp2Boimj DN+Vp19DqcdBqa5mXiv60KdgIA==
X-Google-Smtp-Source: ABhQp+Sks5EUpHzQ4UqpZ6x4dLlKgy1uXrLkFMfvCPgvNmC3yzDiuO3CP8BPAJ7I6aYnzoK6ATYzww==
X-Received: by 10.80.170.107 with SMTP id p40mr2623338edc.158.1510132331026; Wed, 08 Nov 2017 01:12:11 -0800 (PST)
Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id i16sm3157519edj.77.2017.11.08.01.12.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 Nov 2017 01:12:10 -0800 (PST)
Message-ID: <1510132329.17184.123.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>, Watson Ladd <watsonbladd@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Date: Wed, 08 Nov 2017 10:12:09 +0100
In-Reply-To: <CABcZeBNesAA3qG=4mpyq2B+23HpXD66ePdk61OzwQQXHmUB1gQ@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> <CACsn0cnfV1G0PSPZzbFDkKGd-1a3BhFh3UY3o0Xr529ht=Lg8w@mail.gmail.com> <CABcZeBNesAA3qG=4mpyq2B+23HpXD66ePdk61OzwQQXHmUB1gQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26)
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hAhyiry8XQIkeIamCmZ4jKHRVLw>
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 09:12:15 -0000

On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote:
> 
> 
> On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd <watsonbladd@gmail.com>;
> wrote:
> > 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?
> 
> It means:
> 
> 1. Send the fake session_id
> 2. Send a bunch of spurious CCS values.
> 
> 
> > 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.
> 
> Well, the idea is that this is a purely local decision by one side.

Which increases the cost of TLS1.3 implementation and testing by
introducing different handshake state machines. Why not negotiate that
CCS addition with an extension and have it defined outside the TLS 1.3
spec? I understand the concerns of the browser "community" on being
100% backwards compatible with middle boxes, but the TLS1.3 standard is
more than just browsers. If 100% compatibility is required, there is a
very simple solution, use TLS 1.2.

regards,
Nikos