Subject: [DNSOP] Proposal for a new record type: SNI

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Feb 2017 13:02:57 -0500

Hi dnsop,

I've written a draft proposal to improve the privacy of TLS connections, by
letting servers use the DNS to tell clients what SNI to send.

https://tools.ietf.org/html/draft-schwartz-dns-sni-01

I've incorporated some helpful feedback [1] from the TLS WG, but now I
could use your help analyzing the DNS side. All comments welcome; this
draft will change based on your feedback.

One particular issue that I could use advice on: should this be a new
record type, or should it reuse/repurpose an existing type like SRV or PTR?

Thanks,
Ben

[1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 14 Feb 2017 14:16:15 -0500

> [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html

Hi, Ben:

I'm kind of curious: your examples are pretty HTTP-centric, and HTTP
already has some pretty strong features for origins to persistently
modify how clients perform TLS, i.e., HTTP Strict Transport Security and
HTTP Public Key Pinning, along with preloading of those settings by the
browser vendors. Why not follow that same model for the functionality in
your draft?

-- 
Robert Edmonds

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Feb 2017 14:24:52 -0500 (EST)

On Tue, 14 Feb 2017, Ben Schwartz wrote:

> I've written a draft proposal to improve the privacy of TLS connections, by letting servers use the DNS to tell clients what SNI
> to send.
> 
> I've incorporated some helpful feedback [1] from the TLS WG, but now I could use your help analyzing the DNS side. All comments
> welcome; this draft will change based on your feedback.

This seems like a bandaid to TLS that I think just needs
fixing in the TLS protocol.

If I was a passive attacker logging lots of traffic, I would just
query the SNI's of all major sites (and/or any other A/AAAA records
I encounter while monitoring the traffic streams) so the protection
this offers is lost very quickly.

I don't think the additional TLS to DNS "ephemeral SNI" synchronisation
is worth the trouble. It would make more sense to have the TLS
client take the hit of some additional roundtrip to the server to
convey this privately after the EDH.

Also, it would make more sense to actually use the TLS server PUBKEY
for this, if the server uses the same pubkey for a lot of certificates
or SubjectAltNames. It is just as meaningless to the observer as an
ephemeral SNI, but now the TLS server can select the proper key if
it is configured with multiple different keypairs.

Paul

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 14 Feb 2017 19:33:38 +0000

> On Feb 14, 2017, at 10:02 AM, Ben Schwartz <[email-masked]> wrote:
> 
> Hi dnsop,
> 
> I've written a draft proposal to improve the privacy of TLS connections, by letting servers use the DNS to tell clients what SNI to send.
> 

Hi Ben,

>    _443._tcp.subdomain1.example.com.  IN SNI subdomain2.example.com

As I read this part I was assuming that the RDATA of the SNI record is an RFC 1035 <domain-name> and the lack of a trailing dot made me twitch a little bit.

It seems to me that you need to decide what the format of the RDATA will be.  Throughout most of the doc it looks like a <domain-name>, but in other places it sounds like an opaque string (particularly the paragraph about extensibility).

>    When initiating a TLS connection to a domain and port, a client
>    application SHOULD query the SNI record for the prefixed domain at
>    the same time as the A or AAAA query, and wait for a response before
>    initiating TLS. 

In the Introduction you said "Clients can make use of this record without adding delay to their connection process" but here the instruction is to wait.  How long should a client wait for a response to its SNI query?

Oh, I see later you wrote: A client application SHOULD NOT delay initiating a TCP connection while waiting for the SNI DNS response.

>    The application MUST discard or ignore any SNI
>    record whose RDATA is not a well-formed domain name or an empty
>    string. 

This might need more clarification.  Here's a place where the RDATA sounds very much like <domain-name>.  But then the empty label "." becomes particularly tricky here because, arguably, a <domain-name> can never be an empty string.

>    If
>    the selected SNI record is present with an empty RDATA (RLENGTH = 0),
>    then the client SHOULD omit the Server Name Indication.

Again, advice here will depend on what you choose for the RDATA format.  If its <domain-name> then you can't really have RDLEN=0.

>    Client applications MUST NOT allow the contents of the SNI record to
>    influence their certificate validation behavior.  The client's
>    certificate validation MUST be based on the user's specified
>    destination, not the RDATA of the SNI DNS record.  

Given this, it sounds like there is no real reason that the SNI value needs to be a domain name.  It could be something else, like an opaque string or an RFC4122 UUID?

I think this doc also needs a privacy considerations that talks about ways it could be abused by server operators.  For example, I think it could be used as a component of a so-called super cookie.  Each client could get a unique SNI from the DNS server, allowing the web site to track individuals.  While you may be improving privacy with respect to passive attackers, it can reduce privacy between web clients and servers.

DW

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Feb 2017 15:03:09 -0500

> browser vendors. Why not follow that same model for the functionality in

Hi Robert,

While this technique would apply to any use of TLS, you're right that I'm
mainly motivated by improvements for HTTPS.

It's true, we could accomplish something like this by preloading a data
file into browsers.  In some sense, this is also true for any aspect of
DNS!  Obviously, preloading fares very badly when the data in question is
valid for short times, or applies to many thousands or millions of domains,
and I think both problems apply here.

For example, a CDN that operates DNS on behalf of its customers could apply
SNI records to all of their domains.  Preloading all of those domains into
every browser seems impractical, and the list will quickly become outdated.

Without preloading, we cannot solve the problem of revealing the
destination in the initial connection.

I would also note that HSTS and HPKP could not have been implemented using
insecure DNS, given their adversary model.  The SNI record is very
different, and does not require DNSSEC.

--Ben

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 14 Feb 2017 15:39:24 -0500

Hi, Ben:

In your draft, the reason for not using TXT is given as:

2.1.3.  Using TXT

   We could encode this information in a TXT record, but that would
   violate the intended purpose of TXT records: to convey information to
   human readers.

I'm not sure if it's true that TXT records are intended only for human
consumption. TXT RRs contain "descriptive text" where "[t]he semantics
of the text depends on the domain where it is found".

If you define "where the domain is found" as, e.g., domains like
_443._tcp._sni.www.example.com, then you get to define the semantics of
what is described by the TXT record at that location. I think DKIM is an
example of a protocol that uses this kind of scheme with TXT records.

-- 
Robert Edmonds

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2017 22:14:32 -0000

>fixing in the TLS protocol.

For once I agree with Paul.

If you're going to change the client anyway, why is this better than a
modified handshake that sets up the encrypted channel before sending
the SNI?  I realize this is not a great time to open up TLS, with the
dust from TLS 1.3 just settling, but there's never a good time for
some stuff.

You should assume that bad guys have access to passive DNS databases,
so it's not hard to reverse the indirection that SNI records provide.
If you used TXT records the reversal would be slightly harder, since
you'd have to pick them out from all the other cruft that's encoded
in _prefix TXT records.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2017 22:19:25 -0000

>of the text depends on the domain where it is found".

That horse left the barn at least a decade ago, before SPF, DKIM,
DMARC, and a lot of other TXT records primarily intended to be
consumed by computers.  Humans can read them, but this human can't do
much with records like this:

taugh.com. IN TXT "google-site-verification=7SCAvuZtE7dOCpG0drHDEBOqco9JnPzFUIUBSgU3eWc"

Whether to use a TXT record is of course a subsidiary question to
whether DNS SNI indirection is a good idea in the first place.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Feb 2017 19:31:33 -0500

> dust from TLS 1.3 just settling, but there's never a good time for

I'm /soooo/ not a TLS person, but I think that this was discussed in
the TLS WG and didn't make it into the final spec -- it requires (at
least) an additional RTT. You do get SNI encryption with Zero-RTT, but
it's too later by then...
Some slideware: https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.pdf
The DNS SNI lookup could at least be done in parallel with the
"normal" DNS one (and, possibly returned in a
draft-wkumari-dnsop-multiple-responses answer :-))

> so it's not hard to reverse the indirection that SNI records provide.

Yup. I believe that much of the privacy benefit is gained if you
happen to host your site on the same domain / IP as many other sites.
Unfortunately this is true not just for domain fronting / this
technique, but for many other situations -- it doesn't matter how well
the SNI is hidden, if you connect to an IP address which only hosts a
small number of sites (or sites all on the same topic) you've lost.

An example of this is aa.org - the only other site on that IP is
www.alcoholicsanonymous.org - if you had an expectation of privacy, it
probably doesn't matter which one of the two names you went to...

> you'd have to pick them out from all the other cruft that's encoded

Hmmmm... are you suggesting we make TXT records cruftier to increase
privacy? :-)

W

>
> R's,
> John
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 00:51:00 +0000

presuming that the client will have to look up the hostname of the 
destination at some stage, and presuming that a passive network attacker 
may see DNS requests as well as TCP connections, how does this help?

Or does this require the use of DNS over TLS.

And also there will be leakage of certificate IDs in OCSP lookups which 
cannot be secured due to the paradox that would create.  An attacker 
could mine sites for cert IDs and do a reverse mapping from that.

Adrien

------ Original Message ------
From: "Ben Schwartz" <[email-masked]>
To: "Robert Edmonds" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 15/02/2017 9:03:09 AM
Subject: Re: [DNSOP] Proposal for a new record type: SNI

>><https://tools.ietf.org/html/draft-schwartz-dns-sni-01>
>> >
>><https://www.ietf.org/mail-archive/web/tls/current/msg22353.html>
>>
>>Hi, Ben:
>>
>While this technique would apply to any use of TLS, you're right that 
>I'm mainly motivated by improvements for HTTPS.
>
>DNS!  Obviously, preloading fares very badly when the data in question 
>is valid for short times, or applies to many thousands or millions of 
>domains, and I think both problems apply here.
>
>For example, a CDN that operates DNS on behalf of its customers could 
>apply SNI records to all of their domains.  Preloading all of those 
>domains into every browser seems impractical, and the list will quickly 
>become outdated.
>
>I would also note that HSTS and HPKP could not have been implemented 
>using insecure DNS, given their adversary model.  The SNI record is 
>very different, and does not require DNSSEC.
>
>--Ben

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Feb 2017 21:09:05 -0500

> Or does this require the use of DNS over TLS.

The draft says:

   A passive adversary who monitors the client's DNS queries could learn
   which domain the client is accessing, defeating the confidentiality
   benefits of this record type.  Therefore, clients wishing to conceal
   browsing history from a passive adversary SHOULD also use DNS over
   TLS [RFC7858 <https://tools.ietf.org/html/rfc7858>].  However,
clients MAY use SNI records with standard
   DNS, in order to provide protection against a weak passive adversary
   who can monitor only the link between the client and the TLS server,
   not the link between the client and the DNS server.

> cannot be secured due to the paradox that would create.  An attacker could
> mine sites for cert IDs and do a reverse mapping from that.
>

Interesting observation!  I'll add a note.  However, I don't think this is
a big problem.  The goal is not to hide which certificate is being used.
The goal is to hide which domain is being accessed within a multi-domain
(SAN/UCC or wildcard) certificate.

> apply SNI records to all of their domains.  Preloading all of those domains
> into every browser seems impractical, and the list will quickly become
> outdated.
>

---

From: "John Levine" <[email-masked]>
Date: 15 Feb 2017 23:10:06 -0000

>draft-wkumari-dnsop-multiple-responses answer :-))

To put it baldly, if it is a problem that SNI leaks, the solution is
to fix SNI.  This is not a solution, it is at most a band-aid that
will deter a subset of unsophisticated snoops while adding useless
complexity to https.  For example, what are users supposed to do when
the SNI DNS records and the SNI mapping in the servers inevitably get
out of sync?

