Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Geoff Huston]

>> 
>> 
>> All of the following conditions must be met to trigger special
>> processing inside resolver code:
>> 
>> o  The DNS response is DNSSEC validated
>> 
>> o  The result of validation is “Secure”.
>> 
>> o  The Checking Disabled (CD) bit in the query is not set.
>> 
>> o  The QTYPE is either A or  (Query Type value 1 or 28).
>> 
>> o  The OPCODE is QUERY.
>> 
>> o  The leftmost label of the original QNAME (the name sent in the
>>   Question Section in the original query) is either "root-key-
>>   sentinel-is-ta-" or "root-key-sentinel-not-ta-”.
>> 
>> 
>> Geoff
> 
> I think that is the way to go.
> 

Mark, thanks for your patience with my evident cluelessness!


Geoff


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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Mark Andrews]

> On 4 Apr 2018, at 2:30 pm, Geoff Huston  wrote:
> 
> 
> 
>> 
>> No.  Below is self contradictory. Condition 1 requires that
>> CD=1 be turned into CD=0 and condition 3 requires that no special
>> processing happens for CD=1.
>> 
>> How CD is handled determines what you are testing when you have
>> resolvers in series.
>> 
>> Do you want CD=1 to disable special processing?
> 
> yes
> 
>> Do you want to only test the first validator?
> 
> yes
> 
>> Do you want to test the entire chain?
> 
> no
> 
>> Do you want consistency?
> 
> err, umm - yes? (is this a trick question? :-) )
> 
>> 
>> All the scenarios need to be worked through remembering that there
>> is a cache that may be populated.
>> 
> 
> 
> Mark, would it help if the phrase “regardless of whether DNSSSEC validation 
> was requested.” 
> was removed?
> 
> i.e.:
> 
> 
> All of the following conditions must be met to trigger special
> processing inside resolver code:
> 
> o  The DNS response is DNSSEC validated
> 
> o  The result of validation is “Secure”.
> 
> o  The Checking Disabled (CD) bit in the query is not set.
> 
> o  The QTYPE is either A or  (Query Type value 1 or 28).
> 
> o  The OPCODE is QUERY.
> 
> o  The leftmost label of the original QNAME (the name sent in the
>Question Section in the original query) is either "root-key-
>sentinel-is-ta-" or "root-key-sentinel-not-ta-”.
> 
> 
> Geoff

I think that is the way to go.


-- 
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] [Doh] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Davey Song]

I'm sorry to hear that. I would like to provide some information as a
background if it's useful.

dns-wireformat-http draft was originally proposed in DNSOP WG as a
experimental draft in early 2016. We focus on the requirement of enhancing
DNS availability bypassing the middlebox on the path via HTTP tunnel.  It
was later adopted in DNSOP WG as WG document. I think it was an original
and sound work deserving us to work on at that time.

However, it was postponed in 2017 and we are told that HTTP people has
concern on it.  At that time, draft-hoffman-dispatch-dns-over-https was
proposed as a standards track aiming to defined HTTPS as substrate
transport for DNS which is different from the DNS over HTTP tunnel case.

Later DOH was created forcusing on HTTPS as DNS transport protocol. We were
told that the proxy and tunnel case is not in the scope of DOH but we are
suggested use the technology developed in DOH. At that time I still think
it is valuable to introduce a use case of DNS over HTTP tunnel and define
necessary protocol. The compromise is that we drop the free use of
HTTP(without TLS) and HTTP 1.x because DOH has mandatory requirement on
HTTPS and HTT /2.

When I submited dnsop-dns-wireformat-http-02 weeks ago, I asked if we could
introduce a optional parameter which is bettern than a new media type
"application/dns-tcpwireformat". I suppose that optional parameter should
defined in dnsop-dns-wireformat-http-02 instead of DOH draft. However,
after original_transport optional parameter was defined in 05 version of
doh draft, I'm afraid it was enlarged its scope to contain the proxy/tunnel
case which make people think dns-wireformat-http is useless. I'm confused.

So I would like to ask folks in the two WGs how to proceed:

1) Should dns-wireformat-http draft insists on the original defination of
DNS over HTTP(s) tunnel with new HTTP header as a experimental document?
Because that is the original experiment we have done to show the capacity
of DNS over HTTP(s).
2) If the answer is no, how should  dns-wireformat-http draft align itself
with DOH document. My suggestion is to define the original_transport
optional parameter in  dns-wireformat-http draft.

Or Is there any other way out not abandoning our work? As the co-author I
still want to rescue it.

-Davey



On 4 April 2018 at 10:35, Martin Thomson  wrote:

> On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman 
> wrote:
> > Martin: Are you saying that you want DOH to remove the optional
> parameter from the application/dns-udpwireformat registration? If so, what
> do you propose for the DNSOP WG?
>
> Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
> concede that I'm probably missing something.
>
> By my current understanding, draft-ietf-dnsop-dns-wireformat-http is
> indistinguishable from a specific implementation of
> draft-ietf-doh-dns-over-https.  That is, if a DOH server wanted to
> service all its queries by forwarding requests to a resolver [1], I
> can't see how that would be disallowed by DOH, and that's exactly what
> draft-ietf-dnsop-dns-wireformat-http appears to describe.
>
> Convince me that this isn't the case (or not, and I'll be in the rough on
> this).
>
> --Martin
>
> [1] ...after randomizing the ID.
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Geoff Huston]

> 
> No.  Below is self contradictory. Condition 1 requires that
> CD=1 be turned into CD=0 and condition 3 requires that no special
> processing happens for CD=1.
> 
> How CD is handled determines what you are testing when you have
> resolvers in series.
> 
> Do you want CD=1 to disable special processing?

yes

> Do you want to only test the first validator?

yes

> Do you want to test the entire chain?

no

> Do you want consistency?

err, umm - yes? (is this a trick question? :-) )

> 
> All the scenarios need to be worked through remembering that there
> is a cache that may be populated.
> 


Mark, would it help if the phrase “regardless of whether DNSSSEC validation was 
requested.” 
was removed?

