Re: [DNSOP] Prefixed name spaces and DANE client TLSA

[Shane Kerr]

Shumon,

At 2016-01-13 09:30:01 -0500
Shumon Huque  wrote:
> (And Shane - it wasn't the "first thing we though of" - in fact all
> alternate
> suggestions brought up in the thread had already be considered by the
> authors of the draft.)

I apologize for my mis-characterization. I was both ignorant and unkind,
things that I dislike in others and hate in myself. :(

Cheers,

--
Shane

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

Re: [DNSOP] Prefixed name spaces and DANE client TLSA

[Shumon Huque]

On Thu, Jan 14, 2016 at 2:25 PM, Rob Austein  wrote:

>
> I would recommend that you think about how any of these proposed
> schemes interact with DNS wildcards.  Yes, some people use wildcards
> with TLSA RRs, or even with CNAME RRs pointing to TLSA RRs: this
> allows one to express "every service on machine foo.example.org uses
> the same certificate" concisely.
>

Sure. For client credentials, the most natural use of wildcards I envision
would be to specify that a given client uses the same credentials for all
application protocols. In our proposed form, this can be accomplished
by replacing the leading _app label with a wildcard. Or by aliasing a
defined set of per-app names to a generic name.

So if one buys George's analysis of this as a role vs protocol
> distinction, the question becomes whether it's more useful to be able
> to group by roles or by protocols.  That is, are you more likely to
> want to say "all roles for protocol foo use the same certificate",
> "all protocols for role foo use the same certificate", or just not
> allow any kind of grouping here at all.  The first of these makes the
> most sense to me, YMMV.
>

I assume here that role means a "client", "server" or other role for the
same application protocol.

We also need to define what protocol means - is it the application
protocol or the transport protocol? If considering both independently,
we have additional possible groupings.

But yes, I agree that making it easy to group the commonly expected
ways should be a goal. Assuming the base domain name will be the
same in each grouping, "all protocols for role foo" should be expressible
with wildcards. "All roles for application protocol Foo" is a bit more
challenging, since the client TLSA record uses a symbolic name for the
application whereas the server TLSA record uses a port number. Assumptions
could be made about applications using well known ports I guess, but
that doesn't offer a complete solution.

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

Re: [DNSOP] Prefixed name spaces and DANE client TLSA

[John R Levine]

This doesn't let you alias server certs without also aliasing client
certs, no idae if that would be a problem in practice.  The comments
in RFC 6698 suggest that aliasing server certs is rarely useful.


Just on the last point, I couldn't find where in 6698 it says that about
aliases, ...


You're right, it doesn't, but it does say disparaging things about 
wildcards which have sort of the same issues.



but RFC 7671 offers two design patterns involving aliases
for server TLSA records that might be common - one for virtual hosting,
and another to alias many server records to a common DANE-TA
issuer.


I'd think DNAMEs would work great for that.  Publish one set of records 
describing the common issuer, then use a few DNAMEs to point everyone else 
at it, e.g. in the client case:


  $ORIGIN hostco.example
  _submission._client._tcp TLSA ... issuer info ...
  _pop3s._client._tcp CNAME _submission._client._tcp
  _pop3._client._tcp CNAME _submission._client._tcp
  _imaps._client._tcp CNAME _submission._client._tcp
  _imap._client._tcp CNAME _submission._client._tcp
  _xmpp-client._client._tcp CNAME _submission._client._tcp

then

  _client._tcp.bob.example. DNAME _client.tcp.hostco.example.
  _client._tcp.carol.example. DNAME _client.tcp.hostco.example.
  _client._tcp.ted.example. DNAME _client.tcp.hostco.example.
  _client._tcp.alice.example. DNAME _client.tcp.hostco.example.

This has the nice property of creating exactly the records you want, as 
opposed to wildcards which match everything whether or not it makes sense.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

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

Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming

[Paul Hoffman]

Thanks for the review!

On 14 Jan 2016, at 11:32, 神明達哉 wrote:


Here are my comments on the 06 version:

- Section 3.1

 [...]  This would be when the resolver starts with an empty cache,
 and when one or more of the NS records for the root servers has
 expired.

This seems to talk about a recursive server behavior that allows a
subset of an RRset to expire.  Is that the intent?  Is there any
reason why we can't simply say "...and when the NS RRSet for the
root zone has expired."?


Good catch. The RRset will expire at the same time.


(btw I think 'root zone' is better
than 'root servers' here).


This is not the expiration on the whole root zone, only on the NS 
records. The expiration of the root zone itself comes from the SOA, 
which has a different value than the TTLs on the NS RRset. That is, in 
the current root, the expiration in the SOA is 604800 but the TTLs on 
the NS records are 518400.



- Section 3.1: some modern recursive servers "prefetch" un-expired
RRsets.  We might also mention that case here.


Yes.


- Section 3.3

 [...]  At the time this
 document is being published, there is little use to performing DNSSEC
 validation on the priming query because the "root-servers.net" zone
 is not signed, and so a man-in-the-middle attack on the priming query
 can result in malicious data in the responses.

I think this text needs more explanation.  Since the priming query
is "./NS", it's not immediately obvious why the fact that
"root-servers.net" is unsigned matters.  This text seems to be based
on some implicit assumptions/facts such as:
- all root servers are authoritative for the root-servers.net zone
- we'll eventually need  and A RRsets of the NS names
- even if ./NS is signed, it's not very useful in practice unless
  these  and A are also signed
and, reading between the lines I think I can agree with the seeming
intent, but IMO it should be explained more clearly and explicitly.


The first bullet point is not necessary for your argument. Would the 
following be better than the quoted sentence?


At the time this document is being published, there is little use to 
performing
DNSSEC validation on the priming query. This is because being able to 
validate
the NS records is not sufficient for having authenticated addresses for 
the root
servers: having validated A and  RRsets for each root server is also 
needed.
Without those validated A and AAA RRsets, a man-in-the-middle attack on 
the

priming query can result in malicious data in the responses



- Section 4.1

 answer section) and an Additional section with A and/or  RRSets
 for the root name servers pointed at by the NS RRSet.

Similar to the previous point, it seems to be based on some implicit
assumptions including:
- all root servers are authoritative for the root-servers.net zone
- all these servers populate the additional section from a different
  zone they are authoritative for than that for the query name ("."
  in this case)
- none of the root server implementations use the
  "minimal-responses" (or equivalent) option

I think these should be clearly stated.


Those implicit assumptions are not needed for the current text. RFCs 
1034 and 1035 and 2181 do not restrict what can be put in the Additional 
section to only being things for which the server is authoritative.




- Section 4.2

 For an EDNS response, a resolver SHOULD consider the address
 information found in the Additional section complete for any
 particular server that appears at all.

This one also seems to assume some particular behavior of the root
server implementations.  At least protocol-wise, we cannot
necessarily assume this completeness, right?  Then I'd also suggest
clarifying the assumption.


This seems like a reasonable question. What do others think?



Editorial nits:

- Section 3.2: s/other other/other/

 [...]  Two other other
 common methods include picking the first from the list, and

- Section 4.2: s/to to/to/

 [...]  Instead, the recursive resolver needs to to
 issue direct queries for A and  RRSets for the remaining names.


Fixed. Thanks again!

--Paul Hoffman

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-priming-06.txt

[Paul Hoffman]

On 14 Jan 2016, at 10:25, Bob Harold wrote:


Section 1 says
[RFC1034] describes
that configuration as a list of servers that will authoritative
answers to queries about the root.

s/that will authoritative answers to/that will give authoritative 
answers to/

(or "that will authoritatively answer")


Good catch; fixed.


Section 3 says
The RD bit MAY be set to 0 or 1, although the meaning of it being set
to 1 is undefined for priming queries.

But a priming query is just a normal DNS query, so RD would be defined
normally, no?


It would be defined normally, yes. Section 4.1 says that a priming query 
should come back with an authoritative answer. Setting the RD bit to 1 
could result in non-authoritative answers.


How does the WG feel about this? If the response to a priming query is 
non-authoritative, should the resolver reject it and try more queries? 
Or is it OK for a priming response to be non-authoritative?


--Paul Hoffman

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-priming-06.txt

[Bob Harold]

On Wed, Jan 13, 2016 at 5:32 PM,  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Domain Name System Operations Working Group 
> of the IETF.
>
> Title   : Initializing a DNS Resolver with Priming Queries
> Authors : Peter Koch
>   Matt Larson
>   Paul Hoffman
> Filename: draft-ietf-dnsop-resolver-priming-06.txt
> Pages   : 6
> Date: 2016-01-13
>
> Abstract:
>This document describes the queries a DNS resolver can emit to
>initialize its cache.  The result is that the resolver gets both a
>current NS RRSet for the root zone and the necessary address
>information for reaching the root servers.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-resolver-priming-06
>
>

