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

Benjamin Kaduk <bkaduk@akamai.com> Wed, 08 November 2017 13:55 UTC

Return-Path: <bkaduk@akamai.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 2D140126C3D for <tls@ietfa.amsl.com>; Wed, 8 Nov 2017 05:55:05 -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, HTML_MESSAGE=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=akamai.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 j515G6XoMH5t for <tls@ietfa.amsl.com>; Wed, 8 Nov 2017 05:55:03 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32153126CD6 for <tls@ietf.org>; Wed, 8 Nov 2017 05:55:03 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA8Ds1rv011621; Wed, 8 Nov 2017 13:55:01 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=FXudQ+IhUagMSCe3drvTK52cxOsbMfN+pDkv/6tc6fs=; b=cYof1WslDe1xmB63eU2EJORxMs353PoJnifqf70KFqrxeuhwI7fWLhdL4MeM83xezle9 99YRK03DeMlJRuSx9dY+TDYu0tyEYWEdo+Mb/gq8CdQozDRKVVQCbcwDKiSvhs0F7+D5 CtfurizGkGWgxFPiNj2pHw9riQx5HJMyjZt1ZzijW7jqCJZZXxbsqhHEPANQ1GBtF/nx lWYQysFIuAZYxSPi1avRb3XwJ6wj2q/ac96eM6iRgau8B4SaFLVGApuB73dNfQNz7uQD v/LAULlAPAJOz6qqimX5VI+f3bW3i9Y77Xha22nQaQrYj+b/wGhFxVn0rPfh5p43p9TR 1Q==
Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2e40q1rjvw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Nov 2017 13:55:01 +0000
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA8DpSJ3005746; Wed, 8 Nov 2017 08:55:00 -0500
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2e18vvypnx-1; Wed, 08 Nov 2017 08:55:00 -0500
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 99E39839B2; Wed, 8 Nov 2017 06:54:59 -0700 (MST)
To: Eric Rescorla <ekr@rtfm.com>, Nikos Mavrogiannopoulos <nmav@redhat.com>
Cc: "tls@ietf.org" <tls@ietf.org>
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> <1510132329.17184.123.camel@redhat.com> <CABcZeBPA9AFzaJh_sqN+EUzRNRD-verk+c6_AS9xumhru+WPwg@mail.gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <126ede22-36d3-42d5-18fd-511b7e1349c7@akamai.com>
Date: Wed, 8 Nov 2017 07:54:59 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBPA9AFzaJh_sqN+EUzRNRD-verk+c6_AS9xumhru+WPwg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------0C41299F2A571CAFE3AA3F12"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-08_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711080189
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-08_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711080189
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/54jxLhoc0mVhmMuCnZdRL04o0x4>
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 13:55:05 -0000

On 11/08/2017 07:34 AM, Eric Rescorla wrote:
>
>
> On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos
> <nmav@redhat.com <mailto:nmav@redhat.com>> wrote:
>
>     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 <mailto:watsonbladd@gmail.com>>
>     > wrote:
>     > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <jri@google.com
>     <mailto: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. 
>
>
> It doesn't introduce different handshake state machines, because you just
> ignore the CCS.
>

I am leery of things that we flat-out *ignore*, as that sort of thing
has a history of coming back to bite us.

>  
>
>     Why not negotiate that
>     CCS addition with an extension and have it defined outside the TLS 1.3
>     spec?
>
>
> That actually does introduce different state machines.
>

True, but perhaps still worth thinking about.
In some sense, we might not even need an extension; we could take
Martin's idea and run with it -- server MUST send CCS if the client
sends a sessionID, and server MUST NOT send CCS if the client does not
send a sessionID.  This would still make the state machine bigger, but
avoids a fork that depends only on "what message do I receive here".  On
the other hand, it also places all the burden of deciding when to use
the compat scheme on the client, when people are making the case that
some servers, at least, have some sense of when they're behind a
relevant middlebox.  But I'm not entirely sure how convincing those
arguments have been, so far.

-Ben

> -Ekr
>
>     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
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls