Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Eric Rescorla <ekr@rtfm.com> Fri, 28 October 2016 18:04 UTC

Return-Path: <ekr@rtfm.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 207AA129675 for <tls@ietfa.amsl.com>; Fri, 28 Oct 2016 11:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 1anSy_3sAyXO for <tls@ietfa.amsl.com>; Fri, 28 Oct 2016 11:04:38 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 486C4129444 for <tls@ietf.org>; Fri, 28 Oct 2016 11:04:38 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id w3so95556296ywg.1 for <tls@ietf.org>; Fri, 28 Oct 2016 11:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q9ZCkrfd9hAC0zQoH/jMHo5bCdJP5iEWQE19qy0zyiw=; b=032EEL+6UIpZZg75BcB9fFzLPiK/+sqjvIlIBOo5idTU4HrBL+QfhxJz1XKjdbgECo XVjD05qzqXaGom+Hy6FhgC7T/spQdbggIpLCZMf8KxgO45e2no7mv1cTHKg4Uy9klJpZ hVgZS4j9qxCfGJmuYN+nHB4e4dotF1U2E0gxSVlcWFi9z++rVamwWqtDg2XRyozZz2D6 L4GMe8dxOeisD6NkKQp3J84ArdzB0o0AUCi/DtXNV8MnwZtDjh/IOKIGcm0zhsGZFpD6 J/eArxaF7Wc6MCWAfVtt79QioKuNCDYSkBWcbG+E0XA1xn7FOYPYVPFYPEvCgyu3sJMp E8Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q9ZCkrfd9hAC0zQoH/jMHo5bCdJP5iEWQE19qy0zyiw=; b=IMITZ5vvjyUHtfd7XlKPEbzsdVkTdrIuxzAb12dbfGbC8lCK1YEYRDcwlKZmGY3Oag axJu7V/UwMqpATZdQx0NKydP2IuKB3QgS6xnKjppAc2ku9H16hMl6cJ5gt+kjfoCXMAG SFs9X1tfZcTWb0zZiqHm8P1ZkpX5zSE+/4TQZsvJMhqZWfVmmFh5gXhoFN2oydik86YE 71CDErNOMSI+Vnyob+aT5CpNQAN5GZ9tvlmKJqYg7jC2iJ9oAwN2ItNqoIJ1EAvERun2 5cifbmdAaFvI+Mk5UJQ5m8plgFg4ykd4hqN9LGjmCqtzkd1xvwI5TrFguVP+QXx4DSFS 7tow==
X-Gm-Message-State: ABUngvekxxyFzgDuAsVNkNtw39aL4bbRn6uhMlJ1qLr5PpCKvIVCcufU3qvhvdsmPQPlm7R5+qXPliB5zo93VQ==
X-Received: by 10.129.125.215 with SMTP id y206mr4789353ywc.234.1477677876803; Fri, 28 Oct 2016 11:04:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Fri, 28 Oct 2016 11:03:56 -0700 (PDT)
In-Reply-To: <20161028160003.B5CA61A56C@ld9781.wdf.sap.corp>
References: <CAOgPGoChDnFf-4Vxm1S021MXHhGGpTjniD6+124B7off2RzO6w@mail.gmail.com> <20161028160003.B5CA61A56C@ld9781.wdf.sap.corp>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 29 Oct 2016 05:03:56 +1100
Message-ID: <CABcZeBPz_FvqeBjsQS+6g5t3qV1xTGy2QcSv=te5_NxwpJSAnw@mail.gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: multipart/alternative; boundary=001a11492dfaf0c409053ff0b04d
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sVt9Bst_gqBJZGf5iO5jLFjC-VU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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: Fri, 28 Oct 2016 18:04:40 -0000

On Sat, Oct 29, 2016 at 3:00 AM, Martin Rex <mrex@sap.com>; wrote:

> Joseph Salowey wrote:
> >
> > This is a working group last call announcement for
> draft-ietf-tls-tls13-18,
> > to run through November 20. If possible, we would like to receive
> comments
> > on the list by November 13 so they can be discussed at the meeting in
> > Seoul. We hope to address any substantive issues raised during that
> process
> > shortly thereafter.
> >
> > In order to allow for cryptographic review, we will delay submission of
> the
> > draft to the IESG until the end of January 2017; there will be an
> > opportunity to address any issues discovered by the cryptographic
> community
> > prior to submission to the IESG.
>
>
> There are two seriously backwards-incompatible changes in the
> current proposal that provide zero value, but completely break
> backwards-compatibility with existing middleware infrastructure.
>
>
> (1) hiding of the TLS record content types.
>     Please leave the TLS record types (handshake/AppData/Alert/CCS)
>     clearly visible on the outside of the TLS records, so that
>     middleware protocol parsers (which interface to transport-free
>     TLS protocol stacks) can continue to work, and continue to
>     work efficiently.


I'll let the chairs determine how to handle this.



> (2) hiding of the TLS extension SNI.
>     Right now it is perferctly fine to implement TLS extensions SNI
>     on the server completely outside the TLS protocol stack to route
>     to single-cert SNI-unaware backends.  The current proposal
>     suggest to move TLS extension SNI into the encrypted part, if
>     my superficial reading of the draft is correct, so TLSv1.3
>     will not fly with existing architectures where spreading of
>     TLS requests on the server-side based on TLS extension SNI
>     is done outside of the TLS protocol stack (i.e. bottleneck-less
>     without having to open TLS).


This isn't quite right. In RFC 6066, the client sends its server_name
extension in ClientHello and the server responds with an empty
server_name in its ServerHello to indicate that it accepted SNI.

   A server that receives a client hello containing the "server_name"
   extension MAY use the information contained in the extension to guide
   its selection of an appropriate certificate to return to the client,
   and/or other aspects of security policy.  In this event, the server
   SHALL include an extension of type "server_name" in the (extended)
   server hello.  The "extension_data" field of this extension SHALL be
   empty.

In TLS 1.3, the client's extension remains where it is, but the server's
extension is in EncryptedExtensions. This shouldn't interfere with
configurations such as the one you describe, as the server already
needed to insert the SNI field itself and hash it into Finished.

-Ekr


>