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

[Stefan Winter <[e-mail]>]

Hi,

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

After more feedback in anothe thread, I've refined the text even more. I
believe we are getting somewhere now :-)

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

I've added more text which suggests rate-limiting (but want to leave the
details to implementations).

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

There's actually a better place for this: the S-NAPTR RFC requires me to
wreite a section on "Server Identification and Handshake" anyway.

My current working copy has text to explain why TLS-PSK is bad, suggests
the NAIRealm certificate property (MTI), and has a non-MTI explanation
of what we do in eduroam.

As I thought more about DANE, I think we were actually a bit unfair: the
algorithm discovers a /server/. The identification and handshake
therefore only need to deal with server identification.

It's true that the contacted RADIUS server at some point also has to
make a determination whether it wants to talk to the RADIUS client, but
this doesn't have to be determined on the same grounds as the
server-side identification.

That's actually the same as with NAIRealm: this (MTI!) mechanism only
takes one through the server-side identification, the client auth is
left unspec'ed.

In that light, I think it's fair to add DNSSEC+DANE as one of the
mechanisms. I've added stub text about it; if there is sufficient
interest in the topic then this can be expanded.

I've added a remark that the discovery spec only concerns itself with
the server-side identification.

Greetings,

Stefan Winter

> 
> 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
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]