"But fixing SNI is hard" isn't a good reason to do this.  I understand
that adding an extra round trip to the handshake would be a problem,
but I am a long way from believing that's the only way to fix SNI.

R's,
John

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 15 Feb 2017 18:48:41 -0500

> the SNI DNS records and the SNI mapping in the servers inevitably get

FWIW, the draft recommends users retry with whatever their behavior would
have been otherwise, effectively imposing a one roundtrip penalty in this
failure case.

> but I am a long way from believing that's the only way to fix SNI.

Removing SNI without adding an extra roundtrip to every SSL connection
logically requires the client to learn an additional piece of information
about the server before it contacts the server.  In a typical situation
(e.g. hyperlink following), the client's only initial piece of information
about the server is its domain name.

Mapping a domain name to information about the thing that lives at that
domain name is the defining characteristic of the DNS.  It seems to me,
therefore, that any solution to the SNI problem must either use DNS or
reinvent DNS.  I'd prefer the former.

There are certainly alternative ways that we could use DNS (e.g. publishing
a public key).  Of the available options, I felt this was the simplest.  I
think it could reasonably be extended to a more sophisticated solution if
one were developed.

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 17 Feb 2017 15:49:12 -0500

Thanks for the input everyone!  Here's an updated version with some
clarifications based on your feedback:
https://tools.ietf.org/html/draft-schwartz-dns-sni-02

Diff:
https://www.ietf.org/rfcdiff?url1=draft-schwartz-dns-sni-01&url2=draft-schwartz-dns-sni-02

I know this approach is controversial, so I'm also very curious to hear any
suggestions of other ways that we could fix this privacy leak without
slowing down everyone's connections.  As a friend put it: if everyone can
see you're reading justinbieber.tumblr.com, "that defeats the whole point
of HTTPS".

On Tue, Feb 14, 2017 at 1:02 PM, Ben Schwartz <[email-masked]> wrote:

> Hi dnsop,
>
> I've written a draft proposal to improve the privacy of TLS connections,
> by letting servers use the DNS to tell clients what SNI to send.
>

---

From: "John Levine" <[email-masked]>
Date: 17 Feb 2017 22:03:09 -0000

In article <[email-masked]> you write:
>slowing down everyone's connections.

I have problems with the word "other".  This approach depends for its
security on the assumption that it is hard to reverse SNI record
lookups, that is, to find the qname(s) that have SNI records with
given contents.

That is a poor assumption.  There are many large passive DNS
databases, and a lot of people have access to them.  My working
assumption is that anyone sophisticated enough to peek at TLS
handshake packets is sophisticated enough to find a passive DNS
source.

So to me the question is whether the small speculative incremental
increase in user security is worth the investment to define a new
record type, add it to DNS servers and provisioning systems, add it to
web server configuration languages, and set up whatever infrastructure
is needed to coordinate the published SNI records and what the web
servers expect.

I'd also note that if the assumption is that people will publish SNI
records through the usual registrar and dns hosting operators managed
through web consoles, there is no chance that the webware will support
SNI records.  We know this because they don't support any other
RRTYPEs defined in the past decade, either.

R's,
John

---

From: Erik Nygren <[email-masked]>
Date: Fri, 17 Feb 2017 21:02:14 -0500

I wrote a similar draft a few years ago which I've been considering
resurrecting if there is interest:

    https://tools.ietf.org/html/draft-nygren-service-bindings-00

One of the big challenges that at least in the web context, browsers want
to make as few DNS lookups as possible prior to making HTTP requests.
(For example, some home gateways choke if too many requests are
outstanding.)
Having to lookup both A and AAAA is already a problem.  So if we're going
to add
something, ideally we'd add something that was extensible that could be
used
for multiple purposes.

For this case, the result could be something like:

_https._b.www.example.com IN B 2 0 www.example.com. { "alpn": "h2",
"tls-sni": "SOME_TOKEN", "hsts": true }
_https._b.www.example.com IN B 1 0 www-alt.example.com. { "alpn":
"quic352", "tp": 443, "tls-sni": "SOME_OTHER_TOKEN", "hsts": true }

By adding this one single lookup, you both get to specify an alternate SNI,
be able to force HTTPS-only, and specify Alternative Services (ala rfc7838
but allowing it to be done in DNS).  Having an extensible model here also
increases
the value of a client doing the lookup as once the records exist other
optional
attributes can be added in.

(Ignore the specific key/value pair examples in that expired I-D.  They
made more
sense when some other things were being considered.)

Based on our extensive discussions in the TLS WG over the past few years,
introducing something like this into the DNS to indicate an alternate SNI
value
(which might be one shared with many other hostnames) or telling the client
not to send an SNI value seemed to be one of the best ways to help with
the SNI privacy problems, at least once there is a DNS privacy path.

For example, for a cert like *.example.com (perhaps with lots of other SANs
as well)
there is no reason the client needs to send "
something-potentially-private.example.com" when sending
an SNI value of "wildcard.example.com" would do just fine.  The TLS
handshake
is too late to learn this, but if we could move it into the DNS then clients
could learn it (and potentially other useful info) before connecting.

[I added DKG as he was a strong advocate of doing something in this space
for signalling TLS SNI omission, alteration, or aliasing in DNS records.]

             Erik

On Fri, Feb 17, 2017 at 3:49 PM, Ben Schwartz <[email-masked]> wrote:

> I know this approach is controversial, so I'm also very curious to hear
> any suggestions of other ways that we could fix this privacy leak without

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 17 Feb 2017 21:23:43 -0500

On Fri, Feb 17, 2017 at 5:03 PM, John Levine <[email-masked]> wrote:

> any

That was not my intent, and I don't think it's accurate.  We can consider
two cases

1. Multiple domains on the same host set the same SNI record.  Possession
of a global DNS database is no help to the adversary.  The adversary still
cannot distinguish the domains.  This is the intended use.

2. A domain sets an SNI record that is unique to that domain.  This is not
the intended use.