i.e.:


 All of the following conditions must be met to trigger special
 processing inside resolver code:

 o  The DNS response is DNSSEC validated

 o  The result of validation is “Secure”.

 o  The Checking Disabled (CD) bit in the query is not set.

 o  The QTYPE is either A or  (Query Type value 1 or 28).

 o  The OPCODE is QUERY.

 o  The leftmost label of the original QNAME (the name sent in the
Question Section in the original query) is either "root-key-
sentinel-is-ta-" or "root-key-sentinel-not-ta-”.


Geoff

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Dave Lawrence]

Martin Thomson writes:
> Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
> concede that I'm probably missing something.

I think that's right.  -05 with the original_transport optional
parameter accommodates the aims of that other draft.

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

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Joe Abley]

On Apr 3, 2018, at 21:32, Frederico A C Neves  wrote:

>> On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote:
>> Hi Frederico,
>> 
>>> On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
>>> I was looking at our server to evaluate the MIXFR implementation and
>>> it seams to me that the current text covering dnssec aware client
>>> logic don't take in account that a posterior record at the addition
>>> section, by an MIXFR DNSSEC aware server, will implicitly replace the
>>> RRSIG RRset.
>> 
>> I am unclear what case you are covering.
> 
> Any situation that you have an updated RRset. It is implicit that
> you'll have to update the signature, so I was arguing that this is
> afterward covered by 3.6 Replace a RRset. My "simplified" logic take
> this in account to don't impose this extra logic at the client for
> updated RRsets, only for removed RRsets, explicit or when a removal of
> RR causes it.

I have not been reading this thread in depth and so I have not commented up 
until now. But I sense that there is a proposed shift of responsibility for 
coherency in the contents of a zone, specifically with resapect to DNSSEC. 
Quite possibly I am wrong, in which case I will enjoy being told as much.

If I am a zone administrator, responsible for the self-consistent contents of 
my zone, and I make a mistake, the behaviour today (with zones distributed by 
AXFR, IXFR, rsync, ftp, avian carrier) is that a DNS zone is a DNS zone and the 
RRSets contained within are simply that, no appreciation, understanding or 
accommodation of DNSSEC required.

The line of thinking inherent in the lowest quoted paragraph above suggests 
that distribution of sets of RRSets (together forming a zone) must with this 
new transfer mechanism be completed with semantic appreciation for the 
relationship between non-RRSIG-type RRSets and the corresponding RRSIG-type 
RRSets that accompany them in a signed zone. This worries me.

The protocol requirements for DNSSEC as described in RFC 4035 are non-trivial 
to implement already (cf. the treatment of RRSets in a response with their 
accompanying RRSIG RRSets as an atomic unit in the cache, to be expired 
together regardless of differences in TTL) and I don't think we want to extend 
them without good reason.

If we expect MIXFR (or whatever it is eventually called) to behave differently 
in this respect to AXFR, IXFR or any number of out-of-band transfer mechanisms, 
we should have a good reason for it. I don't know that I see one, yet.


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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Martin Thomson]

On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman  wrote:
> Martin: Are you saying that you want DOH to remove the optional parameter 
> from the application/dns-udpwireformat registration? If so, what do you 
> propose for the DNSOP WG?

Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
concede that I'm probably missing something.

By my current understanding, draft-ietf-dnsop-dns-wireformat-http is
indistinguishable from a specific implementation of
draft-ietf-doh-dns-over-https.  That is, if a DOH server wanted to
service all its queries by forwarding requests to a resolver [1], I
can't see how that would be disallowed by DOH, and that's exactly what
draft-ietf-dnsop-dns-wireformat-http appears to describe.

Convince me that this isn't the case (or not, and I'll be in the rough on this).

--Martin

[1] ...after randomizing the ID.

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Mark Andrews]

> On 4 Apr 2018, at 11:17 am, Geoff Huston  wrote:
> 
>> On 4 Apr 2018, at 10:59 am, Mark Andrews  wrote:
>> 
>> 
>>> On 4 Apr 2018, at 10:28 am, Geoff Huston  wrote:
>>> 
>>> I thought that if the query contained CD = 1 then the DNS response
>>> would not be validated,
>> 
>> This ONLY applies if the answer is NOT ALREADY CACHED.  If the answer
>> is already cached then CD=1 queries will get this processing as the
>> answer returned from the cache will be “secure” or “insecure” depending
>> on ealier validation.  If you don’t want CD=1 queries to get this processing
>> you need to explicitly exclude it.  You can’t depend on the answer NOT being
>> cached.
>> 
> 
> Mark,
> 
> If I understand you correctly, then the preconditions need to include
> an explicit provision that the CD bit is not set. 
> 
> Does the following wording work for you?

No.  Below is self contradictory. Condition 1 requires that
CD=1 be turned into CD=0 and condition 3 requires that no special
processing happens for CD=1.

How CD is handled determines what you are testing when you have
resolvers in series.

Do you want CD=1 to disable special processing?
Do you want to only test the first validator?
Do you want to test the entire chain?
Do you want consistency?

All the scenarios need to be worked through remembering that there
is a cache that may be populated.

>  All of the following conditions must be met to trigger special
>  processing inside resolver code:
> 
>  o  The DNS response is DNSSEC validated, regardless of whether
> DNSSSEC validation was requested.
> 
>  o  The result of validation is “Secure”.
> 
>  o  The Checking Disabled (CD) bit in the query is not set.
> 
>  o  The QTYPE is either A or  (Query Type value 1 or 28).
> 
>  o  The OPCODE is QUERY.
> 
>  o  The leftmost label of the original QNAME (the name sent in the
> Question Section in the original query) is either "root-key-
> sentinel-is-ta-" or "root-key-sentinel-not-ta-”.
> 
> 
> regards,
> 
>   Geoff
> 

-- 
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] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Davey Song]

On 3 April 2018 at 17:58, Martin Thomson  wrote:

> If I understand your response (not sure that I do), that seems pretty
> academic and not at all persuasive.  For instance, if a client cared
> about testing TCP capabilities, it can always do its own resolution.


It's not the emphasis. Peopole get tied of misbehavior (or unexperect
behavior) of all kinds of middlebox. I just think DOH proxy should not add
any fuel on that.

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

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Frederico A C Neves]

Hi Matthijs,

On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote:
> Hi Frederico,
> 
> On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
> > I was looking at our server to evaluate the MIXFR implementation and
> > it seams to me that the current text covering dnssec aware client
> > logic don't take in account that a posterior record at the addition
> > section, by an MIXFR DNSSEC aware server, will implicitly replace the
> > RRSIG RRset.
> 
> I am unclear what case you are covering.

Any situation that you have an updated RRset. It is implicit that
you'll have to update the signature, so I was arguing that this is
afterward covered by 3.6 Replace a RRset. My "simplified" logic take
this in account to don't impose this extra logic at the client for
updated RRsets, only for removed RRsets, explicit or when a removal of
RR causes it.

So the actual difference on the wire is one server replacing the RRSIG
and the other adding it. For the client processing is RRSIG removal
logic only at RRset removal in one case and at any change for the
other. Bellow a zone at serial 1 and 2 and the two MIXFR versions.

example.IN  SOA serial=1
example.IN  RRSIG SOA
a.example.  IN  A   192.0.2.1
a.example.  IN  RRSIG A
b.example.  IN  A   192.0.2.2
b.example.  IN  A   192.0.2.3
b.example.  IN  RRSIG A

example.IN  SOA serial=2
example.IN  RRSIG SOA
b.example.  IN  A   192.0.2.3
b.example.  IN  A   192.0.2.4
b.example.  IN  RRSIG A
c.example.  IN  A   192.0.2.5
c.example.  IN  RRSIG A


# "simplified MIXFR"
example.IN  SOA serial=2
example.IN  SOA serial=1
a.example.  ANY A
b.example.  IN  A   192.0.2.2
example.IN  SOA serial=2
b.example.  IN  A   192.0.2.4
b.example.  ANY RRSIG A
c.example.  IN  A   192.0.2.5
c.example.  IN  RRSIG A
example.IN  SOA serial=2

# "implicit RRSIG removal at any change"
example.IN  SOA serial=2
example.IN  SOA serial=1
a.example.  ANY A
b.example.  IN  A   192.0.2.2
example.IN  SOA serial=2
b.example.  IN  A   192.0.2.4
b.example.  IN  RRSIG A
c.example.  IN  A   192.0.2.5
c.example.  IN  RRSIG A
example.IN  SOA serial=2

> 
> > Logic could be simplified only to Deletions of RRs, when they conclude
> > a removal of a RRset, or RRsets by itself.
> 
> No, also if there is an RR addition, it means the RRset has changed, so 
> existing RRSIG records can be implicitly removed.
> 

That is true but in this case you imply that it will be later added. I
was proposing to replace it.

> > All the other cases, addition or replacement, will be covered
> > automatically by an addition or replace of a RRSIG RRset. There is no
> > need to extra client logic to remove RRSIG, at addition of a RR, and
> > at deletion of a RR if it not remove the RRset.
> 
> Note there is no such thing as an RRSIG RRset. I tried to clarify this 
> in the terminology bis document:

So how do you call, two RR for the same name, type and class in a
double signed zone? Never mind I was not aware of this, thanks! Change
"a RRSIG RRset" by "any RRSIGs" and the logic still stands.

> 
>https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html
> 
> Note that adding an RRSIG is different than replacing an RRSIG.

Ok, but we could achive the same end result with both logics and
operations.

> 
> > This is documented as issue #10 and includes proposed text.
> > 
> > https://github.com/matje/mixfr/issues/10
> 
> I think it makes more sense to keep the text as is, that is when 
> changing an RRset implicitly remove the corresponding RRSIG records. I 
> am opposed to only removing corresponding RRSIG on a RR deletion.
> 

I think my version is easyer imposing less checks on clients but I can
live with the current text

I just realized the draft needs a new example for 4.2. The current one
is based on "Delete All RRsets of a Type". This operations was removed
in the current version of the draft.

> Best regards,
>Matthijs

Fred

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Geoff Huston]

> On 4 Apr 2018, at 10:59 am, Mark Andrews  wrote:
> 
> 
>> On 4 Apr 2018, at 10:28 am, Geoff Huston  wrote:
>> 
>> I thought that if the query contained CD = 1 then the DNS response
>> would not be validated,
> 
> This ONLY applies if the answer is NOT ALREADY CACHED.  If the answer
> is already cached then CD=1 queries will get this processing as the
> answer returned from the cache will be “secure” or “insecure” depending
> on ealier validation.  If you don’t want CD=1 queries to get this processing
> you need to explicitly exclude it.  You can’t depend on the answer NOT being
> cached.
> 

Mark,

If I understand you correctly, then the preconditions need to include
an explicit provision that the CD bit is not set. 

Does the following wording work for you?


  All of the following conditions must be met to trigger special
  processing inside resolver code:

  o  The DNS response is DNSSEC validated, regardless of whether
 DNSSSEC validation was requested.

  o  The result of validation is “Secure”.

  o  The Checking Disabled (CD) bit in the query is not set.

  o  The QTYPE is either A or  (Query Type value 1 or 28).

  o  The OPCODE is QUERY.

  o  The leftmost label of the original QNAME (the name sent in the
 Question Section in the original query) is either "root-key-
 sentinel-is-ta-" or "root-key-sentinel-not-ta-”.


regards,

   Geoff

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Mark Andrews]

> On 4 Apr 2018, at 10:28 am, Geoff Huston  wrote:
> 
> I thought that if the query contained CD = 1 then the DNS response
> would not be validated,

This ONLY applies if the answer is NOT ALREADY CACHED.  If the answer
is already cached then CD=1 queries will get this processing as the
answer returned from the cache will be “secure” or “insecure” depending
on ealier validation.  If you don’t want CD=1 queries to get this processing
you need to explicitly exclude it.  You can’t depend on the answer NOT being
cached.

