Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

Eric Rescorla <ekr@rtfm.com> Thu, 18 October 2018 02:26 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 02C32130E53 for <tls@ietfa.amsl.com>; Wed, 17 Oct 2018 19:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 HReYKEIMNxJ7 for <tls@ietfa.amsl.com>; Wed, 17 Oct 2018 19:26:17 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 3E238130E57 for <tls@ietf.org>; Wed, 17 Oct 2018 19:26:17 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id j17-v6so26246613lja.1 for <tls@ietf.org>; Wed, 17 Oct 2018 19:26:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WVyTTffKNYWVThhuB0P0W6IBz5zazmQ/xXAXRyP5CsU=; b=jNfb95Uv+O6VphFktcZWiA43pK9Ri5jZ05aALvXBYYUlMxwGPoDaXT3gbwfDJ0ozEG aBL/RUE1cTi/oudEgQCybsiJ7jte4UOfN4o0mau0Knm4SX3MJQsaRVtWil7s6r3f7vl1 CebBWCTWDm1CFaoy/Whh4zKxs2ziyJbMzrLoGGW3jnD5I8nH7sWcx7RDclwmdkxyyQ5i X3xKv1p5RdRfbDpaM+Pw0CrrHehHCQgfn0b5X+1LbDmivRs2mxoM38k4nknce2hyZs7w GxBLIBtrhrs0Isj5FnWyYfnuQVVyOdgpL0qmM75LINQVW5akrEl3PqOO0dLW3xpjgggl McPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WVyTTffKNYWVThhuB0P0W6IBz5zazmQ/xXAXRyP5CsU=; b=BdpOOsqLJHghc8QA9QKSSP1HFMw/SAQZfHLmGMwOr3nRRAURdj0Bsf6Q31jLAMDBYM R5L/H4xpWOd5SraSf48smLhuRHzEud0GccrS5f60+moXf1lGx//PorbNaWbCUBEYCD1N 30wzCIDlikEkhlOIwW2L581erRDMng3xArRszrldyE7veuBPg/9J0rxHqgbokVTSm8w4 23FwppuDb/ltHGBI/oTTZtCxqTw2WNohBzufBttNyUDT2uClp+54raB7+SkzHXmKlj/x vuFPvMLGMn7GP/Jpz1Difdg+iKBKP3jRsXcxyuRX301DKxlONEmvl+dzqrkgsXC+RmHB yIFg==
X-Gm-Message-State: ABuFfohwK90yeF5hqFZXnK1zgaBnPgMwbPkr3euAvleAytJdGkd5VgTl e/Cd+XwzDjaJF6IfKXP6Ncsi+HKL56bHvJqy4cWHhHC0tqA=
X-Google-Smtp-Source: ACcGV63FtqJXLc231K2KtyW9jiuuF3XLVCyWdJk7xOO/nROUHC5ogTNBH4c+f7AtWvLA9AS+qqNX7K3CvMH6tl3Oi1Y=
X-Received: by 2002:a2e:7017:: with SMTP id l23-v6mr13771346ljc.160.1539829575237; Wed, 17 Oct 2018 19:26:15 -0700 (PDT)
MIME-Version: 1.0
References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> <20181017170236.DA9D1404C@ld9781.wdf.sap.corp> <CABcZeBPCz39L0LQBXUM-yhhN3FmccNwQRvYNT+-ChfxRcPdD+g@mail.gmail.com> <20181017234110.39D36404C@ld9781.wdf.sap.corp>
In-Reply-To: <20181017234110.39D36404C@ld9781.wdf.sap.corp>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 17 Oct 2018 19:25:38 -0700
Message-ID: <CABcZeBN1kkF3WPnfP69V99kbQJr3P+t2BD9izFviJ97XcWsw6Q@mail.gmail.com>
To: mrex@sap.com
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d8d391057877826e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bNO-PexiJWXxmb_2QxpXe0nYoUY>
Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 18 Oct 2018 02:26:20 -0000

On Wed, Oct 17, 2018 at 4:41 PM Martin Rex <mrex@sap.com> wrote:

> Eric Rescorla <ekr@rtfm.com> wrote:
> > Martin Rex <mrex@sap.com> wrote:
> >
> > > Sean Turner <sean@sn3rd.com> wrote:
> > > >
> > > > This is the working group last call for the
> > > > "Issues and Requirements for SNI Encryption in TLS"
> > > > draft available at
> > > > http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/.
> > > > Please review the document and send your comments to the list
> > > > by 2359 UTC on 31 October 2018.
> > >
> > >
> > > I think the idea of encrypted SNI is inherently flawed in its concept.
> > >
> >
> > It's pretty late to raise this point
>
> Nope, I've raised this *EVERY* time on the list when the dead horse was
> newly beaten.
>

