Re: [DNSOP] [internet-drafts@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]

Jan Včelák <jv@fcelda.cz> Thu, 19 July 2018 18:48 UTC

Return-Path: <jv@fcelda.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5654512426A for <dnsop@ietfa.amsl.com>; Thu, 19 Jul 2018 11:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.022
X-Spam-Level:
X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.cz
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 iv30ILT2xPrH for <dnsop@ietfa.amsl.com>; Thu, 19 Jul 2018 11:48:19 -0700 (PDT)
Received: from mail-ua0-x243.google.com (mail-ua0-x243.google.com [IPv6:2607:f8b0:400c:c08::243]) (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 3DA92130E33 for <dnsop@ietf.org>; Thu, 19 Jul 2018 11:48:18 -0700 (PDT)
Received: by mail-ua0-x243.google.com with SMTP id t14-v6so5863867uao.8 for <dnsop@ietf.org>; Thu, 19 Jul 2018 11:48:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Lr0B4IUeZKK5WKJpt9mCd11yEFzoqVXUjVVaRsPWCNI=; b=Au0gQT8SrADVcjxC9+t6DrzEQVDqdAifI9iptLjijCmrJPbDIAnjFFAHTGqiR/+iSE IC7kdBlEDpgZVlx57DPxVtZaZBOvR1iFZS+xz6xkXNEVfTbFgQ5KyzMeTGMzYt8wdzbS ExWG2gztesL9x/NwQNmRKeIbmwR2pw8vMOrRg=
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:content-transfer-encoding; bh=Lr0B4IUeZKK5WKJpt9mCd11yEFzoqVXUjVVaRsPWCNI=; b=PPqWFcPnJZ6JVR/tnVcHSo3J62MamjIT6rc/cURrNC73KNeNXIYJ7SvFE/f9aIbhYi wluAgopKlZx2rtjjgPxBgOKXC1lFo8clvBZrBQZJlF3f3pRGIN0QNygXScD3uPpaw0lR DwfbvptbcIhP4GYHVLoyaTlErLzfW+4i0CIA5I8eSFVidQ9u3ViE+0URYpuzB3ht2g0Z mMvx7ebYud4jSlVXSeYJA4GrgOMeaVvPifzhGT6iVyU/K0GAxz5U2+54rfEztfNqZfHY O6Pm1QyyiBzNzSoEmRs6V3LQfsp6BjBY2UOYmHntgRTKV1PzkTmOQfrNhSvLVNI7uWId EFWA==
X-Gm-Message-State: AOUpUlG7jghyXtpTPHmlyABGo//mFRJcYYZBbWO7SIdz/tcOO/71lKIH nTYtQTYmc/iDAFmi3xru7V8nZ3XHcp9Y9PT7AKlmMw==
X-Google-Smtp-Source: AAOMgpdRuj29qZcuTDivVw0EAXHUW0W8Cqb0+v1a+gobAoa+n+mghN68z0Bcsjps2tPnTqAgKHrgWdyqU3xx5nKkfl8=
X-Received: by 2002:a9f:318a:: with SMTP id v10-v6mr7507132uad.36.1532026097192; Thu, 19 Jul 2018 11:48:17 -0700 (PDT)
MIME-Version: 1.0
References: <20180707191900.7jjaxklib3tlixgb@nic.fr> <CAM1xaJ_jcMunvfuqqgoe-5hTSE1t=A4ELWF1j0SBsztoZ_1S=w@mail.gmail.com> <CAOdDvNpWs3_+c3=pdYjxm+UrEfBUawcTKXY4ks0VbuGSts+q7Q@mail.gmail.com> <CADyWQ+HwNsvgs0BnQ3NqnEob6xZrcbmk_qVOX58UCW4rFrmahg@mail.gmail.com> <CAOdDvNq65kGho6oCX=mMw+qebHOqzJq6qJ7kAWdO53wAKeyj2A@mail.gmail.com>
In-Reply-To: <CAOdDvNq65kGho6oCX=mMw+qebHOqzJq6qJ7kAWdO53wAKeyj2A@mail.gmail.com>
From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= <jv@fcelda.cz>
Date: Thu, 19 Jul 2018 14:48:06 -0400
Message-ID: <CAM1xaJ8nsqreqBz7f2fG_HOaB6dc5JOS_S9Oxj5pyiOaPiyvsA@mail.gmail.com>
To: pmcmanus@mozilla.com
Cc: tjw.ietf@gmail.com, dnsop@ietf.org, draft-rescorla-tls-esni@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pugbETpepd8vC51IA32kI48ECI8>
Subject: Re: [DNSOP] [internet-drafts@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2018 18:48:22 -0000

Patrick, I believe my understanding of the SNI consumer side is the
same. I'm talking about inability to use DNS wildcard on SNI producer
side:

Let's say I get domain example.com and wildcard certificate
*.example.com. I want to run a couple of services on the subdomains of
example.com and I want to use ESNI. If a TLS client want's to connect
for instance to www.example.com, it will resolve www.example.com
A/AAAA record to get server IP and _esni.www.example.com TXT to get
the key to encrypt SNI. Is that right or did I miss something about
your draft?

If the above true, then my objection is that I cannot use DNS wildcard
for _esni record and I will have to create explicit one for each
subdomain (service) on example.com. Another annoying thing is that
existence of _esni.www.example.com TXT record will prevent expansion
of *.example.com A/AAAA for www.example.com. The solution would be to
request new DNS RR type for ESNI which could be used with
*.example.com DNS name.

Jan
On Thu, Jul 19, 2018 at 2:27 PM Patrick McManus <pmcmanus@mozilla.com> wrote:
>
> the tls server side (aka the cert side) can definitely use a wildcard (or a list of explicit names, or a mix of both!) But that's the SNI consumer. The draft is about the SNI producer which does not use wildcards.
>
> e.g. the ESNI work is about what is put in the TLS client handshake (historically the SNI and according this draft a new extension carrying the encrypted SNI) - and that is always an explicit name. And that's also the subject of the DNS query in order to obtain the keys. The DNS query and SNI leak similar amounts of information (although perhaps to different parties), so an encrypted DoT or DoH is an important part of the system.
>
>
> On Thu, Jul 19, 2018 at 1:53 PM, Tim Wicinski <tjw.ietf@gmail.com> wrote:
>>
>> Patrick
>>
>> Can I go and order a SSL Cert with a standard name and a wildcard name for SNI?  We do that now.
>>
>> So, I think Jan is onto something.
>>
>>
>> On Thu, Jul 19, 2018 at 1:47 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
>>>
>>>
>>> On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák <jv@fcelda.cz> wrote:
>>>>
>>>> Hey,
>>>>
>>>> I just scanned the draft and focused mainly on the DNS bits. The
>>>> described method for publishing encryption keys for SNI in DNS won't
>>>> allow use of wildcard domain names.
>>>>
>>>
>>> Thanks!
>>>
>>> I believe the draft is OK on this point because wildcards aren't needed. While certificates can be valid for wildcard domains, the SNI is always a specific hostname (and the plaintext hostname informs the DNS question)
>>>
>>>
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>