> and precondition 1 would not be met.


> But I’m probably wrong, so could you please suggest wording here?
> 
> regards,
> 
> Geoff
> 
> 
>> On 4 Apr 2018, at 10:21 am, Mark Andrews  wrote:
>> 
>> You are effectively saying that the resolver MUST ignore CD=1 for these 
>> queries.
>> 
>>> On 4 Apr 2018, at 7:36 am, Geoff Huston  wrote:
>>> 
>>> 
>>> 
 On 4 Apr 2018, at 7:11 am, Paul Hoffman  wrote:
 
 On 3 Apr 2018, at 13:45, Geoff Huston wrote:
 
> Is the wording “that the resolver has to do DNSSEC validation on what it 
> gets back from the authoritative server *regardless* of whether the 
> originating client requests it?” a clarification that updates the 
> validation behaviours as specified in RFC4035 and RFC6840 as to when a 
> security aware resolver performs validation? Or merely a clarification of 
> the precondition in the context of the sentinel behaviour but of no wider 
> import?
 
 The latter. Otherwise, someone reading the document might not understand 
 that the response must be validated no matter what.
>>> 
>>> 
>>> So you are saying that the document should revert to the wording:
>>> 
>>> All of the following conditions must be met to trigger special
>>> processing inside resolver code:
>>> 
>>> o  The DNS response is DNSSEC validated, regardless of whether
>>>DNSSSEC validation was requested.
>>> 
>>> o  The result of validation is “Secure".
>>> 
>>> o  The QTYPE is either A or  (Query Type value 1 or 28).
>>> 
>>> o  The OPCODE is QUERY.
>>> 
>>> o  The leftmost label of the original QNAME (the name sent in the
>>>Question Section in the original query) is either "root-key-
>>>sentinel-is-ta-" or "root-key-sentinel-not-ta-”.
>>> 
>>> 
>>> (I’ve split the initial condition into two explicit preconditions to be 
>>> consistent with the rest of the enumerated list)
>>> 
>>> Any objections to this from the WG? I’ll wait for 24 hours and then post 
>>> this wording as version 11 unless the WG says otherwise
>>> 
> 

-- 
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] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Geoff Huston]

I thought that if the query contained CD = 1 then the DNS response
would not be validated, and precondition 1 would not be met.

But I’m probably wrong, so could you please suggest wording here?

regards,

Geoff


> On 4 Apr 2018, at 10:21 am, Mark Andrews  wrote:
> 
> You are effectively saying that the resolver MUST ignore CD=1 for these 
> queries.
> 
>> On 4 Apr 2018, at 7:36 am, Geoff Huston  wrote:
>> 
>> 
>> 
>>> On 4 Apr 2018, at 7:11 am, Paul Hoffman  wrote:
>>> 
>>> On 3 Apr 2018, at 13:45, Geoff Huston wrote:
>>> 
 Is the wording “that the resolver has to do DNSSEC validation on what it 
 gets back from the authoritative server *regardless* of whether the 
 originating client requests it?” a clarification that updates the 
 validation behaviours as specified in RFC4035 and RFC6840 as to when a 
 security aware resolver performs validation? Or merely a clarification of 
 the precondition in the context of the sentinel behaviour but of no wider 
 import?
>>> 
>>> The latter. Otherwise, someone reading the document might not understand 
>>> that the response must be validated no matter what.
>> 
>> 
>> So you are saying that the document should revert to the wording:
>> 
>>  All of the following conditions must be met to trigger special
>>  processing inside resolver code:
>> 
>>  o  The DNS response is DNSSEC validated, regardless of whether
>> DNSSSEC validation was requested.
>> 
>>  o  The result of validation is “Secure".
>> 
>>  o  The QTYPE is either A or  (Query Type value 1 or 28).
>> 
>>  o  The OPCODE is QUERY.
>> 
>>  o  The leftmost label of the original QNAME (the name sent in the
>> Question Section in the original query) is either "root-key-
>> sentinel-is-ta-" or "root-key-sentinel-not-ta-”.
>> 
>> 
>> (I’ve split the initial condition into two explicit preconditions to be 
>> consistent with the rest of the enumerated list)
>> 
>> Any objections to this from the WG? I’ll wait for 24 hours and then post 
>> this wording as version 11 unless the WG says otherwise
>> 

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Mark Andrews]

You are effectively saying that the resolver MUST ignore CD=1 for these queries.

> On 4 Apr 2018, at 7:36 am, Geoff Huston  wrote:
> 
> 
> 
>> On 4 Apr 2018, at 7:11 am, Paul Hoffman  wrote:
>> 
>> On 3 Apr 2018, at 13:45, Geoff Huston wrote:
>> 
>>> Is the wording “that the resolver has to do DNSSEC validation on what it 
>>> gets back from the authoritative server *regardless* of whether the 
>>> originating client requests it?” a clarification that updates the 
>>> validation behaviours as specified in RFC4035 and RFC6840 as to when a 
>>> security aware resolver performs validation? Or merely a clarification of 
>>> the precondition in the context of the sentinel behaviour but of no wider 
>>> import?
>> 
>> The latter. Otherwise, someone reading the document might not understand 
>> that the response must be validated no matter what.
> 
> 
> So you are saying that the document should revert to the wording:
> 
>   All of the following conditions must be met to trigger special
>   processing inside resolver code:
> 
>   o  The DNS response is DNSSEC validated, regardless of whether
>  DNSSSEC validation was requested.
> 
>   o  The result of validation is “Secure".
> 
>   o  The QTYPE is either A or  (Query Type value 1 or 28).
> 
>   o  The OPCODE is QUERY.
> 
>   o  The leftmost label of the original QNAME (the name sent in the
>  Question Section in the original query) is either "root-key-
>  sentinel-is-ta-" or "root-key-sentinel-not-ta-”.
> 
> 
> (I’ve split the initial condition into two explicit preconditions to be 
> consistent with the rest of the enumerated list)
> 
> Any objections to this from the WG? I’ll wait for 24 hours and then post this 
> wording as version 11 unless the WG says otherwise
> 
> Thanks,
> 
>  Geoff
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Geoff Huston]