Case 1 is achievable whenever there are multiple domains in a certificate
(Subject Alternative Name or wildcard), with greater privacy protection as
a wider range of domains shares a certificate.

Case 2 is the only option if the domain is alone in its certificate.  In
this scenario, with current TLS, this is unavoidable.

We can certainly imagine solutions to Case 2.  For example, the SNI record
could include a public key that can be used to encrypt the SNI, e.g. RDATA
= "pubkey=<base64 encoded key>".  I would strongly support such a proposal.

Implementation of such a proposal would require changes to TLS, but would
be compatible with this draft's extensibility model.  I view this draft as
a modest step toward such solutions, allowing us to separate the question
of a new DNS record from possible TLS changes.

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 17 Feb 2017 21:37:36 -0500

>     https://tools.ietf.org/html/draft-nygren-service-bindings-00

Thanks for pointing this out, Erik!  I think a flexible binding record like
B could be a great way to solve this problem and also enable clean future
extensibility.

With the standardization of DNS over TLS, I think your binding draft might
make more sense.  Maybe it's time to revisit.

The major concerns I have about B as described there are latency and
graceful degradation.  Does this add delay to new connections?  Does it
break connections if the client is behind a resolver that silently drops
all queries other than "A"?  My impression is that, for a new record to be
widely usable, both answers must be "no".

My draft attempts to resolve both dilemmas by (1) getting a head start on
the SYNACK and (2) specifying fallback behavior if the SNI response doesn't
arrive in time, along with a strategy to minimize the impact of fallback.
Maybe those ideas could be applied to some version of B.

> _https._b.www.example.com IN B 2 0 www.example.com. { "alpn": "h2", "tls-sni": "SOME_TOKEN", "hsts": true }
> _https._b.www.example.com IN B 1 0 www-alt.example.com. { "alpn": "quic352", "tp": 443, "tls-sni": "SOME_OTHER_TOKEN", "hsts": true }
>
> For example, for a cert like *.example.com (perhaps with lots of other
> SANs as well)
> there is no reason the client needs to send "something-potentially-
> private.example.com" when sending
>> see you're reading justinbieber.tumblr.com, "that defeats the whole
>> point of HTTPS".
>>

---

From: "John R Levine" <[email-masked]>
Date: 17 Feb 2017 21:47:30 -0500

> cannot distinguish the domains.  This is the intended use.

Now I'm really confused.  If the SNI value is just a cover name, and the 
client's going to send the real name later, why not just pick a fixed 
impossible cover name like SNI.INVALID and skip the SNI lookup?

Presumably if this became at all popular, everyone will send SNI.INVALID 
so it wouldn't leak anything interesting.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 17 Feb 2017 22:41:29 -0500

> impossible cover name like SNI.INVALID and skip the SNI lookup?

In that case, one would simply omit the SNI, since it is optional.  The
draft specifies that an empty RDATA instructs the client to omit the SNI.
Currently, most TLS servers do not require SNI at all, so this will often
work ... but there's no way for the client to know ahead of time if it's
safe to omit, so the clients always include it.

The reason to allow non-empty RDATA is to support servers that serve
multiple multi-domain certificates from a single IP address, dispatched by
SNI.  This is common on CDNs and other large internet serving systems.

---

From: "John R Levine" <[email-masked]>
Date: 19 Feb 2017 10:24:59 -0500

> SNI.  This is common on CDNs and other large internet serving systems.

Oh, OK, that's helpful.

So the use case is a web server that serves a zillion domains, with the 
domains grouped into clusters that share a certificate.  For each cluster, 
you pick one of the names as the cover name, and the SNI points to that
name.  The cover name doesn't have to be in the DNS, but if it's not, that 
makes it stick out like a sore thumb.

Passive DNS on the server's IP address will reveal all of the server's 
names, and probes on those names to get the certs will reveal which names 
are in which cluster, so all SNI reveals is which names are the cover 
names.

Regards,

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Feb 2017 15:00:27 +0000

Would it be easier or harder, instead of adding a new SNI RRtype, to use
DANE TLSA records to identify the server's cert or key, and use a
variation of TLS SNI to request the cert by digest instead of by name?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: West backing southwest 6 to gale 8. Rough or very rough,
becoming high later in west Bailey. Showers, then rain later. Good,
occasionally poor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Feb 2017 15:39:34 -0500

I really don't like the proposal at all. The idea of beginning the TLS
handshake in DNS is sound. But it is a completely new handshake and
authentication layer.

Right now we have a bit of a mess with service discovery. We have a solid
proposal that makes sense written up as a standard and we have a lot of
folk saying we should do something different, either for legacy reasons or
because they find it impure.

The solid proposal is as follows:

* Discover all services using SRV *without exception*

* Use TXT records to provide additional data *that is required for
discovery and binding*

* TXT records may be bound to the service definition, thus covering all
hosts or be bound to a specific host instance.

* Domain names used for services MAY use CNAME or DNAME. Domain names that
identify services MUST NOT.

* Treat everything else as legacy. Expect Port numbers to be supplanted by
SRV prefixes. Accept that TLSA is dead. Don't tilt at windmills with yet
more discovery schemes.

I see a distinction between Hosts and Services. An internet service is
defined by an SRV prefix. A Host has a unique IP address and may support
multiple services which may also share ports.

If the objective is to conceal the service name being connected to, it
follows that any key used to conceal the service negotiation must be bound
to the host rather than the service.

The protocol that these constraints points to would use a lightweight key
agreement with a client supplied nonce and a host specific DNS key to
protect the initial TLS key agreement and then feed that key as one of the
inputs into the KDF for the service level key agreement.

One bonus of this approach is that if you don't care about authentication,
you can dispense with the service authentication altogether and use
encryption based on the host encryption alone. TLS is designed to provide
service authentication that is its purpose and the reason for most of the
complexity.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 20 Feb 2017 16:08:33 -0500

On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

> handshake in DNS is sound. But it is a completely new handshake and

