Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt

[Mark Nottingham <[e-mail]>]

Diff URL for the curious:
  http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://www.ietf.org/id/draft-ietf-dnsop-onion-tld-00.txt&url2=http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt

Cheers,


> On 2 Sep 2015, at 9:55 am, Mark Nottingham <[e-mail]> wrote:
> 
> See:
>  https://github.com/mnot/I-D/commit/f9975381389d556709cfe77a520eae73ace0659c
>  https://github.com/mnot/I-D/commit/cb43f69aa37f94baeb78aa3eca368dd712a06154
> Do they suffice?
> 
> The references were flipped to normative here:
>  https://github.com/mnot/I-D/commit/8486c73357b0421c013a6e99e90374c54190ce36
> 
> With all changes to date incorporated:
>  http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt
>  http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.html
> 
> Cheers,
> 
>> On 2 Sep 2015, at 12:07 am, Kathleen Moriarty <[e-mail]> wrote:
>> 
>> On Tue, Sep 1, 2015 at 9:58 AM, Christian Huitema <[e-mail]> wrote:
>>> On Tuesday, September 1, 2015 4:37 AM, Kathleen Moriarty wrote:
>>>> 
>>>> I still have the outstanding question on security properties that may be buried
>>>> in this thread.
>>> 
>>> The question was, how could malicious DNS agents trick TOR clients into disclosing their presence. The recent exchange with Mark was about such agents passively listening for clients' mistakes. Is there a way to actively trigger such mistakes?
>>> 
>>> Such attacks would require actively sending information to clients, such as "if you have a request for example.onion, send it to me." The way to do that in the DNS is through NS records. Malicious agents could send an NS record for ".onion" as additional record in a response, asking resolvers to send them such traffic. This might trick legacy clients. Maybe.
>>> 
>>> -- Christian Huitema
>>> 
>>> 
>>> 
>> 
>> My outstanding question is in my message from Aug 30th on Section 2
>> text that I think needs further clarification since the first bullet
>> makes a broad statement without naming the security properties people
>> are supposed to recognize.  Here is the snippet from that message
>> (similar to a point made by Alvaro as well):
>> 
>>> That would seem doable, if something sufficiently brief can be constructed,
>>> because much of the actual mechanism which should lead to the desired
>>> behaviour is described in Section 2 of the draft, the elements of which are
>>> heavily modeled upon the examples provided in RFC6761.
>>> 
>> 
>> It's fine to have them in section 2.  When I read through them again,
>> what are the special security properties that users and applications
>> should recognize that are mentioned in the first bullet?  Are these
>> properties provided through the subsequent bullets handling
>> requirements?  I'm guessing that's the case, but since they are not
>> sub-bullets, I'm not sure.
>> 
>> It would be good to clarify this text to list the properties and to
>> see how the first bullet relates to the subsequent bullets.
>> -- 
>> 
>> Best regards,
>> Kathleen
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 

--
Mark Nottingham   https://www.mnot.net/