> On 4 Apr 2018, at 7:11 am, Paul Hoffman  wrote:
> 
> On 3 Apr 2018, at 13:45, Geoff Huston wrote:
> 
>> Is the wording “that the resolver has to do DNSSEC validation on what it 
>> gets back from the authoritative server *regardless* of whether the 
>> originating client requests it?” a clarification that updates the validation 
>> behaviours as specified in RFC4035 and RFC6840 as to when a security aware 
>> resolver performs validation? Or merely a clarification of the precondition 
>> in the context of the sentinel behaviour but of no wider import?
> 
> The latter. Otherwise, someone reading the document might not understand that 
> the response must be validated no matter what.


So you are saying that the document should revert to the wording:

   All of the following conditions must be met to trigger special
   processing inside resolver code:

   o  The DNS response is DNSSEC validated, regardless of whether
  DNSSSEC validation was requested.

   o  The result of validation is “Secure".

   o  The QTYPE is either A or  (Query Type value 1 or 28).

   o  The OPCODE is QUERY.

   o  The leftmost label of the original QNAME (the name sent in the
  Question Section in the original query) is either "root-key-
  sentinel-is-ta-" or "root-key-sentinel-not-ta-”.


(I’ve split the initial condition into two explicit preconditions to be 
consistent with the rest of the enumerated list)

Any objections to this from the WG? I’ll wait for 24 hours and then post this 
wording as version 11 unless the WG says otherwise

Thanks,

  Geoff

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

[DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Wessels, Duane]

Greetings dnsop,

This draft proposes a technique and new RR type for calculating and verifying a 
message digest over the contents of a zone file.  Using this technique, the 
recipient of a zone containing the new RR type can verify it for completeness 
and correctness, especially so when the zone is signed.  We welcome your 
feedback on this document.

DW


=

A new version of I-D, draft-wessels-dns-zone-digest-00.txt
has been successfully submitted by Duane Wessels and posted to the
IETF repository.

Name:   draft-wessels-dns-zone-digest
Revision:   00
Title:  Message Digest for DNS Zones
Document date:  2018-03-31
Group:  Individual Submission
Pages:  13
URL:
https://www.ietf.org/internet-drafts/draft-wessels-dns-zone-digest-00.txt
Status: https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/
Htmlized:   https://tools.ietf.org/html/draft-wessels-dns-zone-digest-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wessels-dns-zone-digest


Abstract:
  This document describes a protocol and DNS Resource Record used to
  provide a message digest over DNS zone data.  In particular, it
  describes how to compute, sign, represent, and use the message digest
  to verify the contents of a zone for accuracy and completeness.  The
  ZONEMD Resource Record type is introduced for conveying the message
  digest data.



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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Paul Hoffman]

On 3 Apr 2018, at 13:45, Geoff Huston wrote:

Is the wording “that the resolver has to do DNSSEC validation on 
what it gets back from the authoritative server *regardless* of 
whether the originating client requests it?” a clarification that 
updates the validation behaviours as specified in RFC4035 and RFC6840 
as to when a security aware resolver performs validation? Or merely a 
clarification of the precondition in the context of the sentinel 
behaviour but of no wider import?


The latter. Otherwise, someone reading the document might not understand 
that the response must be validated no matter what.


--Paul Hoffman

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Geoff Huston]

> On 3 Apr 2018, at 11:42 pm, Paul Hoffman  wrote:
> 
> 
> On 3 Apr 2018, at 1:34, Geoff Huston wrote:
> 
>> I’ll remove the condition then.
> 
> Will you re-instate what Petr asked for, namely some wording that indicates 
> that the resolver has to do DNSSEC validation on what it gets back from the 
> authoritative server *regardless* of whether the originating client requests 
> it? Without that, it is unclear what a resolver should do.
> 


Hi Paul,

(You should colour me as still confused!)

Is the wording “that the resolver has to do DNSSEC validation on what it gets 
back from the authoritative server *regardless* of whether the originating 
client requests it?” a clarification that updates the validation behaviours as 
specified in RFC4035 and RFC6840 as to when a security aware resolver performs 
validation? Or merely a clarification of the precondition in the context of the 
sentinel behaviour but of no wider import?


thanks,

   Geoff

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

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ted Lemon]

On Apr 3, 2018, at 1:00 PM, Dave Lawrence  wrote:
> That testing TCP capabilities part is a distraction from the core
> motivation.  The request makes sense from a dumb transparent proxy
> point of view, where there's a regular DNS resolver on the one end who
> just wants to be able to get DNS messages through an HTTPS tunnel.
> Media type isn't the right way to achieve that, but the key idea is sound.

This didn't actually clear things up for me.   I think that what you mean is 
that you don't want the tunnel server to do truncation detection and retry over 
TCP—is that right?   If so, that's a point worth discussing explicitly.   I 
think you could make arguments for both positions. Given that you're doing 
DNS-over-HTTP-over-SSL-over-TCP here, the tunnel server definitely could do 
truncation detection and retry, and that would probably perform better.   Also, 
if it's a DNS server that's just consulting its cache, doing truncation is just 
a waste of time.

But possibly I misunderstood your point?

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

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Dave Lawrence]

Martin Thomson writes:
> If I understand your response (not sure that I do), that seems pretty
> academic and not at all persuasive.  For instance, if a client cared
> about testing TCP capabilities, it can always do its own resolution.

That testing TCP capabilities part is a distraction from the core
motivation.  The request makes sense from a dumb transparent proxy
point of view, where there's a regular DNS resolver on the one end who
just wants to be able to get DNS messages through an HTTPS tunnel.
Media type isn't the right way to achieve that, but the key idea is sound.

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Evan Hunt]