And there have been multiple consensus calls to the contrary, so this
is just re-raising a decided issue.


>> As it is, there are a number of servers which desperately require
> >> the presence of TLS extension SNI, or will fail TLS handshakes either
> >> by choking and dropping connections (Microsoft IIS 8.5+) or by
> >> very unhelpful alerts (several others), and also HTTP/2.0 requires
> >> unconditional cleartext presence of TLS extension SNI.  Any kind of
> >> heuristics-based approach for clients to guess whether or not to
> >> send TLS extension SNI is flawed from the start.  If a network
> >> middlebox can make a client present a cleartext TLS extension SNI
> >> by refusing connections without cleartext TLS extension SNI,
> >> the entire effort becomes pretty useless.
> >
> > Yes, clients must not fall back to cleartext SNI in this case.
>
> Please give a clear deterministic algorithm how a client can
> tell apart a server that requires cleartext SNI from a server
> that does not want cleartext SNI.
>

This isn't really the relevant question, as there are many servers
now which do not require SNI.

The relevant question is how a client can be made aware that
a server does support ESNI and can have high confidence that
it will accept it. Such an algorithm is provided in:
https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-4

Note that as explained in detail, it is not necessary that all clients
send ESNI to that server.





>   It is necessary
> > > that the client knows reliably that a hostname must not be sent
> > > in the clear, including when the connection fails for unknown reasons,
> > > and only a new URI method will reliably provide such a clear
> distinction.
> > >
> >
> > I don't agree with this claim, given that we have a number of other
> proposed
> > mechanisms for the client to know when ESNI is allowed, including DNS.
>
> DNS is a non-starter for several reasons.
>

> Ever heard of firewalled networks, private DNS universes and HTTP CONNECT
> proxies?
>

Yes, I've heard of all of these. They're not relevant to the question at
hand.



> >> By sending TLS extension SNI in the clear to a server, the client
> >> tells that server:  I am going to perform an rfc2818 "HTTP over TLS"
> >> section 3.1 "Server Endpoint Identification" matching
> >
> > I don't know where you get this from, given that RFC 6066 doesn't
> > even cite 2818.
>
> Simply to avoid a downref.  I should not have to explain this to you.
>
> rfc2818, section 3.1:
>
>    3.1.  Server Identity
>
>    In general, HTTP/TLS requests are generated by dereferencing a URI.
>    As a consequence, the hostname for the server is known to the client.
>    If the hostname is available, the client MUST check it against the
>    server's identity as presented in the server's Certificate message,
>    in order to prevent man-in-the-middle attacks.
>
> rfc6066, section 3:
>
>    3.  Server Name Indication
>
>    TLS does not provide a mechanism for a client to tell a server the
>    name of the server it is contacting.  It may be desirable for clients
>    to provide this information to facilitate secure connections to
>    servers that host multiple 'virtual' servers at a single underlying
>    network address.
>
>
> It looks blatantly obvious to me that
>   rfc2818:  "check the hostname of the server agains the server's identity
>              as presented in the server's Certifcate messag"
> and
>   rfc6066:  "a mechanism for a client to tell a server the name of the
> server
>              it is contacting"
>

It may be obvious to you, but I don't believe it's correct. For instance,
the server might be using some form of certificates other than X.509.

> In protocol version SSLv3->TLSv1.2, encryption keys are only established

> >
> >> *AFTER* successful authentication of the server through its server
> >> certificate. So it was obviously impossible to encrypt the information
> >> whose only purpose it was to allow the server to decide *which* TLS
> Server
> >> certificate to use for authentication (hen-and-egg).
> >
> > This isn't really correct: the mechanism for encrypting SNI itself would
> > actually work fine in previous versions of TLS as well.
>
> Actually, no, it will not work at all in TLSv1.2
> (this would not be TLSv1.2 anymore, or an entirely different TLS extension)
>
> My server-side implementation of TLS extension SNI is entirely outside
> of the TLS protocol stack.


This is actually quite compatible with the encrypted SNI mechanism
specified in draft-ietf-tls-esni, because it was designed to work
with split architectures.

-Ekr