HELO validation in the style of CSV using SPF records for data may be a very
effective and useful compliment to MASS.
At this stage the idea of suggesting deployment of a new syntax for SPF is
dangerous, ill conceived and if endorsed would bring the IETF into
widespread contempt. It is not responsible for an Internet standards body to
refuse to endorse a standard that has established real grass roots and
industry momentum and then endorse another standard that has no support and
no deployment instead.
I do not think that is going to happen.
The SPF people have added HELO checking as a validation option. There is
therefore no justification for continuing with CSV at this point.
-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
Douglas Otis
Sent: Friday, January 07, 2005 3:45 PM
Cc: ietf-mailsig
Subject: Re: Web pages for MASS effort
Dave,
I know it has been awhile and now William Leibzon has
introduced his pages, so I once again reviewed the mass site:
http://mipassoc.org/mass
Perhaps on the mass web page you could include a link to:
http://brandenburg.com/specifications/draft-crocker-mail-arch-01.html
together with William Leibzon's page at:
http://www.metasignatures.org/eglossary.htm
William's glossary of terms seems to be more crypto related
so there is little overlap.
There is a fair difference between terminology used in
different mail related forums. It would be good to be
consistent with some of these terms so these links could help.
There are things of merit in each approach and, as with any
engineering, considering the effect on resources should play
a role in this process.
It is not possible for a digital signature of a message to
provide network protection. Network resources are expended
regardless of the result of checking the signature, and then
perhaps checking their accreditation/reputation. CSV,
without exchanging keys or messages, brings an authenticated
name for asserting accreditation/reputation checks for
virtually the same name set as that provided by a MASS
solution (especially wrt DK). If to protect network
resources, CSV will be needed together with any MASS
solution. Network overhead regarding the two approaches
should be considered, so I'll refer back to Dave Crocker's
feature summary on the mass website.
Within the query section, the method of distributing the key
within the message has an advantage by using the SMTP TCP
transport to carry the public key and using DNS to reference
a fingerprint. The resulting TCP traffic burden with the
added public key placed within the message should increase
about 3%. There is a slight CPU overhead with respect
building the fingerprint.
In comparison, DK has a disadvantage as it places a larger
payload into the DNS record and related infrastructure. I
would expect having a slightly increased traffic flow within
SMTP/TCP (with congestion
avoidance) is preferable over passing more information using
DNS/UDP. There is some relief in caching the related public
keys using DNS and this may justify passing a greater load
through DNS/UDP. Looking at the breakdown of the burdens
placed upon TCP/UDP would be helpful in deciding where the
public key should be placed. There is already schemes using
the fingerprint approach, so some of this territory has
already been covered.
http://www.ietf.org/internet-drafts/draft-ietf-secsh-dns-05.txt
I see great value in being able to assess the domain granting the initial
access to the mail channel and thereby establish more direct communication
to these entities with much less noise generated by the normal name
spoofing. With signed messages, the use of name based
accreditation/reputation can supplant difficult to maintain IP address based
histories. Both CSV and MASS identify the administrators and both are
needed to establish credible reports to rectify largely security related
issues.
-Doug