Let me clarify/correct a couple of things here...
Andre Grueneberg wrote:
>
> Edgar Lovecraft wrote:
> > > 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),
>
> The draft states that 119 Bytes is a limit for some stupid DNS caches.
> The next limit is that of traditional DNS over UDP, which is 512 octets
> per packet -- EDNS0 [RFC2671] extends this limit. After that we'll have
> to stick to TCP DNS, which is aweful.
I would agree, 119/127 is a bad limit.
> > As for the single TXT record length, they suggest under 127, but bind
> > will take up to 255 (RFC max I believe),
>
> No, I don't see a limit for TXT-DATA besides of RDLENGTH being an 16bit
> integer and that of transport protocols. For practical reasons, let's
> assume 255 octets a limit. Some bytes overhead (those flags defined) --
> let's take 230 Bytes available for key data. Which is ascii armored,
> resulting in a size decrease to 6/8 or 172 Bytes or 1376 bits. So one
> might be able to use 1024 bit keys -- with 119 octets, the practical
> maximum is at 512 bits, which doesn't hold for months.
After doing some extra research into the matter the limit of 255 or 127
Bytes appear to be the limits of a single TXT record string return value,
(I will explain a little better below), not the size limit of a TXT record
which I have not found an RFC limit to, however Bind 4.8 and up should
hold at the very minimum nearly 2k or more for a single TXT record in the
zone db files. Bind then seperates the return into 255 byte chunks
during the return. (I have done no analisys for TCP vs. UDP here, just
some basic testing)
>
> > 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..."
This is were I will claim the 'not enough caffine defense' :P
Actually I was just not thinking about it and used improper information,
based partly on not using the TXT RR very often and not double checking
the relevant RFC's before posting... oh well, we all make mistakes...
> At least me, I read "single TXT record" a bit different than you do.
> Ever thought about round-robin DNS? The draft states that multiple TXT
> records for one name would lead to undefined operation.
>
Fred Viles wrote (about the same section above):
>
> That is not a single TXT record, that is three TXT records. You
> can't rely on them being returned in any particular order, DNS
> doesn't work that way.
As Fred and you pointed out, that was multiple TXT records, however I did
some more testing and this is what I found.
Going back to what you thought the practical size would be, I would
disagree, and here is why.
The proper "Single" TXT record for a private key modulus of 10240
would be this (for what I generated as per the RFC draft examples),
this was done on BIND 8.2.3 and BIND 9.2.1
----this goes into a Bind zone file----
;
; TXT record examples
;
brisbane._domainkey IN TXT "g=; k=rsa; p=MII..<1788 Chars>..AQ=="
----Dig Output----
;; QUERY SECTION:
;; brisbane._domainkey.example.com, type = TXT, class = IN
;; ANSWER SECTION:
brisbane._domainkey.example.com. 1D IN TXT "g=; k=rsa; p=MII...77"
"d7Y...yEL" "PMb...Abl" "lBq...BXl" "XLB...Wnz" "ri4...8gP" "BeO...Q=="
If you notice, BIND has broken up the string in a list of strings
(were I goobered up my previous example this morning) of a single
TXT record. So all in all, my previous statment of limiting the
key modulus size is still relevant, as very large keys can be used,
and can be sent through common DNS implementations.
All done at the prompt:
openssl genrsa -out rsa.private 10240
openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
openssl dgst -sign rsa.private -sha1 <singlemessage | \
perl -MMIME::Base64 -0777 -ne 'print encode_base64($_)' | \
sed -e '1s/^/b=/' -e 's/^/ /' >for-message-header
sizes of generated files:
7923 rsa.private << Used for signing >>
1840 rsa.public << Put into DNS TXT RR >>
1756 for-message-header << Put into message header >>
(The single message was on old email of 14202, this is the same file
as used in the time testing)
--
--EAL--
