Re: [dnsext] comments on draft-crocker-dnssec-algo-signal-03

[Michael Graff <[e-mail]>]

I remain unconvinced that tcp is evil.

Re secspider yes it is not as useful. It measures probed algorithms  
not reported ability to use algorithms.

--Michael


On Jul 30, 2009, at 14:29, Eric Osterweil <[e-mail]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Jul 29, 2009, at 12:56 PM, Michael Graff wrote:
>
>> Let me state some reasons I'm opposed to this draft's purpose, even  
>> though I think some part of it would be very interesting to pursue.
>>
>> (1)  This becomes a meta-type in practice.  It might prevent some  
>> lookups initially, but should a client ask for items that were not  
>> in the cache, the server would have to remember which algorithms it  
>> saw in the DNSKEY response to know which it could usefully retrieve  
>> with follow-on queries.  For example, a particular stub might  
>> support more algorithms than the cache it asks, so additional  
>> queries (including additional queries for the DNSKEY to obtain its  
>> signatures) would have to be generated.
>>
>> (2)  This solves a problem I do not fully believe is a problem,  
>> that of TCP fallback.  I've said it before, but chat servers, web  
>> servers, and other types of TCP-based servers handle many, many  
>> connections/sec and many, many sustained clients today.  I don't  
>> understand why DNS is different here, excepting perhaps that we  
>> have not encountered this situation until now.
>>
>> (3)  It solves a problem that I do not fully believe is a problem,  
>> that of fragmented packets.  There is no solid solution in this  
>> proposal that it WILL get packets through, only that it might have  
>> a better chance to do so.  Key rollover will still cause large  
>> packets and/or TCP fallback, which means only during rollover  
>> events will badness occur.  I'd rather it occur all the time rather  
>> than only in some situations.
>
> So, I don't completely understand this.  The PMTU problem is  
> actually observable, so why are you saying it doesn't exist?  There  
> are numerous zones for which this can be seen.  Also, I think it is  
> important to note that a TC bit is commonly interpreted to mean, "do  
> TCP now."  However, this does not need to be the case, and RFC 2671  
> does not advocate that approach either.
>
> Maybe before this descends too quickly, would you mind clarifying  
> why you don't believe it is a problem?
>
>>
>>
>> (4)  I believe the knowledge it would allow to be gathered -- that  
>> of which algorithms, hashes, etc. were in common use -- is very  
>> valuable. Perhaps a draft on "voluntary reporting of server  
>> capabilities" would be useful, where the data would be anonymous,  
>> infrequently (order days at least) reported, and collected into  
>> reports.  Knowing that RSA/SHA1 is not used any longer is very good  
>> information to know in terms of deprecating protocols, but using  
>> that as a filter seems unwise to me.
>
> fwiw, this is available on the front page of:
>    http://secspider.cs.ucla.edu/
> under "Distribution of key algorithms in use."  Is that not a  
> sufficient summary?
>
> Eric
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (Darwin)
>
> iEYEARECAAYFAkpxkisACgkQK/tq6CJjZQKB/ACeN6aqvjcsBEFOKaPaf2m3ioXO
> dIMAoIOR7rwumf5N6oE/TSmSb4IoA+qt
> =r7Ia
> -----END PGP SIGNATURE-----

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>