Matthew Byng-Maddick wrote:
>
..[snip]...
>
> The use of 384-bit keys worries me, especially following his claim about
> authentication of the domain.
That was a poor example I think. I did some testing though on a dual p4
2.3Ghz with 1.5G RAM, signing 14K messages, at the 384-bit level time was
0.001s per message, at a 1024-bit key, this jumped to 0.015s per message.
(Time as reported by 'time <command>' on a linux console). Also, the key
size is determined by the domain, it is not stuck at 384-bits (at least
that is not defined in the current draft), it can be as large as you want
(DNS TXT record size seems to be the limit here), so just for fun i
generated a 10240-bit key (that took forever!) and signed the same 14k
message with that key, 12.381s! I suppose if someone where to be
particularly obnoxious, they could just use a very large key and presign
a bunch o' messages, and then send them all to the same server, or server
farm. I don't think it would be too hard for DoS attack if the key length
is not kept at a 'resonable' level...
That is a rather silly example, but it is something to think about.
> I'm going to reserve judgement on most of it (apart from the
> show-stopper above) for the moment.
>
I did agree, until I increased the key size and thought about it a bit
more. This thing really needs to be thought out more as to the technical
implementations/ramifications.
As for the single TXT record length, they suggest under 127, but bind will
take up to 255 (RFC max I believe), but you can return multiple strings for
each TXT record and from the DomainKeys draft:
"Within a single TXT record, implementors should concatenate multiple
strings in the order presented and ignore string boundaries."
example (in BIND format anyway):
example.com IN TXT "this would be line one"
IN TXT "this would be line two"
IN TXT "so on and so forth..."
Hmm, large keys and DoS here we come :)
--
--EAL--