Section 1 says
[RFC1034] describes
that configuration as a list of servers that will authoritative
answers to queries about the root.

s/that will authoritative answers to/that will give authoritative answers to/
(or "that will authoritatively answer")


Section 3 says
The RD bit MAY be set to 0 or 1, although the meaning of it being set
to 1 is undefined for priming queries.

But a priming query is just a normal DNS query, so RD would be defined
normally, no?

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

Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming

[神明達哉]

At Wed, 13 Jan 2016 13:53:06 -0800,
"Paul Hoffman"  wrote:

> We'd really like folks to review it, particularly because this is such a
> large change from earlier versions. The document is still definitely
> open for discussion, and if there is consensus to reverse some of the
> changes, that's of course fine. Regardless, let's get this published in
> a form where everyone (?) is happy.

Here are my comments on the 06 version:

- Section 3.1

   [...]  This would be when the resolver starts with an empty cache,
   and when one or more of the NS records for the root servers has
   expired.

  This seems to talk about a recursive server behavior that allows a
  subset of an RRset to expire.  Is that the intent?  Is there any
  reason why we can't simply say "...and when the NS RRSet for the
  root zone has expired."? (btw I think 'root zone' is better
  than 'root servers' here).

- Section 3.1: some modern recursive servers "prefetch" un-expired
  RRsets.  We might also mention that case here.

- Section 3.3

   [...]  At the time this
   document is being published, there is little use to performing DNSSEC
   validation on the priming query because the "root-servers.net" zone
   is not signed, and so a man-in-the-middle attack on the priming query
   can result in malicious data in the responses.

  I think this text needs more explanation.  Since the priming query
  is "./NS", it's not immediately obvious why the fact that
  "root-servers.net" is unsigned matters.  This text seems to be based
  on some implicit assumptions/facts such as:
  - all root servers are authoritative for the root-servers.net zone
  - we'll eventually need  and A RRsets of the NS names
  - even if ./NS is signed, it's not very useful in practice unless
these  and A are also signed
  and, reading between the lines I think I can agree with the seeming
  intent, but IMO it should be explained more clearly and explicitly.

- Section 4.1

   answer section) and an Additional section with A and/or  RRSets
   for the root name servers pointed at by the NS RRSet.

  Similar to the previous point, it seems to be based on some implicit
  assumptions including:
  - all root servers are authoritative for the root-servers.net zone
  - all these servers populate the additional section from a different
zone they are authoritative for than that for the query name ("."
in this case)
  - none of the root server implementations use the
"minimal-responses" (or equivalent) option

  I think these should be clearly stated.

- Section 4.2

   For an EDNS response, a resolver SHOULD consider the address
   information found in the Additional section complete for any
   particular server that appears at all.

  This one also seems to assume some particular behavior of the root
  server implementations.  At least protocol-wise, we cannot
  necessarily assume this completeness, right?  Then I'd also suggest
  clarifying the assumption.

Editorial nits:

- Section 3.2: s/other other/other/

   [...]  Two other other
   common methods include picking the first from the list, and

- Section 4.2: s/to to/to/

   [...]  Instead, the recursive resolver needs to to
   issue direct queries for A and  RRSets for the remaining names.

--
JINMEI, Tatuya

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

Re: [DNSOP] Prefixed name spaces and DANE client TLSA

[Rob Austein]

[Commenting only on technical aspect of the name structure --
discussion of whether the namespace is cluttered, pretty, intuitive,
etc, are too abstract for me.  Not making light of user confusion
issues, just recusing on them.]

I would recommend that you think about how any of these proposed
schemes interact with DNS wildcards.  Yes, some people use wildcards
with TLSA RRs, or even with CNAME RRs pointing to TLSA RRs: this
allows one to express "every service on machine foo.example.org uses
the same certificate" concisely.

So if one buys George's analysis of this as a role vs protocol
distinction, the question becomes whether it's more useful to be able
to group by roles or by protocols.  That is, are you more likely to
want to say "all roles for protocol foo use the same certificate",
"all protocols for role foo use the same certificate", or just not
allow any kind of grouping here at all.  The first of these makes the
most sense to me, YMMV.

Wildcards are probably also the main technical reason for caring about
differences between the naming for TLSA and SRV RRs.

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