On Fri, 10 Jun 2005, John Levine wrote:
Nice summary of prior work in the first part. I have a few niggles but
it's basically correct and well organized.
Thank you. And I'd be interested to here about any "niggles" too, the
online version is not final, i.e. any serious inconsistencies can be fixed.
Also just the first summary portion of the paper (parts 1-5 and conclusion,
but without part6 that talks about my path after crypto algorithm) is
available as separate pdf document, see right top link on html document site.
IPR Disclosure: Algorithm I described above for doing path authorization
after forwarding based on hostname from crypto signatures is patent
pending. License is expected to be compatible with GPL programs.
What's the application number? I don't see anything with your name in
the USPTO application database.
First of all only provisional application is filed right now. Plus you
probably don't know but William is my middle name and not legal first name.
If you're that curious I'll provide the number, I don't think it matters
with provisional applications.
Also, where has this been implemented and how much mail have people
run through it? For a scheme this complex, it's important to have
data to compare the results of this scheme with simpler alternatives
like plain DK or S/MIME.
Despite what you think, I don't write things down unless I had run at least
some experiments and tested basis ideas. Not always everything I write but
the main parts I always test between 2 or 3 machines in the lab.
As far as part6 of the paper you also seem to be confused that it describes
META Signatures - it does not. META is just used as an example, the same
algorithm will work with IIM, most likely with DKIM too.
If you want to test it yourself do the following:
1. Get IIM server and set it up on network with domain in MAILFROM
that has SPF record that positively identifies that network.
to network where that IIM server is used and with -all at the end
2. Send email to the forwarding system to destination further away,
we're going to assume forwarder does not do SRS.
3. After the forwarding site the final destination checks IIM signature
and we're going to assume it verifies. It then extracts hostname from
the "h" tag of IIM signature and resolves the ip address. After that
the ip address is used as "smtp client ip" for SPF verification based
on SPF record for MAILFROM domain. SPF is going to verify despite
that message has been forwarded. This will work 100% of the time!
Now as this is serious security mailist (hopefully), I'll note that what
is described above is not 100% authorization safe because it makes an
assumption that data entered in the signature about host it is correct.
Obviously signature is verified, however all this does is puts this name
as being heresy data based on another verified identity (presumably Sender).
If you read my paper its exactly the problem that I have that some people
propose to use one method as way to positively identify forgeries in
entire email where as you need to look and have safe ways to positively
identify forgeries for each identity independent (i.e. having verified
Sender does not mean that MAILFROM could not have been forged purposely
by that sender - or the other way around - that is why doing SPF with DK
together is bad idea). The core issue is that many people proposing SPF,
SID, DK and others see the technologies largely as something for anti-spam,
where as I look at it as part of basic email security and want to see
that authorization for each identity be positively (and negatively!)
identified on its own.
So getting back to the point of the algorithm I proposed, it needs a
positive way to identify that hostname really was the one used to enter
the signature and that means being able to do authorization of the
signature not just on the sender but on the hostname or both together.
That is why META-Signatures contain possibility of multiple "ID" segments.
Without possibility of multiple ids (multiple roots for authorization)
it can be done with either cryptographically verified trust (public key
is signed by multiple roots and this is indicated in the signature) but
that only works with something more complex like S/MIME. For DK or IIM
with single authorization root, you can do it with SRV or proper dns
redeligation, i.e., if domain example.com is a source for authorization
for crypto signature (i.e. "d" tag of iim), then it uses SRV record to
list location of the actual cryptographic data lets say its at
"r1._fp.mail.example.net" and where "h" is "mail.example.net".
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net