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

mrex@sap.com (Martin Rex) Fri, 28 October 2016 18:23 UTC

Return-Path: <mrex@sap.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 75DA4129593 for <tls@ietfa.amsl.com>; Fri, 28 Oct 2016 11:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 w9LAZ5jED7GP for <tls@ietfa.amsl.com>; Fri, 28 Oct 2016 11:23:45 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFD61294A8 for <tls@ietf.org>; Fri, 28 Oct 2016 11:23:45 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3t5BwH2HyVz26CG; Fri, 28 Oct 2016 20:23:43 +0200 (CEST)
X-purgate-ID: 152705::1477679023-0000521C-35536832/0/0
X-purgate-size: 2574
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t5BwG48nKzkp5T; Fri, 28 Oct 2016 20:23:42 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 842351A56E; Fri, 28 Oct 2016 20:23:42 +0200 (CEST)
In-Reply-To: <CABcZeBPz_FvqeBjsQS+6g5t3qV1xTGy2QcSv=te5_NxwpJSAnw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 28 Oct 2016 20:23:42 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20161028182342.842351A56E@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KdIvpFg6DSW1YLBr-Vzmf92T3K4>
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
Reply-To: mrex@sap.com
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:23:46 -0000

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).


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).


-Martin