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

Eric Rescorla <ekr@rtfm.com> Fri, 28 October 2016 18:30 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 838FD12953B for <tls@ietfa.amsl.com>; Fri, 28 Oct 2016 11:30:51 -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 LUw-VT3aY4ix for <tls@ietfa.amsl.com>; Fri, 28 Oct 2016 11:30:49 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 9C28A128B37 for <tls@ietf.org>; Fri, 28 Oct 2016 11:30:49 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id h14so99192740ywa.2 for <tls@ietf.org>; Fri, 28 Oct 2016 11:30:49 -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=DD+V1Sggag1UklTsykPSq3wnGpCcQDvUL2a0MZjVIl8=; b=QlqqVTQw/OL6NvISxr+F9n4OXufyJS1clautPO85AsLzhe4trfMAQutzYuNa7b7fNW 93f8LYlIg11AYNKmv7ZHaURT016giRXXfa5JzjSF2o7uCVoUO3ZsjyRoii6zf3CO26C1 fXJExKAyHMPGF/zn94XtC6xsA1xw0wvUTzbXNhV0h+pOwkju2TJqDnfoAvhTGWsH4qBP kFcHa+eeihvKjWaIV0l/Piki787pLxAlSJ49atoL+XKx92tSnAcdLMwyITwDPDt3+FMQ Mynma81IvkRLcVkXIxxkCTukolABBbGR83A3tV5tXHxOwOvyPCHw81oq4mQaUx/kulzg UmPQ==
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=DD+V1Sggag1UklTsykPSq3wnGpCcQDvUL2a0MZjVIl8=; b=W80WUmSXVaeDl8BiDwsFNzkl4wwPNZFqsTDk4DhPZc+gpXY8GEdRGxgUbLcNlm90w4 nIciwhFTYTYP+uUVgZc6BqkPz+Xh/4k2VlkPQc0tTu7+5HiHCfcD4INBexJRHagA+/JC uQBn0fAt/1WlQjo5Af43MiCra44Jf7aDNJZ0Z87LOnOwqFxqejFpscCnqB7wbmkz6hNw bt21kYG94UN2KfF0L1C/Kj/nYEUy5spTgYgF66HkYJOJpJf+WjD8uIA/MCoAEkavIytt 5BQVTvT/WlZuqDoeqds28FHOS1Op+wXf6KB9z3gaqj8QnIve8c+cyk+nFYa6vw7ryAb3 83+Q==
X-Gm-Message-State: ABUngveOAcJjl4XZwJutczv2tzLDnxtuWS2ZOBKyxJBpIk3z9ulsVKDMSpIGLvYUZQkIi5dakK71Oqfvgntk5A==
X-Received: by 10.13.195.1 with SMTP id f1mr15618292ywd.354.1477679448845; Fri, 28 Oct 2016 11:30:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Fri, 28 Oct 2016 11:30:08 -0700 (PDT)
In-Reply-To: <20161028182342.842351A56E@ld9781.wdf.sap.corp>
References: <CABcZeBPz_FvqeBjsQS+6g5t3qV1xTGy2QcSv=te5_NxwpJSAnw@mail.gmail.com> <20161028182342.842351A56E@ld9781.wdf.sap.corp>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 29 Oct 2016 05:30:08 +1100
Message-ID: <CABcZeBO+mUZ5kqM9KWhwHF36Fp_k-YyiLDD7YOajgPpr5QWpBQ@mail.gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: multipart/alternative; boundary=001a114e4e5ca42357053ff10e83
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DfNlqyPe_2BnRAE9i4_60IoM8p4>
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:30:51 -0000

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

> If the server_name remains in plaintext and full sight in ClientHello
> (where it needs to be for TLSv1.2 backwards compatibility anyway),
> then I don't have an issue.  (I'm sorry for not reading the draft in full)


Good to hear.


> Eric Rescorla wrote:
> >
> >> (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.
>
> Yes, I know that rfc6066 suggests the server responds with an empty SNI
> extension.  This kind of server response is is a complete waste,
> and server-side SNI works just fine with the server not returning
> an empty SNI extension.
>
>
> >
> >    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.
>
> Nope, the server doesn't need to insert anything at all.  The empty
> TLS extensions SNI in ServerHello is completely superflouous.
>
> If this is really about "hinding the empty TLS extension SNI response",
> while leaving the actualy server_name in full sight in the cleartext
> ClientHello, why not just dropping the ServerHello TLS extension SNI
> response and be done with it?  It really has no functional value other
> than information discovery for scanners (the bad guys).
>

I would be fine with that if others are. Here's how we got here:

- RFC 6066 requires it (it's a SHALL level requirement).
- We didn't see a need to update the semantics of 6066
- Everything that doesn't have to be in ServerHello goes into EE.

If point #2 is wrong, then that's easy to change, though it would be a
change to
implementations. NSS, for instance, sends it:
http://searchfox.org/nss/source/lib/ssl/ssl3ext.c#436
-Ekr


>
> -Martin
>