On Tue, Apr 03, 2018 at 06:32:49PM +1000, Geoff Huston wrote:
> So this text is saying that the AD bit is set if the resolver considers all
> RRsets in the Answer section to be authentic. Fair enough.

More correctly, the bit is cleared if the resolver *doesn't* consider all
RRsets to be validly signed, but the distinction probably isn't that
important here.

> What happens when neither DO nor AD is set in the request? 

"dig +noends +noadflag" will produce such a query, if you want to try
it out.

> Do you get a response that is authentic (but without any explicit signalling
> in the response  that would indicate that authentication has occurred) or the
> Servfail response in the case where authentication fails?

This. The resolver attempts validation and returns a plain-looking answer
if the response was valid or provably insecure, SERVFAIL if bogus.

> Or do you get a response that is not necessarily authenticated even though
> the CD bit is not set?
> 
> If its the former then the AD bit may or may not be set on responses even
> though they have been "DNSSEC validated”

That's correct.

(Also the AD flag can easily be turned on or off by an intermediate proxy,
so you should never rely on it for much of anything, really.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Matthijs Mekking]

On 03-04-18 15:22, Mark Andrews wrote:


-- Mark Andrews

On 3 Apr 2018, at 22:37, Matthijs Mekking
wrote:

Hi Frederico,


On 03/29/2018 08:45 PM, Frederico A C Neves wrote: I was looking
at our server to evaluate the MIXFR implementation and it seams
to me that the current text covering dnssec aware client logic
don't take in account that a posterior record at the addition 
section, by an MIXFR DNSSEC aware server, will implicitly replace

the RRSIG RRset.

I am unclear what case you are covering.



Logic could be simplified only to Deletions of RRs, when they
conclude a removal of a RRset, or RRsets by itself.

No, also if there is an RR addition, it means the RRset has
changed, so existing RRSIG records can be implicitly removed.

>

Poor logic. Take the case where you add a new algorithm to the DNSKEY
RRset there is no requirement to update existing RRSIG.


If I add a DNSKEY record to the RRset, I would definitely want a new 
RRSIG because the data changed, so the existing signature is no longer 
useful.




Even when re-signing you can’t remove RRSIG with the same key id
unless you know that the server prevents duplicate key ids.  For the
general case you need to validate the RRset against the RRSIG to give
the DNSKEY then you can delete RRSIGs generated from that DNSKEY.


Implicit RRSIG deletion is only for RRSIG records covering the RRset 
that has changed. It is not meant for re-signing purposes, nor is it 
meant for sophisticated DNSKEY tracking.



- Matthijs



All the other canonrequirementses, addition or replacement, will
be covered automatically by an addition or replace of a RRSIG
RRset. There is no need to extra client logic to remove RRSIG, at
addition of a RR, and at deletion of a RR if it not remove the
RRset.

Note there is no such thing as an RRSIG RRset. I tried to clarify
this in the terminology bis document:

https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html

Note that adding an RRSIG is different than replacing an RRSIG.


This is documented as issue #10 and includes proposed text. 
https://github.com/matje/mixfr/issues/10

I think it makes more sense to keep the text as is, that is when
changing an RRset implicitly remove the corresponding RRSIG
records. I am opposed to only removing corresponding RRSIG on a RR
deletion.

Best regards, Matthijs



Fred ___ 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




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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Hoffman]

On Apr 3, 2018, at 2:58 AM, Martin Thomson  wrote:
> 
> If I understand your response (not sure that I do), that seems pretty
> academic and not at all persuasive.  

to you. It was persuasive enough for the DNSOP WG to adopt the document as 
a WG item.

> For instance, if a client cared
> about testing TCP capabilities, it can always do its own resolution.

That's not what draft-ietf-dnsop-dns-wireformat-http is about.

Martin: Are you saying that you want DOH to remove the optional parameter from 
the application/dns-udpwireformat registration? If so, what do you propose for 
the DNSOP WG?

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

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Mark Andrews]

-- 
Mark Andrews

> On 3 Apr 2018, at 22:37, Matthijs Mekking  wrote:
> 
> Hi Frederico,
> 
>> On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
>> I was looking at our server to evaluate the MIXFR implementation and
>> it seams to me that the current text covering dnssec aware client
>> logic don't take in account that a posterior record at the addition
>> section, by an MIXFR DNSSEC aware server, will implicitly replace the
>> RRSIG RRset.
> 
> I am unclear what case you are covering.
> 
> 
>> Logic could be simplified only to Deletions of RRs, when they conclude
>> a removal of a RRset, or RRsets by itself.
> 
> No, also if there is an RR addition, it means the RRset has changed, so 
> existing RRSIG records can be implicitly removed.

Poor logic. Take the case where you add a new algorithm to the DNSKEY RRset 
there is no requirement to update existing RRSIG.

Even when re-signing you can’t remove RRSIG with the same key id unless you 
know that the server prevents duplicate key ids.  For the general case you need 
to validate the RRset against the RRSIG to give the DNSKEY then you can delete 
RRSIGs generated from that DNSKEY. 

>> All the other canonrequirementses, addition or replacement, will be covered
>> automatically by an addition or replace of a RRSIG RRset. There is no
>> need to extra client logic to remove RRSIG, at addition of a RR, and
>> at deletion of a RR if it not remove the RRset.
> 
> Note there is no such thing as an RRSIG RRset. I tried to clarify this in the 
> terminology bis document:
> 
>  https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html
> 
> Note that adding an RRSIG is different than replacing an RRSIG.
> 
> 
>> This is documented as issue #10 and includes proposed text.
>> https://github.com/matje/mixfr/issues/10
> 
> I think it makes more sense to keep the text as is, that is when changing an 
> RRset implicitly remove the corresponding RRSIG records. I am opposed to only 
> removing corresponding RRSIG on a RR deletion.
> 
> Best regards,
>  Matthijs
> 
> 
>> Fred
>> ___
>> 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

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

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Matthijs Mekking]

Hi Frederico,

On 03/29/2018 08:45 PM, Frederico A C Neves wrote:

