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

[Mark Nottingham <[e-mail]>]

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/