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

[Eric Osterweil <[e-mail]>]

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