I was looking at our server to evaluate the MIXFR implementation and
it seams to me that the current text covering dnssec aware client
logic don't take in account that a posterior record at the addition
section, by an MIXFR DNSSEC aware server, will implicitly replace the
RRSIG RRset.


I am unclear what case you are covering.



Logic could be simplified only to Deletions of RRs, when they conclude
a removal of a RRset, or RRsets by itself.


No, also if there is an RR addition, it means the RRset has changed, so 
existing RRSIG records can be implicitly removed.




All the other cases, addition or replacement, will be covered
automatically by an addition or replace of a RRSIG RRset. There is no
need to extra client logic to remove RRSIG, at addition of a RR, and
at deletion of a RR if it not remove the RRset.


Note there is no such thing as an RRSIG RRset. I tried to clarify this 
in the terminology bis document:


  https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html

Note that adding an RRSIG is different than replacing an RRSIG.



This is documented as issue #10 and includes proposed text.

https://github.com/matje/mixfr/issues/10


I think it makes more sense to keep the text as is, that is when 
changing an RRset implicitly remove the corresponding RRSIG records. I 
am opposed to only removing corresponding RRSIG on a RR deletion.


Best regards,
  Matthijs




Fred

___
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] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Martin Thomson]

If I understand your response (not sure that I do), that seems pretty
academic and not at all persuasive.  For instance, if a client cared
about testing TCP capabilities, it can always do its own resolution.

On Tue, Apr 3, 2018 at 7:44 PM, Davey Song  wrote:
>
>
> On 3 April 2018 at 15:33, Martin Thomson  wrote:
>>
>> This is intended to do what?  Indicate where the response came from?
>> Why does the client care?
>
> To keep the proxy (API client and server) transparent and bypass the
> middlebox along the path. Without the indicate, the API server has no clue
> what transport the client use (or would like to use. because there maybe
> cases that client would like to test TCP capablity of the far end resolver,
> I don't know). If no such indicate, It is either always using UDP or TCP by
> default (or by local configuration). It can be done as an choice for
> software implementation, but for protocol design IMHO, a indicate should be
> introduced to provide that information.
>
>>
>> I assume that it doesn't apply to requests,
>> or that would get into draft-bellis-dnsop-xpf territory.
>
> That's is the quesion whether the indicate should be carried in HTTP layer
> or DNS layer. If we use HTTP as a tranparent tunnel without any modification
> on upper layer message, I would prefer to use a HTTP indicate.
>
>>
>> BTW, you really need to drop UDP from the media type name now.
>> application/dns-udpwireformat;original_transport=tcp is a bit of a
>> contradiction.
>
>
> I agree.  I find no harm defining a media type "application/dns-wireformat"
> for DOH.
>
> Davey
>

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

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Davey Song]

On 3 April 2018 at 15:33, Martin Thomson  wrote:

> This is intended to do what?  Indicate where the response came from?
> Why does the client care?

To keep the proxy (API client and server) transparent and bypass the
middlebox along the path. Without the indicate, the API server has no clue
what transport the client use (or would like to use. because there maybe
cases that client would like to test TCP capablity of the far end resolver,
I don't know). If no such indicate, It is either always using UDP or TCP by
default (or by local configuration). It can be done as an choice for
software implementation, but for protocol design IMHO, a indicate should be
introduced to provide that information.


> I assume that it doesn't apply to requests,
> or that would get into draft-bellis-dnsop-xpf territory.
>
That's is the quesion whether the indicate should be carried in HTTP layer
or DNS layer. If we use HTTP as a tranparent tunnel without any
modification on upper layer message, I would prefer to use a HTTP indicate.


> BTW, you really need to drop UDP from the media type name now.
> application/dns-udpwireformat;original_transport=tcp is a bit of a
> contradiction.


I agree.  I find no harm defining a media type "application/dns-wireformat"
for DOH.

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Geoff Huston]

> On 3 Apr 2018, at 5:38 pm, Mark Andrews  wrote:
> 
> AD is only set or potentially set in the response if DO or AD is set on the 
> query.
> 
> The condition boils down to testing for AD or DO in the query because the 
> answer needs to be secure and there can’t be a CNAME or DNAME pointing to it. 
>  About the only way it to not have a AD would be for there to be a CNAME and 
> the target be insecure based on the other conditions.
> 
> I would just remove the condition. 
> 

Thanks Mark. 

I had just posted a followup before seeing your response.

I’ll remove the condition then.


Geoff





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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Geoff Huston]

> On 3 Apr 2018, at 4:39 pm, Geoff Huston  wrote:
> 
> 
> 
>> On 3 Apr 2018, at 1:10 pm, Mark Andrews  wrote:
>> 
>> Do we really want to test for AD?  How many stub resolvers set DO or AD to 
>> elicit a AD response?
>> 
> 
> I’m not sure that we are on the same page here. The precondition is: "The AD 
> bit is to be set in the response”  i.e. it is not a test on the query per se 
> - it is a test on the response. Your comment appears to suggest that you 
> believe that the text is asking for a test on the query. That is definitely 
> not the intention of the text. i.e. it does not attempt to say what 
> combination of flags in the query is used to signal that validation is to be 
> applied (thats the role of RFC4035 and RFC6840), but the text is attempting 
> to say “if the resolver has validated the response and is passing back a 
> response that it is marking as being valid” then perform 
> 
> I felt that saying that:
> 
>   o  The DNS response is DNSSEC validated
> 
>   o  the result of validation is "Secure"
> 
>   o  the AD bit is to be set in the response
> 
> would encompass this state. 
> 
> Is there a better way of saying this? Please suggest text if you believe that 
> this could be stated more accurately.


heh - the more I read the DNSSEC RFCs the more confused I get!

After further reading I now suspect that Mark is right, and the 
AD bit test is _not_ what is wanted.

Section 3.2.3 of RFC4035  reads

