Re: [DNSOP] Published: draft-hardaker-rfc5011-security-considerations-04.txt

[Petr Špaček]

Version 04 addresses all my comments, thank you!

If you decide to mention me in the document feel to use "Petr Spacek" as
ASCII version of my name to avoid the Unicode madness.

Have a nice day.
Petr Špaček  @  CZ.NIC

On 02/17/2017 10:38 PM, Wes Hardaker wrote:
> 
> For those following along with this draft, I've just published -04.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Digest, Vol 123, Issue 70

[Viktor Dukhovni]

> On Feb 20, 2017, at 4:19 PM, dnsop-requ...@ietf.org wrote:
> 
> Accept that TLSA is dead. Don't tilt at windmills with yet more discovery 
> schemes.

There at least ~2400 MX hosts with published TLSA records for SMTP serving over
100k domains and growing.  In addition to Postfix and Exim, vendors are starting
to implement DANE for SMTP.  Adoption is not surprisingly slow, but TLSA for 
SMTP
is certainly not "dead", and adoption will accelerate as more MTAs and service
providers add support.

If you're talking about TLSA for HTTPS, then indeed it is not likely to be used
at all soon...  Whether that's dead or just dormant is presently academic.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] finding the issue tracker

[Mark Andrews]

It's hard to find issue trackers if they are not recorded as such.

https://github.com/Abhayakara/draft-tldr-sutld-ps/issues

should be listed as the issues tracker for

https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:  +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

In message 
, Phillip Hallam-Baker writes:
> On Mon, Feb 20, 2017 at 8:42 PM, Mark Andrews  wrote:
>
> >
> >
> > 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.
> >
>
> +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.
>
> 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.
> >
>
> 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
>
>
>
> > 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".
> >
>
> 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/ records as needed.

Or just add the A/ 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/ 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.

> 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'.
> 
> 
> 
> > 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.
> >
> 
> I would prefer to specify the security policy in an accompanying prefixed
> TXT record because I need more than TLSA provides.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Phillip Hallam-Baker]

On Mon, Feb 20, 2017 at 8:42 PM, Mark Andrews  wrote:

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

​+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.​

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

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



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

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/ 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'.



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

I would prefer to specify the security policy in an accompanying prefixed
TXT record because I need more than TLSA provides.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

In message 
, Phillip Hallam-Baker writes:
> On Mon, Feb 20, 2017 at 4:08 PM, Ben Schwartz  wrote:
>
> > On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker <
> > ph...@hallambaker.com> wrote:
> >
> >> 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.
> >>
> >
> > What you're proposing does sound like a completely new handshake.  To be
> > clear, this proposal makes no change to TLS.
> >
>
> Well there is your problem. There is little point in doing this unless
> you
> feed the result into the TLS handshake to follow.
>
>
> 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
> >>
> >
> > Could you point me to which document you're referring to?
> >
>
> https://tools.ietf.org/html/rfc6763
>
>
>
> > 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.
> >>
> >
> > I'm not sure I understand this distinction.
> >
>
> 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  records map hosts to IP addresses.
>
>
> > 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.
> >
>
> 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.7200IN  MX  20 mx.ams1.isc.org.
isc.org.7200IN  MX  10 mx.pao1.isc.org.
isc.org.7200IN  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
;; 

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

[John R Levine]

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?


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,
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] Proposal for a new record type: SNI

[Phillip Hallam-Baker]

On Mon, Feb 20, 2017 at 4:08 PM, Ben Schwartz  wrote:

> On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker <
> ph...@hallambaker.com> wrote:
>
>> 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.
>>
>
> What you're proposing does sound like a completely new handshake.  To be
> clear, this proposal makes no change to TLS.
>

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


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
>>
>
> Could you point me to which document you're referring to?
>

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



> 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.
>>
>
> I'm not sure I understand this distinction.
>

​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  records map hosts to IP addresses.​


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

​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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Robert Edmonds]

John R Levine wrote:
> > 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...
> 
> 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?

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

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


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Mon, Feb 20, 2017 at 4:19 PM, John Levine  wrote:
> In article  you write:
>>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?
>
> 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.

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




>
> R's,
> John
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

In article  you write:
>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?

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Phillip Hallam-Baker]

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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop