On Tue, 30 Nov 2004, Douglas Otis wrote:
I would not be happy to see this information removed. I find it useful
at times. I would not expect to have an MUA able to highlight what
should be trusted any time soon. This is not a simple issue however.
Its pretty simple issue - you offer signer an ability to decide if
he/she/it wants the signature to survive with alterations (and possibly
this adds slight chance of the message being reused by spammer, which
will result in abuse reports) or if signer wants signature that will
fail if email is altered but is more secure.
Now, my guess is that right now we need signatures that can survive
alterations but once enough mail list servers and other intermediate
systems signing, we may well begin to slowly change to more secure
signatures. What is important is to make the change easy for signer
- as easy as a check box on configuration screen or one line in
.conf file and that we can do with option of either adding number
of characters (after canonicalization) as part of siganture or not
doing it. But this option MUST be available as part of the protocol.
I do like the method used in IIM with respect to where the burden is
placed. This can be seen as a separate issue however.
Could you elaborate what you mean by "burden" in above? Because
in regards to burden both IIM and DK and most other systems (except
possibly SES) are pretty similar - the cryptography is left to
the recepient.
Is an unprotected DNS server a reasonable approach for public key
distribution? Does DNSSEC offer a solution?
I talked to couple dns people at last IETF and then more on IPv6 summit,
let me just mention that they are somewhat pessemistic about widespread
deployment of DNSSEC in the near-future. In fact it seems to me IPSec
being deployed with IPv6 may have slightly more deployment momentum
right now (which is not to say its going all that well for ipsec either...)
IIM provides the public key within the message and, for those that wish
better protection, perhaps could employ the use of HTTPS for the
authorization step. The IIM draft calls for HTTP.
META Signatures allow to do fingerprint authorization with HTTPS, it'll
become even more clear with next version of META-Auth headers that use
URLs for location data. I would however mention that use of HTTPS will
likely mean slower authentication, i.e. its goes like this from quickest
to slowest:
1. UDP data lookup where data is < 512 bytes
2. TCP lookup with one immediate data retrieval (immediatly get the data
as soon as TCP session is ready).
3. TCP session that requires additional session/protocol connection
negotiation (such as with SSL).
I also would like to note that DNS is great database system for small
pieces of data and in that case using dns with fingerprints (which are
a lot smaller then full public key) may well offer great benefits in
terms of lookup performance.
The question of establishing a public key distribution system via DNS
has the prospect of fostering other uses. This raises the question, do
we want to do this?
That has been discussed so many times...
But going back to it again, it maybe interesting to think how use of DNS
and public keys that go with DNSSEC can help us or how we can possibly
help DNSSEC. There are shared areas of interest including DNS record
syntax, programming to automated key distribution/creation, etc.
But I'll note that if we want to work together with dns people, it would
be good idea to do design in the way that they would approve of - and you
probably heard before what dns people think of using TXT records for things
related to email authentication.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net