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

Hi Jan,

On Thu, Jul 19, 2018 at 2:48 PM, Jan Včelák <jv@fcelda.cz> wrote:

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

the esni keys are completely independent of the associated certificates.
Indeed it is anticipated that the same set of esni keys would cover many
different parties and certificates that only share a TLS termination point
in common. (i.e. the esni keys don't encrypt or authenticate https, they
just encrypt the SNI field). so for clarity we should probably move on from
certificate properties.

nonetheless, it is indeed the point of ESNI that the same TXT (or perhaps
ESNI RR-type) content applies to multiple domains - that's what forms the
anonymity pool.

> 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?
>
>
sounds right

> 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.
>
>
got it (and as I hinted above, the RRTYPE is an open issue in the bug
tracker - I think there's significant support for making the change though
this is the first I've heard this argument, so I'll add it to the list.
thanks).

Am I correct in saying that what you're getting at is not so much a wire
issue as a convention among configuration and implementations? i.e.
wildcards are synthesized - they aren't actually sent as responses that
clients use in some kind of short-cut kind of way?

Thanks for the help.

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