william(at)elan.net wrote:
On Wed, 26 Oct 2005, Stephen Farrell wrote:
That I think is a fair enough point and worth discussing. (As might
be whether or not to allow an option for public keys to be included
with signatures.)
Please do (discuss it at the very least).
OTOH it seems that there should be a benefit to
using DNS to move the keys and policy data if its done well, since
it does provide a somewhat out-of-band channel (generally good in
security) as well as potential ways to choke back on misbehaviour
(which can be both good and dangerous).
Out-band channel makes one system dependent more heavily on another
system, which means the security strength of total system is cumulative
and thus smaller then either one.
Every use of crypto depends to some extent on an out of band
channel to distribute some "more trusted" infotrmation. That channel
could be the mail I got a while ago, stuff from DNS, (as here),
a smartcard delivered by courier or lots of other things. So having
some out-of-band-ness is required and good.
Your point about more dependencies meaning less security is fair
enough but I wouldn't agree that security is "cumulative" since
the weakest link is where you'll get attacks, and that weak link
could be anywhere. Anyway we shouldn't get hung up on this.
Besides do note that no matter how you do you end-up having to move the
same data - you just rearranged who does it moving it off your
[protocol] back to someone else's - this is not at all nice behavior and
result of DKIM could be increase of size of data carried by dns by 100%
or more.
So in this case you also have to consider if where you moved it to is a
system well suited for moving such data and how much of a problem it
could be and from what we know so far DNS really works very well with
small constant size data pieces as its database values but is not very
good when such data is large and comes close to its UDP limit.
I didn't get all of that, but I guess the point is that we need to
ensure that whatever we require from DNS doesn't break the limits of
what works in the real world. I'm sure that's understood.
Additionally note that security depends on size of public key used
and if attacks on pki protocols continue and with increase of Moore's
low predicted computing resources, we'd end-up having to increase size
of public keys and you're already at the limit with DNS with current
size and little or no way to do it further.
Well, each additional bit of RSA modulus does add a lot of work for
the attacker if they're factoring, so there's no a-priori need to
jump from 1024 to 2048. (OTOH 1025 bit keys can be worse than 1034
bit keys against some side-channel attacks if I remember right, so
we can't just pick any length at all.)
A much better approach is to put always small and fixed-size value of
fingerprints in dns and let public keys be handled together with other
mail data as SMTP is already designed for moving significant amounts
of data and this increase would not have any major impact on it.
I'm kind of sympathetic to making the data we need in DNS be fixed
size to the extent we can, but of course you've now introduced
a new use of a hash algorithm and those aren't currently the flavour
of the month, especially when what you're hashing is random looking
stuff like public keys, so doing that would have to be done very
carefully.
Note also that this doesn't get you up to "2048 bit security",
since you're now dependent on the collision resistence of the
hash function which won't change no matter how long an RSA modulus
you need for signature verification.
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org