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

Eric Rescorla <> Fri, 28 October 2016 18:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 838FD12953B for <>; Fri, 28 Oct 2016 11:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LUw-VT3aY4ix for <>; Fri, 28 Oct 2016 11:30:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C28A128B37 for <>; Fri, 28 Oct 2016 11:30:49 -0700 (PDT)
Received: by with SMTP id h14so99192740ywa.2 for <>; Fri, 28 Oct 2016 11:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id f1mr15618292ywd.354.1477679448845; Fri, 28 Oct 2016 11:30:48 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 28 Oct 2016 11:30:08 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Sat, 29 Oct 2016 05:30:08 +1100
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary="001a114e4e5ca42357053ff10e83"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Oct 2016 18:30:51 -0000

On Sat, Oct 29, 2016 at 5:23 AM, Martin Rex <> 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:

> -Martin