Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
On Thu, 19 Jul 2018, Jan Včelák wrote: It's harder to deploy a new rrtype than an overloaded TXT record, but you can't have everything. Just a note that IANA action will be soon (eventually) required to use underscore label: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ You already need an IANA action to get a new rrtype. Neither is terribly hard, but an underscore label will be easier. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
On Thu, Jul 19, 2018 at 4:56 PM John Levine wrote: > It's harder to deploy a new rrtype than an overloaded TXT record, but > you can't have everything. Just a note that IANA action will be soon (eventually) required to use underscore label: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
On Thu, Jul 19, 2018 at 3:04 PM Kazuho Oku wrote: > Background: In ESNI, we would like to support two types of > deployments: 1) DNS and TLS servers operated by same entity, 2) DNS > and TLS server operated by separate entities. Let me sketch how this could work with custom DNS record type. Let's call the new type ESNI. This is how the DNS records for CDN and our example.com domain may look like: cdn-provider.test. SOA ... cust.cdn-provider.test. A 192.0.2.100 cust.cdn-provider.test. 2001:db8::cafe:100 cust.cdn-provider.test. ESNI "..." example.com. SOA *.example.com. CNAME cust.cdn-provider.test. jabber.example.com. CNAME somewhere-else.test. no-esni.example.com. 2001:db8::beef:100 mail.example.com. A 198.51.100.1 mail.example.com. 2001:db8::beef:200 mail.example.com. ESNI "..." I think this configuration should support all the deployments you mentioned: - mail.example.com is configured explicitly. - jabber.example.com. configuration is outsourced to some other provider. We don't know if they provide A, , or ESNI. - no-esni.example.com is configured explicitly with no ESNI. - any other subdomain under example.com is outsourced to cust.cdn-provider.test which providers A, , and ESNI > My understanding is that ANAME is coming, but that is for address > records only. It cannot be used to delegate a specific type that you > choose. We all wish we had solution for this problem. At the moment, you can use just CNAME which takes all. If you wanna configure subset of A, , ESNI, you have to do that explicitly. Also, you cannot use CNAME at zone apex (for example.com.). Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
In article you write: >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. Yes, that is a very well known fact about _prefix names in the DNS. If you want wildcards to work, use a new rrtype, e.g., instead of this: > _esni.example.com. 60S IN TXT "..." "..." do this: example.com. 60S IN ESNI 983989D92330EA840... It can use base64 encoded text but it might as well just put the ESNIKeys structure literally in the record, represented in the master file in hex string, like the certificate stored in a TLSA record. It's harder to deploy a new rrtype than an overloaded TXT record, but you can't have everything. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
What Ray Says Also, I have SSL certs right now (sadly but that's another talk) for aws-region-y.saas.com, *.saas.com *.foo.saas.com, *.saasdb.com etc. and let's say we want a ssl cert of aws-region-y.saas.com with all the wildcards as SNI names. On Thu, Jul 19, 2018 at 3:39 PM, Ray Bellis wrote: > On 19/07/2018 15:36, Patrick McManus wrote: > > > [replying to myself] I see now that the wildcards are part of things > > like axfr which form an open definition for interoperability.. so they > > are a wire protocol element of a sort. Thanks! > > Kind of. > > Wildcards are carried in AXFR so that primary and secondary name servers > both know to synthesise the required records. > > It is technically possible to explicitly ask for `*.example.com` to test > for the presence of a wildcard, but otherwise the synthesis is done > entirely on the server side and the `*` does *not* usually appear in the > DNS wire protocol. > > Ray > > ___ > 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
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
On 19/07/2018 15:36, Patrick McManus wrote: > [replying to myself] I see now that the wildcards are part of things > like axfr which form an open definition for interoperability.. so they > are a wire protocol element of a sort. Thanks! Kind of. Wildcards are carried in AXFR so that primary and secondary name servers both know to synthesise the required records. It is technically possible to explicitly ask for `*.example.com` to test for the presence of a wildcard, but otherwise the synthesis is done entirely on the server side and the `*` does *not* usually appear in the DNS wire protocol. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
On 19/07/2018 15:07, Patrick McManus wrote: > 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? That's correct - wildcards are expanded on the DNS server, not by the client. FWIW the same issue appears to arise with the current specification for carrying the ALTSVC information as a DNS RR, again because of its use of underscore prefix labels. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
On Thu, Jul 19, 2018 at 3:07 PM, Patrick McManus wrote: > > 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? > > [replying to myself] I see now that the wildcards are part of things like axfr which form an open definition for interoperability.. so they are a wire protocol element of a sort. Thanks! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@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 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/ 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/ 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 > 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 > 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 > wrote: > >>> > >>> > >>> On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák 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
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
2018-07-19 14:48 GMT-04:00 Jan Včelák : > 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/ 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/ 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. I agree that the issue exists. Thank you for pointing that out. I can see that using a dedicated type resolves the issue for the case where the DNS and TLS servers are operated by the same entity. However, that would not solve the issue if the servers are operated by different entities. Do you have any suggestions on how we can support that case as well? Background: In ESNI, we would like to support two types of deployments: 1) DNS and TLS servers operated by same entity, 2) DNS and TLS server operated by separate entities. The latter case is actually common; it is often the case for a website to select different service providers for DNS and CDN. In such case, we would like to use CNAME to delegate the ESNIKeys entry from the DNS of the website to that of the CDN (example show below). Otherwise, there is a risk of the key (which needs to be rotated) getting out of sync. _esni.example.com. IN CNAME 3600 _esni.cdn.example. However, this pattern does not work for wildcards, because CNAME is not type-specific. We would want to do something like below, but that is not possible. *.example.com IN A 192.0.2.1# IP address provided by CDN *.example.com IN CNAME _esni.cdn.example. # delegate ESNI records only My understanding is that ANAME is coming, but that is for address records only. It cannot be used to delegate a specific type that you choose. > Jan > On Thu, Jul 19, 2018 at 2:27 PM Patrick McManus 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 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 >>> wrote: On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák 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 >>> >> -- Kazuho Oku ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
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/ 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/ 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 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 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 >> wrote: >>> >>> >>> On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák 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
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
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 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 > wrote: > >> >> On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák 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
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
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 wrote: > > On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák 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
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák 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
Re: [DNSOP] [BEHAVE] Fwd: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
[ + DNSOP ]
On Mon, Jul 16, 2018 at 4:15 PM Christian Huitema wrote:
>
> I have never been a great fan of the DNS64 hacks. The DNS64
> specification, and RFC7050, are making a set of assumptions about the
> DNS infrastructure, the way stub resolvers are configured, and the
> possibility for intermediate resolvers to spoof records on the fly.
>
> One of these assumptions was already on shaky ground when the spec was
> written. It is only OK to spoof DNS records if the clients do not insist
> on DNSSEC. I don't have good numbers on clients, by I see measurements
> showing that over 90% of clients are served by recursive DNS resolvers
> that request DNSSEC validation (setting the DNSSEC OK option flage to
> 1), and over 50% of clients are served by recursive DNS resolvers that
> perform DNSSEC validation.
>
> Another assumption is that clients use DNS resolvers that are under the
> control of the network provider. Again, current measurement show that
> more than 25% of clients are server by third party DNS resolvers. That
> number is actually growing steadily. New DNS transports like DNS over
> TLS or DNS over HTTPS ensure that the exchanges between clients and
> third party resolvers will be pretty much immune to hacking by on-path
> middleboxes.
>
> Yet another assumption is that clients expect DNS responses to vary
> depending on the interface over which the DNS queries are sent. Again,
> this is incompatible with the current trend of using third party
> resolvers. That assumption might have worked when applications were only
> using DNS resolvers provided by the operating system. But then, we see a
> solid trend of moving transport services out of the kernel and into
> application libraries. QUIC is an example of that.
>
> These numbers and these trends tell me that technologies like DNS64 will
> be very hard to deploy, and also very unreliable when deployed. These
> technologies make a number of unwarranted assumptions about the nature
> of the DNS service. I don't think that attempting yet another patch like
> ipv4only.arpa will help all that much. In fact, I would much prefer to
> let 7050 die a deserved death, and maybe hasten that death by
> deprecating its status.
RFC7050 is already widely deployed -- I must admit that I personally
also view it as a hack, but I'd much rather that, as it will continue
to be used, it is at least well described, and has less pointy edges
on it
W
>
> -- Christian Huitema
>
>
>
> On 7/15/2018 7:20 PM, Warren Kumari wrote:
> > Dear BEHAVE,
> >
> > I sent this to DNSOP a while back, but didn't think to send it to
> > behave as well - sorry.
> >
> > Please see below, and if you have comments, please comment in the
> > DNSOP list (so that we don't have overlapping discussions)...
> >
> >
> > Thank you!
> > W
> >
> >
> > -- Forwarded message -
> > From: Warren Kumari
> > Date: Wed, Jul 4, 2018 at 4:26 PM
> > Subject: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
> > To: dnsop
> >
> >
> > Dear DNSOP,
> >
> > Stuart Cheshire & David Schinazi have asked me to AD sponsor the
> > draft-cheshire-sudn-ipv4only-dot-arpa document
> > [0]
> > ..
> >
> > >From the document:
> > "The specification for how a client discovers its network's NAT64
> > prefix [RFC7050] defines the special name 'ipv4only.arpa' for this
> > purpose, but declares it to be a non-special name in that
> > specification Domain Name Reservation Considerations section.
> > Consequently, despite the well articulated special purpose of the
> > name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names
> > registry as a name with special properties.
> > This document formally declares the actual special properties of the
> > name, and adds similar declarations for the corresponding reverse
> > mapping names."
> >
> > RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address
> > Synthesis") is worth reading before reading this. If you are mainly a
> > DNS person,
> > this may be...surprising.
> >
> >
> > When reading draft-cheshire-sudn-ipv4only-dot-arpa there are a few things
> > worth
> > keeping in mind:
> >
> > 1: This is a fairly specialized function - it is used by NAT64 clients
> > to discover the prefix used for synthesis ("normal" people /
> > applications never need to resolve this). The main people who will
> > deal with this are mobile / stack vendors, and NAT64 providers.
> > 2: RFC7050 has a large amount of text around DNSSEC, what to do with
> > DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64
> > device*, not the ipv4only.arpa name.
> > 3: Devices use this mechanism to discover the IPv6 prefix used for
> > IPv6 address synthesis - different interfaces (e.g cellular and wifi)
> > will have different prefixes. This means that clients
> > must
> > do this query using the resolver learned on / appropriate for that
> > interface. This is the main bit which is weird for a DNS person - the
> > response from the resolver for your cellular
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
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. Relevant text in the draft: The name of each TXT record MUST match the name composed of _esni and the query domain name. That is, if a client queries example.com, the ESNI TXT Resource Record might be: _esni.example.com. 60S IN TXT "..." "..." The reason is that _esni.*.example.com. doesn't work as a wildcard. If you want wildcards to work, new dedicated DNS record type will be needed. I think it should be fairly easy to get a new type allocated as this doesn't require special DNS processing. Cheers, Jan On Sat, Jul 7, 2018 at 3:19 PM Stephane Bortzmeyer wrote: > > I think that ESNI is a nice and simple idea to solve the privacy > problems of the current TLS SNI. I forward the draft here because it > uses DNS to publish keys, under a underscore prefix. > > > > -- Forwarded message -- > From: internet-dra...@ietf.org > To: > Cc: > Bcc: > Date: Mon, 02 Jul 2018 16:30:21 -0700 > Subject: I-D Action: draft-rescorla-tls-esni-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Encrypted Server Name Indication for TLS 1.3 > Authors : Eric Rescorla > Kazuho Oku > Nick Sullivan > Christopher A. Wood > Filename: draft-rescorla-tls-esni-00.txt > Pages : 19 > Date: 2018-07-02 > > Abstract: >This document defines a simple mechanism for encrypting the Server >Name Indication for TLS 1.3. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 > https://datatracker.ietf.org/doc/html/draft-rescorla-tls-esni-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > ___ > 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
Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02
All, On 2018-07-18 14:36, Wessels, Duane wrote: It seems to work, although since I have no other implementation to compare against I can't be sure that the digest values are in any way correct. My own implementation, alluded to in the draft, is here: https://github.com/verisign/draft-dns-zone-digest/tree/master/impl I have a few test cases in the Tests directory. Duane sent me a mail off-list and after minor tweaks on both sides it seems like the two implementations now interoperate. * It might be worth mentioning that names are expected to be uncompressed. It's kind of obvious, but it might trick up some implementations. The draft says "It also adopts DNSSEC's canonical RR form (Section 6.2 of [RFC4034])" in one place and "calculated by concatenating the canonical on-the-wire form of all RRs" later. I wouldn't object to being more explicit. Do you want to propose some text or shall I take a stab? I think just adding like this is enough: "calculated by concatenating the canonical on-the-wire form, without name compression, of all RRs" * The TTL of the ZONEMD record has to come from somewhere. It can either come from configuration or pulled from somewhere else (I used the TTL of the SOA record). This should be documented. I also used the SOA TTL in my implementation. I can make that a recommendation in the draft. Someone pointed out to me that since ZONEMD is meta-data we don't really expect it to be queried normally, and a TTL of 0 is a reasonable default. My own feeling is that I would like ZONEMD to be a "normal" record outside of zone generation, so assume that it can and will be queried just like any other record. (This is also an open question in the current draft, IIRC.) In the current draft we already have to look at the SOA to get the serial, so using the TTL is straightforward. If we remove serial from the ZONEMD then TTL from the SOA might be less obvious, but I think it will still be the best default. Cheers, -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec
+1. Support adoption. > On Jul 19, 2018, at 8:42 AM, Sara Dickinson wrote: > > I also support adoption of this draft - it is attempting to address a genuine > impediment to deploying DNSSEC and I think this group is the right place to > work on it. > > As mentioned at the mic in Montreal, I’d like to see it additionally reflect > how the proposals here feed into the process for moving vendors after > deployment. > > Sara. > >> On 18 Jul 2018, at 11:13, Yoshiro YONEYA wrote: >> >> I support this draft to be WG I-D. >> >> -- >> Yoshiro YONEYA >> >> On Fri, 6 Jul 2018 20:26:59 -0400 Tim Wicinski wrote: >> >>> We've had some interest in moving this document forward, and the chairs >>> wanted to kick off this Call for Adoption before Montreal so if there >>> are concerns there will be some meeting time to address. >>> >>> This document is label as: Informational. The document is attempting >>> to document operational deployment models on deploying DNSSEC signed >>> zones across multiple platforms. >>> >>> This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec >>> >>> The draft is available here: >>> https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/ >>> >>> Please review this draft to see if you think it is suitable for >>> adoption by DNSOP, and comments to the list, clearly stating your view. >>> The authors will be at the next meeting to address questions or concerns. >>> >>> Please also indicate if you are willing to contribute text, review, etc. >>> >>> This call for adoption ends: 20 July 2018 >>> >>> Thanks, >>> Tim >> >> ___ >> 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 smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec
I also support adoption of this draft - it is attempting to address a genuine impediment to deploying DNSSEC and I think this group is the right place to work on it. As mentioned at the mic in Montreal, I’d like to see it additionally reflect how the proposals here feed into the process for moving vendors after deployment. Sara. > On 18 Jul 2018, at 11:13, Yoshiro YONEYA wrote: > > I support this draft to be WG I-D. > > -- > Yoshiro YONEYA > > On Fri, 6 Jul 2018 20:26:59 -0400 Tim Wicinski wrote: > >> We've had some interest in moving this document forward, and the chairs >> wanted to kick off this Call for Adoption before Montreal so if there >> are concerns there will be some meeting time to address. >> >> This document is label as: Informational. The document is attempting >> to document operational deployment models on deploying DNSSEC signed >> zones across multiple platforms. >> >> This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/ >> >> Please review this draft to see if you think it is suitable for >> adoption by DNSOP, and comments to the list, clearly stating your view. >> The authors will be at the next meeting to address questions or concerns. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 20 July 2018 >> >> Thanks, >> Tim > > ___ > 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
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dns-capture-format
I have gone over the diffs of the document, and stand by my earlier assessment that this document is ready for standardization. Please move it to IETF Last Call. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