What you're proposing does sound like a completely new handshake.  To be
clear, this proposal makes no change to TLS.

> proposal that makes sense written up as a standard
>

Could you point me to which document you're referring to?

> and we have a lot of folk saying we should do something different, either
> for legacy reasons or because they find it impure.
>

I'm not sure I understand this distinction.

> inputs into the KDF for the service level key agreement.

How many DNS and destination roundtrips does this require?  My impression
is that SRV records have proven unpopular in part because they generally
add a DNS roundtrip delay to each initial connection.

---

From: "John Levine" <[email-masked]>
Date: 20 Feb 2017 21:19:25 -0000

>variation of TLS SNI to request the cert by digest instead of by name?

I don't see how that would help.  Using passive DNS it's easy to find
all the names that point to a server, which makes it easy to get all
of the TLSA records for those names so the bad guy knows the hashes.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Mon, 20 Feb 2017 18:24:04 -0500

> of the TLSA records for those names so the bad guy knows the hashes.

http://www.bieberfever.com/ ("The Official Juston Bieber Fan Club") is
hosted by Akamai on 23.38.103.18.
According to DNSDB (IMO the best passive DNS service), there are 605
other sites *also* hosted on 23.38.103.18.

No doubt pervasive monitors (and others) will use passive DNS systems
to build a map of SNI DNS RRs, but I'd much much rather have the men
in black thinking that I'm visiting www.precisiondoor.net,
www.theman.in, or www.worldsleadingcruiselines.com than knowing my
dirty little secret love of the Bieb...

Even more embarrassing is my love of Kylie Minogue -- 162.249.104.157 [0]
I'd much rather have anyone watching my TLS connections think that I'm
a fan of www.artofnoiseofficial.com, lilyallen.de or one of the other
900+ sites on that IP address.

Yes, maps of $site -> SNI *will* be made, and will be used for
profiling -- but ...

"I read Playboy for the articles" only works if they have articles --
I only went to www.worldsleadingcruiselines.com to read that, *not* to
try buy the new poster, you know, the one where he's hair is *sooo*
dreamy...

W

---

From: "John R Levine" <[email-masked]>
Date: 20 Feb 2017 15:35:22 -0800

> dirty little secret love of the Bieb...

I really don't get this.  The bad guys we're worried about have to be 
sophisticated enough to do a packet capture and pick the SNI bits out of 
TLS handshakes.  How plausible is it that those bad guys would say, oh, 
using a script to find the cert hashes that will reveal the specific site 
is too hard so never mind?

R's,
John

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 20 Feb 2017 19:06:24 -0500

John R Levine wrote:
> sophisticated enough to do a packet capture and pick the SNI bits out of TLS
> handshakes.  How plausible is it that those bad guys would say, oh, using a
> script to find the cert hashes that will reveal the specific site is too
> hard so never mind?

Isn't the server's certificate encrypted in TLS 1.3?

And even in previous versions of TLS, at least in the CDN world it's
somewhat common to put unrelated domains on the same SAN certificate.

-- 
Robert Edmonds

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Feb 2017 19:06:37 -0500

On Mon, Feb 20, 2017 at 4:08 PM, Ben Schwartz <[email-masked]> wrote:

> On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker <
> [email-masked]> wrote:
>

​Well there is your problem. There is little point in doing this unless you
feed the result into the TLS handshake to follow. ​

> Could you point me to which document you're referring to?

https://tools.ietf.org/html/rfc6763

>> * Domain names used for services MAY use CNAME or DNAME. Domain names
>> that identify services MUST NOT.
>>
>

​Ooops...​

 Domain names that identify
​HOSTS
 MUST NOT.

​A service is an abstract Internet service which may be provided by any
host chosen from group of hosts ​specified in an SRV record. A host is a
physical machine.

​SRV records map services to hosts.​
​A and AAAA records map hosts to IP addresses.​

> add a DNS roundtrip delay to each initial connection.

​One if it is done right.​

You are going to want to lock down your client to resolver DNS and you
might as well fix the protocol at the same time. That is why standardizing
on DNS-SD for everything is the way to go.

---

From: "John R Levine" <[email-masked]>
Date: 20 Feb 2017 16:59:36 -0800

> Isn't the server's certificate encrypted in TLS 1.3?

Yes, but Tony's proposal as I understood it was to use the hash from a 
TLSA certificate instead of the text of the SNI domain.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Feb 2017 12:42:30 +1100

In message <CAMm+Lwj1JZLUh6K1ipYjW_989u6ea+tYHHps4Gavf_d=[email-masked]>
, Phillip Hallam-Baker writes:
> Well there is your problem. There is little point in doing this unless
> you
> feed the result into the TLS handshake to follow.
>
>
> Ooops...
> HOSTS
> A service is an abstract Internet service which may be provided by any
> host chosen from group of hosts specified in an SRV record. A host is a
> physical machine.
>
> SRV records map services to hosts.
> A and AAAA records map hosts to IP addresses.
>
>
> One if it is done right.

Zero if it is done right.  We can easily extend the DNS to say
"Fetch the additional record for the SRV records before answering"
if you have this EDNS option present or just have the server do it
without the option.  There is nothing preventing a recursive server
just doing this today.

This is the essential difference between a CNAME and SRV records
as far as browser vendors are concerned.  Waiting for the "full"
answer rather than returning a partial answer when there are no
cached address records.

We already have RFC that say go lookup missing data before constructing
a response.  We do this for DNS64.  We do this for CNAME.

If the SRV prefix is _http._tcp or _https._tcp then the recursive
server SHOULD fetch any missing additional address records for the
SRV server including CNAME records if the server name maps to a
CNAME and add them to the addtional section prior to returning the
response.  You could even just do this for all SRV lookups.

A RFC saying something like this would solve the SRV issue over the
long term a recursive servers get replaced.  Unfortunately brower
vendors don't seem to want to say "yes, we will add SRV support if
you change the DNS to do this".

