On Tue, 2004-11-30 at 23:08, william(at)elan.net wrote:
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 can imagine a list of headers to support a channel-signature (used to
assign access accountability).
1) channel-signature
2) message-state
3) pass-through-verification
4) mda-verification
If the message passes through a list-server that does not handle
channel-signatures, then the optional message-state header could be used
to evaluate the cause for the signature failure. What gets rejected or
displayed upon a signature failure becomes a local policy decision,
likely handled by automated message analysis. For initial deployment,
the robustness of the signature may not be adequate to allow message
rejection based upon a signature failure. The message-state header
could act as an interim amendment to help alleviate this problem. This
message-state header would be a separate draft from the implementation
of the channel-signature, but added before the channel-signature.
A pass-through-verification header could be utilized by a list-server to
indicate the verifications that were completed upon accepting the
message. This pass-through-verification header replaces or is done in
conjunction with the header normally generated by the MDA, being the
mda-verification header. Perhaps the normal mode would be to have the
MSA convert mda-verification headers into pass-through-verification
headers. Both of these headers should share a common format and should
include the type and location of the authorization information used for
validations. There should not be an mda-validation header seen within a
message by an Internet-facing MTA and should be cause for rejection.
As time passes, the use of the message-state header could be depreciated
but, if it exists, it would be included within the message signature.
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 receipient.
Having a greater amount of channel-signature overhead contained within
the TCP transport puts less stress on the network. By also having the
public-key contained within the message, there is only a need to obtain
authorization which can be done in parallel with the signature
validation process. Regardless as to how it is done, out-of-channel
information will need to be cached. Requiring less information for this
function, as with IIM, has value and is independent of the public
signature size.
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...)
My concern was with respect to using this mechanism to establish a
security model. Using DNS to distribute the public-key never exceeds
the integrity of the underlying IP infrastructure. By using an HTTPS
server for authorization and putting the public-key within the channel,
the dependence upon IP integrity is removed (assuming the
mda-verification header is utilized). The approach taken by IIM seems
to lend itself to such an improved security model when needed. There is
an emerging problem this can address, where the DK approach does not.
My concern is with respect to investing in the use of DNS to distribute
public-keys ahead of DNSSEC.
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 must admit that I have not had time to review your proposal. I will
do so shortly.
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.
Yes.
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.
Departure from the SRV record to accommodate HTTP directories was not
thrilling. I would rather see a dedicated directory with a parameter
used on the query instead. This would keep this information more static
and recognizable. Perhaps the DNS lookup could include the _smtp
sub-domain carved out by CSV to elude the MS time-out problem.
Offering well defined passive information using a specific label that
does not require indeterminate subsequent lookups is much less onerous.
-Doug