Subject: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-key-tag-04: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 15 Feb 2017 18:14:44 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-key-tag-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- abstract: referring to section 1.1 from here seems wrong,
the abstract ought be readable by itself

- section 5: Is the key tag query only and solely intended to
allow the authoritative to track how clients are paying
attention (or not) to key rollovers? If there's another
purpose I'm not clear about it.

- 5.3: "I believe that to be..." seems like the wrong language
to use with >1 author.

- section 7/8: Is there a missing security/privacy
consideration here, in that an authoritative server here could
arrange to hand out key tags that are specific to (in the
limit) each query, so that when the resolver queries a
sub-domain, and thereafter, the client will be identifiable to
the authoritative server?  One could do this by generating new
keys per querier so that if I ask about example.com I get
given a tag that's unique to me, and then some web content
pushes me to ask about www.example.com and every time I do
that I emit that user-specific key tag. While that'd be
unlikely for a large zone, it might be feasible as a tracker
if some "bad" domain sets up a specific subdomain for such
purposes. That said, I'm not clear how much better this is for
the attacker compared to simply using a tracking name in the
authority component of the URL for e.g. some 1x1 gif.

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 16 Feb 2017 21:43:22 +0000

Hi Stephen,

Agreed. I propose to remove that sentence and let the abstract stand on its own.

> purpose I'm not clear about it.

Yes, that is the sole purpose.  Do you think this needs to be made more explicit?

> - 5.3: "I believe that to be..." seems like the wrong language

Yes.  This sentence was already removed from the authors' shared source file shortly after -04 was sent out.

> authority component of the URL for e.g. some 1x1 gif.

One important aspect to clarify here is that resolver shouldn't be transmitting the key tags for every query.  They are only to be sent with or at the same time as DNSKEY queries.

4.2 says that the edns-key-tag option MUST NOT be sent for non-DNSKEY queries.

5.2 says the need to issue a DNSKEY query is also the trigger to issue a key tag query.

Additionally, the document says that resolvers SHOULD transmit the key tags for zones with configured trust anchors and MAY do so for non-trust anchor zones.  For most resolvers only the root zone would be configured as a trust anchor.

Lastly, there is a practical limitation here in that each unique key given out would require a corresponding unique DS record in the parent zone.  A malicious zone operator might be able to get away with tens of unique keys, but probably not hundreds.  The one exception to this would be if the malicious actor operated both a parent zone and a child zone.

Given all that, do you think it warrants a paragraph in the privacy section?

DW

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Feb 2017 01:10:23 +0000

Hiya,

>> - section 5: Is the key tag query only and solely intended to allow
>> the authoritative to track how clients are paying attention (or
>> not) to key rollovers? If there's another purpose I'm not clear
>> about it.
> 

Up to you. It wasn't clear to me at first, but was clear
when I finished reading.

> 
> 
>> 
>> - 5.3: "I believe that to be..." seems like the wrong language to
>> use with >1 author.
> 
> Yes.  This sentence was already removed from the authors' shared
> source file shortly after -04 was sent out.
> 
>> 
>> - section 7/8: Is there a missing security/privacy consideration
>> here, in that an authoritative server here could arrange to hand
>> out key tags that are specific to (in the limit) each query, so
>> that when the resolver queries a sub-domain, and thereafter, the
>> client will be identifiable to the authoritative server?  One could
>> do this by generating new keys per querier so that if I ask about
>> example.com I get given a tag that's unique to me, and then some
>> web content pushes me to ask about www.example.com and every time I
>> do that I emit that user-specific key tag. While that'd be unlikely
>> for a large zone, it might be feasible as a tracker if some "bad"
>> domain sets up a specific subdomain for such purposes. That said,
>> I'm not clear how much better this is for the attacker compared to
>> simply using a tracking name in the authority component of the URL
>> for e.g. some 1x1 gif.
> 
> One important aspect to clarify here is that resolver shouldn't be
> transmitting the key tags for every query.  They are only to be sent
> with or at the same time as DNSKEY queries.
> 
> Additionally, the document says that resolvers SHOULD transmit the
> key tags for zones with configured trust anchors and MAY do so for
> non-trust anchor zones.  For most resolvers only the root zone would
> be configured as a trust anchor.
> 
> Lastly, there is a practical limitation here in that each unique key
> given out would require a corresponding unique DS record in the
> parent zone.  A malicious zone operator might be able to get away
> with tens of unique keys, but probably not hundreds.  The one
> exception to this would be if the malicious actor operated both a
> parent zone and a child zone.
> 

Again, up to you. The issue is fairly borderline so I won't
argue if you don't wanna.

S.