And if they have a issue with the prefix one can allocate a new TYPE(s)
for class IN that does the same as SRV records but is for http and https.

Service to address can be done with a single lookup and can include the
TLSA records as well.

This is a server that prefetches missing additional data and know
about looking up TLSA records.  You will notice that the additional
section get populated just by the client looking up MX records.  If
you ask with DO=1 you can even get validatible results.

Mark

[rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50368
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 5d5611ff91b234cea8fc5d2858ab99833bfd56c3a5adef30 (good)
;; QUESTION SECTION:
;isc.org.			IN	MX

;; ANSWER SECTION:
isc.org.		7200	IN	MX	20 mx.ams1.isc.org.
isc.org.		7200	IN	MX	10 mx.pao1.isc.org.
isc.org.		7200	IN	RRSIG	MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ=

;; Query time: 2435 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 12:36:03 EST 2017
;; MSG SIZE  rcvd: 279

[rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47874
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 577d2fa83b7277682a8675f358ab9986654bdc6b80e4161c (good)
;; QUESTION SECTION:
;isc.org.			IN	MX

;; ANSWER SECTION:
isc.org.		7197	IN	MX	20 mx.ams1.isc.org.
isc.org.		7197	IN	MX	10 mx.pao1.isc.org.
isc.org.		7197	IN	RRSIG	MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ=

;; ADDITIONAL SECTION:
mx.pao1.isc.org.	3599	IN	A	149.20.64.53
mx.pao1.isc.org.	3599	IN	RRSIG	A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk=

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 12:36:06 EST 2017
;; MSG SIZE  rcvd: 467

[rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64268
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: eb9c5203e623a5489e068cae58ab9988f7a5f11cc716a2df (good)
;; QUESTION SECTION:
;isc.org.			IN	MX

;; ANSWER SECTION:
isc.org.		7195	IN	MX	10 mx.pao1.isc.org.
isc.org.		7195	IN	MX	20 mx.ams1.isc.org.
isc.org.		7195	IN	RRSIG	MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ=

;; ADDITIONAL SECTION:
mx.pao1.isc.org.	3597	IN	A	149.20.64.53
mx.pao1.isc.org.	3598	IN	AAAA	2001:4f8:0:2::2b
mx.pao1.isc.org.	3597	IN	RRSIG	A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk=
mx.pao1.isc.org.	3598	IN	RRSIG	AAAA 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. rOGdKaW/50E/UWD1Ko0rWwcMDJa9gp2tlX+LS1yoHm95TNZ6v5ZIxugj WUPl73nG3mJ8S15/rP+CLz6twIDJkFi5eCS7wXEmBXjuCVJfBhqDzIVJ tA+9AalM44j77nZpn71FWi50EW8M7NVV89c8BxdOkHtV/o4RjvVEs1iU GV0=

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 12:36:08 EST 2017
;; MSG SIZE  rcvd: 667

[rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6978
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 1a50a8309bac059e81215eed58ab998ad77ca4375f67865f (good)
;; QUESTION SECTION:
;isc.org.			IN	MX

;; ANSWER SECTION:
isc.org.		7193	IN	MX	10 mx.pao1.isc.org.
isc.org.		7193	IN	MX	20 mx.ams1.isc.org.
isc.org.		7193	IN	RRSIG	MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ=

;; ADDITIONAL SECTION:
mx.pao1.isc.org.	3595	IN	A	149.20.64.53
mx.pao1.isc.org.	3596	IN	AAAA	2001:4f8:0:2::2b
mx.pao1.isc.org.	3595	IN	RRSIG	A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk=
mx.pao1.isc.org.	3596	IN	RRSIG	AAAA 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. rOGdKaW/50E/UWD1Ko0rWwcMDJa9gp2tlX+LS1yoHm95TNZ6v5ZIxugj WUPl73nG3mJ8S15/rP+CLz6twIDJkFi5eCS7wXEmBXjuCVJfBhqDzIVJ tA+9AalM44j77nZpn71FWi50EW8M7NVV89c8BxdOkHtV/o4RjvVEs1iU GV0=
_25._tcp.mx.pao1.isc.org. 3598	IN	RRSIG	TLSA 5 6 3600 20170322234239 20170220234239 56778 pao1.isc.org. VnV0NTtAdpvfqpLaS2zF4IDKjIN97YPuKSmZ1tXrMLvoVlxutwPiH6El cTCQe/1Pi3QTqTFWr3kste3zIxDgAnnbmCKPbQDH2qsf67MBKM/Rv01O 1jmny3qM18Oqhsf+XTMsYEPe/YYsJzyw9aNydqI2egzkb4X8mpCTl+ge di4=
_25._tcp.mx.pao1.isc.org. 3598	IN	TLSA	3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 12:36:10 EST 2017
;; MSG SIZE  rcvd: 895

[rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50265
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 1143a155c849920e213ee6cf58ab998f2fc22d8d9cdeb566 (good)
;; QUESTION SECTION:
;isc.org.			IN	MX

;; ANSWER SECTION:
isc.org.		7188	IN	MX	10 mx.pao1.isc.org.
isc.org.		7188	IN	MX	20 mx.ams1.isc.org.
isc.org.		7188	IN	RRSIG	MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ=

;; ADDITIONAL SECTION:
mx.pao1.isc.org.	3590	IN	A	149.20.64.53
mx.ams1.isc.org.	3597	IN	A	199.6.1.65
mx.pao1.isc.org.	3591	IN	AAAA	2001:4f8:0:2::2b
mx.pao1.isc.org.	3590	IN	RRSIG	A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk=
mx.pao1.isc.org.	3591	IN	RRSIG	AAAA 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. rOGdKaW/50E/UWD1Ko0rWwcMDJa9gp2tlX+LS1yoHm95TNZ6v5ZIxugj WUPl73nG3mJ8S15/rP+CLz6twIDJkFi5eCS7wXEmBXjuCVJfBhqDzIVJ tA+9AalM44j77nZpn71FWi50EW8M7NVV89c8BxdOkHtV/o4RjvVEs1iU GV0=
_25._tcp.mx.pao1.isc.org. 3593	IN	RRSIG	TLSA 5 6 3600 20170322234239 20170220234239 56778 pao1.isc.org. VnV0NTtAdpvfqpLaS2zF4IDKjIN97YPuKSmZ1tXrMLvoVlxutwPiH6El cTCQe/1Pi3QTqTFWr3kste3zIxDgAnnbmCKPbQDH2qsf67MBKM/Rv01O 1jmny3qM18Oqhsf+XTMsYEPe/YYsJzyw9aNydqI2egzkb4X8mpCTl+ge di4=
mx.ams1.isc.org.	3597	IN	RRSIG	A 5 4 3600 20170322234059 20170220234059 13926 ams1.isc.org. AWHYspeFvJNWrYl78Q4XNnrhIFTUgYS40RUD8tYK0lJ/cIm61yMVzfSJ 5goMRIDXGDBFCAhkNoh7Ld09hfxI4rP6p0pxSRZIbuBj/CQDQ9e8/Wry o4WfRnKajj80/aU4p+68JNg8Fy92s2s/MWqsfBbtJ35Bubc4Qq33rvTE YYE=
_25._tcp.mx.pao1.isc.org. 3593	IN	TLSA	3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 12:36:15 EST 2017
;; MSG SIZE  rcvd: 1083

[rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24483
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 11

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 0d0910d171a5c357fa78b5e458ab999a280908b6527ae8bb (good)
;; QUESTION SECTION:
;isc.org.			IN	MX

;; ANSWER SECTION:
isc.org.		7177	IN	MX	10 mx.pao1.isc.org.
isc.org.		7177	IN	MX	20 mx.ams1.isc.org.
isc.org.		7177	IN	RRSIG	MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ=

;; ADDITIONAL SECTION:
mx.pao1.isc.org.	3579	IN	A	149.20.64.53
mx.ams1.isc.org.	3586	IN	A	199.6.1.65
mx.pao1.isc.org.	3580	IN	AAAA	2001:4f8:0:2::2b
mx.ams1.isc.org.	3589	IN	AAAA	2001:500:60::65
mx.pao1.isc.org.	3579	IN	RRSIG	A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk=
mx.pao1.isc.org.	3580	IN	RRSIG	AAAA 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. rOGdKaW/50E/UWD1Ko0rWwcMDJa9gp2tlX+LS1yoHm95TNZ6v5ZIxugj WUPl73nG3mJ8S15/rP+CLz6twIDJkFi5eCS7wXEmBXjuCVJfBhqDzIVJ tA+9AalM44j77nZpn71FWi50EW8M7NVV89c8BxdOkHtV/o4RjvVEs1iU GV0=
_25._tcp.mx.pao1.isc.org. 3582	IN	RRSIG	TLSA 5 6 3600 20170322234239 20170220234239 56778 pao1.isc.org. VnV0NTtAdpvfqpLaS2zF4IDKjIN97YPuKSmZ1tXrMLvoVlxutwPiH6El cTCQe/1Pi3QTqTFWr3kste3zIxDgAnnbmCKPbQDH2qsf67MBKM/Rv01O 1jmny3qM18Oqhsf+XTMsYEPe/YYsJzyw9aNydqI2egzkb4X8mpCTl+ge di4=
mx.ams1.isc.org.	3586	IN	RRSIG	A 5 4 3600 20170322234059 20170220234059 13926 ams1.isc.org. AWHYspeFvJNWrYl78Q4XNnrhIFTUgYS40RUD8tYK0lJ/cIm61yMVzfSJ 5goMRIDXGDBFCAhkNoh7Ld09hfxI4rP6p0pxSRZIbuBj/CQDQ9e8/Wry o4WfRnKajj80/aU4p+68JNg8Fy92s2s/MWqsfBbtJ35Bubc4Qq33rvTE YYE=
mx.ams1.isc.org.	3589	IN	RRSIG	AAAA 5 4 3600 20170322234059 20170220234059 13926 ams1.isc.org. RsCprRb3PCx0I6U5H+F5QVGNZhg978B1UJCHP/OEoZ8tK0cPZFyiXKk/ BhKeW9QjuDPWg2oYEXYmggowvMy3lWxlOODA161vD1DPaaS79lxCSp19 4GRmdl1146FYZD+jFi2OHsOpn2cTcXtw4bAK4KG9YiFytOBEftD58q3B h+g=
_25._tcp.mx.pao1.isc.org. 3582	IN	TLSA	3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 12:36:26 EST 2017
;; MSG SIZE  rcvd: 1283

[rock:~/git/bind9-marka] marka% dig mx isc.org +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58776
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 9a370fc4fe12b2f891fb40ef58ab9a32f9725da6e638d98c (good)
;; QUESTION SECTION:
;isc.org.			IN	MX

;; ANSWER SECTION:
isc.org.		7025	IN	MX	20 mx.ams1.isc.org.
isc.org.		7025	IN	MX	10 mx.pao1.isc.org.
isc.org.		7025	IN	RRSIG	MX 5 2 7200 20170322234053 20170220234053 13953 isc.org. gH/RpE45SX9aZTGEWmIHcCGYN8ihF/4H3RwYuVkfMPlrZKc/5OsRSuXd AP6wxYgBWNpTWKK3Rl/tCWkDiW9bHA+XjEvhMLeYabdr8Zt8zbXrLFGc mcRGE34YA0uPKkNqTVKjWU6uqFrKkEjxoQU+bWkDnlyd71FRhxIcdZSS hGQ=

;; ADDITIONAL SECTION:
mx.pao1.isc.org.	3427	IN	A	149.20.64.53
mx.ams1.isc.org.	3434	IN	A	199.6.1.65
mx.pao1.isc.org.	3428	IN	AAAA	2001:4f8:0:2::2b
mx.ams1.isc.org.	3437	IN	AAAA	2001:500:60::65
mx.pao1.isc.org.	3427	IN	RRSIG	A 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. lCq2rUOEhMVaUReRtetEQpn3ceuw5Y0vJq8wU7quPsrmFLN7SYMtLgyZ DzVAHJThrrO1WERjz2uA3PTkG4KSQFpRCDC33wTWi9hWsdTapgYablmO tOK/uOabKX8invwG/R7EVZ9KQ1lRamtn8gWDRI77NLQ3PWcV+4BnydaG 8bk=
mx.pao1.isc.org.	3428	IN	RRSIG	AAAA 5 4 3600 20170322234239 20170220234239 56778 pao1.isc.org. rOGdKaW/50E/UWD1Ko0rWwcMDJa9gp2tlX+LS1yoHm95TNZ6v5ZIxugj WUPl73nG3mJ8S15/rP+CLz6twIDJkFi5eCS7wXEmBXjuCVJfBhqDzIVJ tA+9AalM44j77nZpn71FWi50EW8M7NVV89c8BxdOkHtV/o4RjvVEs1iU GV0=
_25._tcp.mx.pao1.isc.org. 3430	IN	RRSIG	TLSA 5 6 3600 20170322234239 20170220234239 56778 pao1.isc.org. VnV0NTtAdpvfqpLaS2zF4IDKjIN97YPuKSmZ1tXrMLvoVlxutwPiH6El cTCQe/1Pi3QTqTFWr3kste3zIxDgAnnbmCKPbQDH2qsf67MBKM/Rv01O 1jmny3qM18Oqhsf+XTMsYEPe/YYsJzyw9aNydqI2egzkb4X8mpCTl+ge di4=
mx.ams1.isc.org.	3434	IN	RRSIG	A 5 4 3600 20170322234059 20170220234059 13926 ams1.isc.org. AWHYspeFvJNWrYl78Q4XNnrhIFTUgYS40RUD8tYK0lJ/cIm61yMVzfSJ 5goMRIDXGDBFCAhkNoh7Ld09hfxI4rP6p0pxSRZIbuBj/CQDQ9e8/Wry o4WfRnKajj80/aU4p+68JNg8Fy92s2s/MWqsfBbtJ35Bubc4Qq33rvTE YYE=
mx.ams1.isc.org.	3437	IN	RRSIG	AAAA 5 4 3600 20170322234059 20170220234059 13926 ams1.isc.org. RsCprRb3PCx0I6U5H+F5QVGNZhg978B1UJCHP/OEoZ8tK0cPZFyiXKk/ BhKeW9QjuDPWg2oYEXYmggowvMy3lWxlOODA161vD1DPaaS79lxCSp19 4GRmdl1146FYZD+jFi2OHsOpn2cTcXtw4bAK4KG9YiFytOBEftD58q3B h+g=
_25._tcp.mx.ams1.isc.org. 3448	IN	RRSIG	TLSA 5 6 3600 20170322234059 20170220234059 13926 ams1.isc.org. IFlqqd2rOCNA/9lj++bw1UnlpwpvNE4AcgFpNj1JFwhHUvW6lbEWBjVY nYraYR1OMypOC+GxFxpxiSfTo+17V9j+PomD4tj7HeFVJNDteE1Uqqs9 iSfFj6pdtKK+DkA04svaO2CIKLONd/TabDb2f8fOMa7AFH/H6cSN69Qt uz4=
_25._tcp.mx.pao1.isc.org. 3430	IN	TLSA	3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0
_25._tcp.mx.ams1.isc.org. 3448	IN	TLSA	3 0 1 5EF9B10DA21B2711522982EAD699FBABE77FD07FF07AC810608A85DA 66AFE916

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 12:38:58 EST 2017
;; MSG SIZE  rcvd: 1511

[rock:~/git/bind9-marka] marka% 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Feb 2017 21:08:37 -0500

> without the option.  There is nothing preventing a recursive server

​+1 Actually that is what I was assuming.

If we are using the current DNS protocol then all we need to do is to
program the DNS servers to intelligently add the necessary additional RRs.

Alternatively, if we are doing DNS over QUIC then we could tweak the
protocol so that this is the default.​

> response.  You could even just do this for all SRV lookups.

​Yup. The only catch is that we all need to do discovery the same way. That
is why SRV+TXT as specified in RFC6763 is the way to go​

> you change the DNS to do this".

I don't think they are interested in SRV just for SRV. But SRV for this
plus SNI encryption could be enough.

We could also fix up some sort of backwards compatibility scheme. A DNS
server that knows that _http._tcp.example.com is http over port 80 can
convert A/AAAA records as needed.

If we are dealing with a trusted DNS resolver chosen by the relying party
that is constant, we can do things like advertise 'next generation
discovery'.

> Service to address can be done with a single lookup and can include the

I would prefer to specify the security policy in an accompanying prefixed
TXT record because I need more than TLSA provides.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Feb 2017 13:34:05 +1100

In message <[email-masked]>
, Phillip Hallam-Baker writes:
> +1 Actually that is what I was assuming.
>
> protocol so that this is the default.
>
> Yup. The only catch is that we all need to do discovery the same way.
> That
> is why SRV+TXT as specified in RFC6763 is the way to go
>
>
>

Or just add the A/AAAA records to the additional section of the
NXDOMAIN/NODATA response to the SRV query using the base name.
The client can synthesize the response using the additional data.
That way the DNS server doesn't need to know the port mappings.

If qtype is SRV strip off leading underscore labels and add addresses
records for the resulting name to the additional section of the
response.

Or the client can just do parallel lookups and wait for all the
responses before proceeding.  Set a flag day N years out for when
to stop performing the A/AAAA lookups.  They can decide to stop
doing parallel lookups much earlier when they see SRV records being
returned consistently.  The flag day is just to sunset backwards
lookups.

Mark