Re: [radext] #148: Review of dynamic-discovery by Jim Schaad

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of radext issue tracker
> Sent: Wednesday, June 26, 2013 6:16 AM
> To: [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad
> 
> #148: Review of dynamic-discovery by Jim Schaad
> 
> 
> Comment (by [e-mail]):
> 
>  > 1) In section 2.3.3, step 4 - what is to be considered an error at this
point.
> For example, there are a number of odd conditions that can be  returned
> from DNSSEC, specifically the "indeterminate" state.
> 
>  I've added text in my working copy which white-lists two sorts of replies
as
> good, and everything else as an error. Hope that is adequate and  removes
> all ambiguity:
> 
>  "2.3.3.  Definitions
> 
>     Where the algorithm states "name resolution returns with an error",
>     this shall mean that either the DNS request timed out, or every
>     response except a) the RR queried for and b) the positive
>     acknowledgement that the record queried for does not exist (i.e.
>     status: NXDOMAIN)."

I wish I knew enough DNSSEC to say for sure, however this is a good step in
the right direction.

> 
>  > 2) In section 2.3.4 - Given that the above algorithm does not return a
TTL
> value in the event of an empty set or define how to know the TTL value
>  - what is the TTL value to be used in in paragraph 2 "negative TTL"?
> 
>  I'll have to modify the return value to be a tuple with the second
element
> being the place to put a negative TTL into (either as learned from an
> NXDOMAIN reply or configured in case of an absence of any reply). I'll
keep
> this TRAC ticket open for this sub-issue.
> 
>  > 3) In section 2.3.5 - Does it make sense to return a result, but to
continue
> the algorithm and store the result after the timeouts for later  use?
> 
>  We discussed this in the last meeting. It's generally a bad idea (end-
users
> can enter bogus DNS data and DoS the server by trying to login with
> corresponding realms). An implementation could be brave and do that
> anyway, so I've added text to Security Considerations explaining the
issues
> with it. Implementations can then do a judgment call whether they  want to
> take this risk. The text is:
> 
>  "   The algorithm has a fixed completion time-out of three seconds.
>     Implementations might be tempted to continue their attempt to resolve
>     DNS records even after the timeout has passed; a subsequent request
>     for the same realm might benefit from retrieving the results anyway.
>     Doing so exposes the server to a Denial-of-Service risk: an attacker
>     might intentionally craft bogus DNS zones which take a very long time
>     to reply (e.g. due to a particularly byzantine tree structure, or
>     artificial delays in responses).  If an attacker generates enough
>     Access-Requests for a number of such zones, it may deplete server
>     sockets or other server resources."

I am not sure that the DOS risk would be significantly larger between a 3
and a 6 second time out.  It would just require half as many requests.  A
better way of addressing the specific problem you have shown here would
involve black-listing of DNS queries and I don't see anything in this text
or the algorithm which talks about doing black listing of any type.


> 
>  > 4) I find the security considerations to be completely inadequate for
this
> document.
>  > Use of a certificate is only going to be valid if the original realm
name
> that is the input the validation routine is what is found and matched  in
the
> certificate.  In this case I would not know where in the name or  alt name
> fields of the certificate it would be found.  You cannot validate  to the
final
> DNS name as that is now an untrusted value.
> 
>  We discussed on the list that an MTI validation mechanism which works in
> the absence of DNSSEC is needed (sigh!). I'll work on corresponding text
> soon. I'll keep this TRAC ticket open until the text is ready.
> 
>  > The suggestion of out-of-band validation methods ignores the existence
> of DANE.
>  >
>  > The NAI document suggests that the RADIUS peer is pre-configured with
> information about certificates or TLS validation data.  The suggested text
> works in the case that the table says do dynamic lookup and here is the
TLS
> configuration data.  But in other cases it is completely unclear how a
TLS-
> PSK would be found for a dynamic lookup.
> 
>  These were both discussed on the list; DANE is clumsy/not usable in its
> current state; TLS-PSK is not in scope for this document.

Great  - please state this in the introduction material

Jim

> 
>  Greetings,
> 
>  Stefan Winter
> 
> --
> -------------------------------------+----------------------------------
> -------------------------------------+---
>  Reporter:                           |       Owner:  draft-ietf-radext-
>   [e-mail]           |  [e-mail]
>      Type:  defect                   |      Status:  new
>  Priority:  major                    |   Milestone:  milestone1
> Component:  dynamic-discovery        |     Version:  1.0
>  Severity:  -                        |  Resolution:
>  Keywords:                           |
> -------------------------------------+----------------------------------
> -------------------------------------+---
> 
> Ticket URL:
> <http://trac.tools.ietf.org/wg/radext/trac/ticket/148#comment:1>
> radext <http://tools.ietf.org/radext/>
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext