Since there was some interest from council to decide on position on
Meng's paper, I thought it might be of interest for you to see the
comments I previously made which Meng unfortunetly has chosen not to
incorporate into the paper. My view of the paper in general is that
its rather one-sided towards SPF, DK and SID and is not a real
representative of email security proposals that we have seen lately
and it purposely avoids the issues that may have seen as being against
the proposals or presents those issues as being purely political when
they are not. So in reality it has some of the same problems as
one-sided Sendmail paper.
---------- Forwarded message ----------
Date: Fri, 5 Nov 2004 18:18:13 -0800 (PST)
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>
Cc: Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
Subject: Re: MAAWG whitepaper draft
On Thu, 4 Nov 2004, Meng Weng Wong wrote:
On Thu, Nov 04, 2004 at 03:09:01AM -0500, Meng Weng Wong wrote:
| http://dumbo.pobox.com/~mengwong/tmp/maawg/draft-20041103.pdf
filename changed to
http://dumbo.pobox.com/~mengwong/tmp/maawg/whitepaper.pdf
I have few late comments as I have not had time to review text before
(and that pdf actuallly caused exception and on my laptop)
Page 10:
1. ", but MUAs tend not to use the author data from the signature to
override the From: header." ->
", but MUAs tend not use the author data from the signature to
override the From: header."
2. "S/MIME signs .." ->
"S/MIME and PGP/MIME sign ..."
3. "Keys are signed ..." ->
"In S/MIME keys are signed ..."
4. "Signatures that do not match ..." ->
"In PGP/MIME keys are distributed in the same web-of-trust system as
with PGP and GPG described above. Signatures that do not match ..."
5. "Jim Fent's Identified Mail is similar to DK" ->
"Cisco's Identified Internet Mail proposal is similar to DK but
includes public key as part of the signature and allows to
verify public key fingerprint through DNS and with special
key registration server"
6. "Microsoft's Email Postmarks is ..." ->
"Email Postmarks are MTA Signatures proposals reuse portions of
S/MIME for MTA-MTA verification while allowing for both signatures
that are signed by central certificate authority certificate and for
self-signed certificates with keys that are either self-published in
DNS in ways similar to DomainKays or published by means of S/MIME
key server"
"The IETF MASS (Message Authentication Signature Service) effort
is researching topics related to cryptographic email signing
proposals listed above."
Page 11:
1. Right side
"Sender ID asks all mailing lists to add a Sender: header. This
is not convenient for the installed base of mailing lists who
do not add Sender:" ->
"Sender ID asks all mailing lists to add a Resent-From: header.
This is not convenient for the installed base of mailing lists
that prefer to add Sender: or that do not add any new header."
Page 21:
right side
"Q2 2005 Forwarders to SRS and prepend Resent-From" ->
"Q2 2005 Forwarders to SRS and add headers appropriate to indicate
resending"
Also please remove sentence about MAAWS being the closest to industry
standard body. It is not appropriate as we in fact do have industry
standard body - IETF (and IETF standards are mentioned several times).
"That said you should still join MAAWG, which is the closest thing we have
to industry bodyu at this time" ->
"That said you should still join MAAWG as this organization can help
companies in email industry with recomendations on how to best implement
above steps and how to protect you email messaging infrastructure
against current wide-scale abuse"
Page 9:
Right side
"Some members of the technical community assert that the very idea of
using PRA for header validation is flawed." ->
"Some members of the technical community assert that the very idea of
using PRA for header validation is flawed. Additionally it is also
noticed that use of Resent-From and Resent-Sender headers as specified
in Sender ID specification is likely to be in inconsistent with use of
these headers as specified in RFC2822 email standard"
Add also
"A potential problem for using SenderID and PRA for MUA verification
is that it relies on data about ip address of the sending MTA to be
located in Received header but this is not a required element of
that header and this information maybe missing as well as the header
itself. Using MTA IP address after the time email has been received
also has possibility of not being able to account for changes in MTA
dns record if MTA has changed its ip address since the time email was
received"
I would also urge you to remove "The author recomends that MUA software"
implement SenderID with PRA checking" line all together as otherwise
you're potentially giving MUA author's bad advise.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net