3.2.3.  The AD Bit


   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer and Authority sections of the response to be
   authentic.  The name server side SHOULD set the AD bit if and only if
   the resolver side considers all RRsets in the Answer section and any
   relevant negative response RRs in the Authority section to be
   authentic. 


So this text is saying that the AD bit is set if the resolver considers all
RRsets in the Answer section to be authentic. Fair enough.


But Section 5.8 of RFC 6840  reads:

5.8.  Setting the AD Bit on Replies

   Section 3.2.3 of [RFC4035] describes under which conditions a
   validating resolver should set or clear the AD bit in a response.  In
   order to interoperate with legacy stub resolvers and middleboxes that
   neither understand nor ignore the AD bit, validating resolvers SHOULD
   only set the AD bit when a response both meets the conditions listed
   in Section 3.2.3 of [RFC4035], and the request contained either a set
   DO bit or a set AD bit.

which appears to be saying that the AD bit is only set of the request contained
either a set DO ot a set AD bit.

What happens when neither DO nor AD is set in the request? 

Do you get a response that is authentic (but without any explicit signalling
in the response  that would indicate that authentication has occurred) or the
Servfail response in the case where authentication fails?

Or do you get a response that is not necessarily authenticated even though
the CD bit is not set?

If its the former then the AD bit may or may not be set on responses even though
they have been "DNSSEC validated”








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

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ray Bellis]

On 03/04/2018 08:33, Martin Thomson wrote:
> This is intended to do what?  Indicate where the response came from? 
> Why does the client care?  I assume that it doesn't apply to
> requests, or that would get into draft-bellis-dnsop-xpf territory.

I think there's some overlap here, if the intent of the
'original_transport' field is to allow a server to make policy decisions
(e.g. truncation, RRL etc) based on that value.

However, my XPF co-authors and I think that a simple transport protocol
value is no longer sufficient for this.  In practise the servers don't
care about the *actual* transport, but instead care about the
meta-properties of that transport, i.e. "is it unspoofable", "does it
support large packets", "is it encrypted" ?

In "old" DNS the use of a single flag indicating "udp" or "tcp" was an
adequate proxy for those meta-properties, but now with DNS-over-TLS,
Cookies, etc, it won't do.

Ray

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Mark Andrews]

AD is only set or potentially set in the response if DO or AD is set on the 
query.

The condition boils down to testing for AD or DO in the query because the 
answer needs to be secure and there can’t be a CNAME or DNAME pointing to it.  
About the only way it to not have a AD would be for there to be a CNAME and the 
target be insecure based on the other conditions.

I would just remove the condition. 

-- 
Mark Andrews

> On 3 Apr 2018, at 16:39, Geoff Huston  wrote:
> 
> 
> 
>> On 3 Apr 2018, at 1:10 pm, Mark Andrews  wrote:
>> 
>> Do we really want to test for AD?  How many stub resolvers set DO or AD to 
>> elicit a AD response?
>> 
> 
> I’m not sure that we are on the same page here. The precondition is: "The AD 
> bit is to be set in the response”  i.e. it is not a test on the query per se 
> - it is a test on the response. Your comment appears to suggest that you 
> believe that the text is asking for a test on the query. That is definitely 
> not the intention of the text. i.e. it does not attempt to say what 
> combination of flags in the query is used to signal that validation is to be 
> applied (thats the role of RFC4035 and RFC6840), but the text is attempting 
> to say “if the resolver has validated the response and is passing back a 
> response that it is marking as being valid” then perform 
> 
> I felt that saying that:
> 
>   o  The DNS response is DNSSEC validated
> 
>   o  the result of validation is "Secure"
> 
>   o  the AD bit is to be set in the response
> 
> would encompass this state. 
> 
> Is there a better way of saying this? Please suggest text if you believe that 
> this could be stated more accurately.
> 
> thanks,
> 
>   Geoff
> 
> 
> 

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

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Martin Thomson]

This is intended to do what?  Indicate where the response came from?
Why does the client care?  I assume that it doesn't apply to requests,
or that would get into draft-bellis-dnsop-xpf territory.

BTW, you really need to drop UDP from the media type name now.
application/dns-udpwireformat;original_transport=tcp is a bit of a
contradiction.

On Mon, Mar 26, 2018 at 4:48 PM, Paul Hoffman  wrote:
> Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining a new 
> media type seems like overkill, particularly given that it will be 
> transporting *the exact same* data as an existing media type. Instead, an 
> optional parameter could be added to the application/dns-udpwireformat 
> registration in the DOH document.
>
> Proposal:
>
> =
>
> In the media type definition, change "Optional parameters" to:
>
> Optional parameters: original_transport
>original_transport has two defined values, "udp" and "tcp".
>This is only expected to be used by servers.
>
> Also in the the DOH document, under Operational Considerations, we would add:
>
> This protocol does not define any use for the original_transport optional
> parameter of the application/dns-udpwireformat media type.
>
> =
>
> Then draft-ietf-dnsop-dns-wireformat-http could define the use of that 
> optional parameter as it sees fit.
>
> --Paul Hoffman
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

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

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Geoff Huston]

> On 3 Apr 2018, at 1:10 pm, Mark Andrews  wrote:
> 
> Do we really want to test for AD?  How many stub resolvers set DO or AD to 
> elicit a AD response?
> 

I’m not sure that we are on the same page here. The precondition is: "The AD 
bit is to be set in the response”  i.e. it is not a test on the query per se - 
it is a test on the response. Your comment appears to suggest that you believe 
that the text is asking for a test on the query. That is definitely not the 
intention of the text. i.e. it does not attempt to say what combination of 
flags in the query is used to signal that validation is to be applied (thats 
the role of RFC4035 and RFC6840), but the text is attempting to say “if the 
resolver has validated the response and is passing back a response that it is 
marking as being valid” then perform 

I felt that saying that:

   o  The DNS response is DNSSEC validated

   o  the result of validation is "Secure"

   o  the AD bit is to be set in the response

would encompass this state. 

Is there a better way of saying this? Please suggest text if you believe that 
this could be stated more accurately.

thanks,

   Geoff



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