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

[Stephen Farrell <[e-mail]>]

Hiya,

On 16/02/17 21:43, Wessels, Duane wrote:
> 
> Hi Stephen,
> 
> 
>> 
>> ----------------------------------------------------------------------
>>
>> 
COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>>
>> 
- abstract: referring to section 1.1 from here seems wrong,
>> the abstract ought be readable by itself
> 
> Agreed. I propose to remove that sentence and let the abstract stand
> on its own.
> 
> 
>> 
>> - 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.
> 
> Yes, that is the sole purpose.  Do you think this needs to be made
> more explicit?

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

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

S.


> 
> 
> DW
>