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.i...@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 <pmcma...@mozilla.com> > wrote: > >> >> On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák <j...@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 >> >> >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
