Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Tony Finch]

Brian Dickson  wrote:
>
> Would it be feasible to limit the behavior of "refuse-any" returning
> "partial" UDP responses, to situations where EDNS with DO=1 is used?

No, this is a defence mechanism, so it needs to cope with uncooperative
clients.

> Older resolvers would need to have some method of getting answers, so
> maybe for those, use the TC=1 method?

There's no "need", partial answers to QTYPE=ANY interoperate fine.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Southerly or southwesterly backing southeasterly at times, 4 or 5,
increasing 6 or 7 at times. Moderate or rough. Rain or showers. Moderate or
good.

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

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

[Robert Edmonds]

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

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

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

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

[Paul Wouters]

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.

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.


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

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

Re: [DNSOP] draft-ietf-dnsop-terminology-bis and "recursive resolver"

[神明達哉]

At Thu, 19 Jan 2017 13:51:33 -0500,
Ted Lemon  wrote:

> I'm updating a document for another working group, and Ralph Droms
> in his last call comments on that document asked me to use
> "recursive resolver" instead of "caching name server", referencing
> draft-ietf-dnsop-terminology-bis.   That document doesn't actually
> define "recursive resolver," but instead "full service resolver,"
> which means almost, but not quite, the same thing.   The document
> does use the term "recursive resolver" fairly liberally despite
> there not being a definition for it.   Given that "recursive
> resolver" is in such common use, including in this document, I think
> the document should include a definition for "recursive resolver".

I agree.  My understanding is that the original terminology draft
restricted itself to terms already defined in existing RFCs an that's
probably why "recursive resolver" wasn't given a definition.  I
thought we are now more flexible in bis, so it makes sense to me to
give a "formal definition" to widely used terms like "recursive
resolver".

--
JINMEI, Tatuya

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

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

[Wessels, Duane]

> On Feb 14, 2017, at 10:02 AM, Ben Schwartz  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  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 , 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  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 .  But then the empty label "." becomes particularly 
tricky here because, arguably, a  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 
 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


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

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

[Robert Edmonds]

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

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

[Ralph Droms]

We've extracted issues from the reviews of draft-ietf-dnsop-sutld-ps posted to 
the list so far, and entered them into the GitHub repo: 
https://github.com/Abhayakara/draft-tldr-sutld-ps 
  We're tracking discussion 
and resolution for issues there, as well.  Text revisions for a few issues have 
been committed to the XML source and the associated issues have been closed.

Additional feedback during the WG last call is, of course, encouraged...

- Ralph


> On Feb 2, 2017, at 6:04 PM, Suzanne Woolf  wrote:
> 
> This message opens a Working Group Last Call for:
> 
> "Special-Use Names Problem Statement"
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ 
> 
> Proposed status: informational
> 
> Starts: 2 Feb. 2017
> Ends: 23 Feb. 2017 (3 weeks)
> 
> Discussion should go to the mailing list. 
> 
> Is this draft ready to advance for publication as an Informational RFC, and 
> as guidance for possible updates to RFC 6761? Does it describe the relevant 
> issues clearly, and cover all the relevant ones that should be taken into 
> account in future work in the IETF on the special use names registry or RFC 
> 6761?
> 
> If not, can you suggest changes that would get your support for advancing it? 
> (“Send text” if possible!)
> 
> 
> thanks,
> Suzanne & 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] Proposal for a new record type: SNI

[John Levine]

In article  you write:
>This seems like a bandaid to TLS that I think just needs
>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

___
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 <20170214203924.5c4v6l5b3bjip...@mycre.ws> you write:
>   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".

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

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

Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2017-02-16

[Paul Hoffman]

On 3 Feb 2017, at 7:40, IESG Secretary wrote:


Webex details will follow


Hopefully before the meeting. Setting up WebEx can take at least two 
tries for any new meeting.


--Paul Hoffman

___
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 Tue, Feb 14, 2017 at 5:14 PM, John Levine  wrote:
> In article  you write:
>>This seems like a bandaid to TLS that I think just needs
>>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.

I'm /s/ 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 :-))

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

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

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

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

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

[Adrien de Croy]

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" 
To: "Robert Edmonds" 
Cc: "dnsop@ietf.org" 
Sent: 15/02/2017 9:03:09 AM
Subject: Re: [DNSOP] Proposal for a new record type: SNI




On Tue, Feb 14, 2017 at 2:16 PM, Robert Edmonds  
wrote:

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



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


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