ietf-mailsig
[Top] [All Lists]

Re: semantics of the signature

2004-10-08 13:27:58


On Fri, 8 Oct 2004, James M Galvin wrote:
 
I am still opposed to an end-to-end email signature mechanism, more
precisely, an end-user to end-user mechanim.  I still believe that to do
so would be re-inventing secure email.

It would if you built completely new signature system like Yahoo and 
Cisco want. But if we extend on S/MIME its just a way to use existing 
secure email technology in new application (that may require new 
extensions for it to work properl for our design).
 
However, the detail I now understand better is that we are seeking an
end-MTA to end-MTA signature mechanism, where one end is "close" to the
originator and one end is "close" to the recipient. 

Correct. But I'll point out if you get "end-MTA to end-MTA" working, that 
pretty much means you got start-MTA to any intermediate-MTA (as intermedia
could well have been the other end) and that means you also got 
intermedia-MTA to recepientend-MTA working as well. So really "end-MTA to
end-MTA" means any MTA in email path to any other MTA in that email path.

Yes, it may be that the originating MTA signature can be validated at 
any point in the path to the recipient, but I don't believe that's a 
primary goal.

It does not matter if we make official it goal or not, the resulting 
system will support it if its supports end-end model. 

I'm hoping this is what Dave meant by "transfer time" mechanism.  If so,
let's be more specific.  If not, well, perhaps this discussion isn't over.

I dont like words "transfer time" either but I think that refers to that 
signature is verified at the time of email delivery when its still in 
transit while for example S/MIME is verified once delivery is completed.

So "transfer time" is basicly a reference to that we're dealing with short
timeframe for verification of signature and that we can use weaker 
encryption methods to provide for faster signature verification.

Also, the primary goal is the creation of one signature, at the
originating MTA.  A question to be debated in the working group is
whether intermediate MTAs should have the option of adding their
signature, what it means to do so, and then how a receiving MTA deals
with the multiple signatures.

As I pointed out if we get end-end mechanism done, that means intermedia
MTAs would be able to add additional signature. But it remains to be 
discussed by this group about what policies apply there, i.e. do you
trust intermediate MTA signature, do you trust original only, etc.
 
Overall, this is close to what MARID was doing but greatly simplified, a
huge win in my opinion.

Its close but not the same. MARID was working on session-based email 
verification based on ip address of SMTP client. Its people at Microsoft
that screwed us up into RFC2822 world there and I'm not greatefull to
them for such step which eventially is what ruined that WG.

As for "greatly simplified", no, I don't think so. MARID technologies are 
by their nature simpler then MASS cryptography verification tecnologies.
 
I still assert that S/MIME and PGP can be part of a solution to this
problem, but I think it was John Levine who asked the question of what
happens when the receiving MTA doesn't understand MIME or the embedded
body part.
I think every MTA and MUA needs to understand MIME by now. The question
is what happens when you use complex mime encapsulations and real text
of email is hiddden well inside some inner layer. 

I'm not convinced that's serious issue, but that's a good
question to debate in the working group.
Yes.

And I agree that the originating MTA signature means more than just "I
control the message."  It means something along the lines of "I'm
asserting that I'm a valid source of email from the email address in the
Return-Path."  
Oh no it does no! Return-Path is SMTP2821 Mail FROM construct, it has 
nothing to do with what we're trying to authenticate here which is email
content itself. But we do want to make reference from that content to
origin RFC8222 headers (i.e. "From:") and authenticate legitimacy of
email address in those headers. 

If you want to verify Return-Path only, then see SPF about system to do
it based on ip adress of SMTP client OR see BATV (to be discussed at
ietf-clear) about how to do it based on cryptography.

The details of that are something that should be debated 
in the working group.

And, of course, there is still the whole issue of key management, but I
don't think there's been any disagreement that that is something to be
debated in the working group, with a preference towards using the DNS.

The question is if DNS can really handle all this in such universal manner.
I think DNS will work for simple cases, but for more complex ones we need 
to be able to rely on key management server. 

And, I think finally, there is the issue of the lifetime of the
signature.  I sense there's some debate to be had on whether the
signature is valid after delivery.

Again, I'll point out that lifetime of email transmission may also be 
different from one case to another. Current SMTP specs (or at least how
SMTP is used) say that email delivery may take up to 5 days. If email
is received by MUA within 5 days of the transmission (and 99% of MUAs
do) I think its not surprising to know that MUA may try to verify the 
signature in the same way MTA would have. 

If I've got all that right, then what I would most like to see the
Charter say is two things.

First, developing an end-user to end-user signature mechanism is
explicitly out-of-scope.

Second, the purpose of this working group is to develop an end-MTA to
end-MTA signature mechanism.
Agreed.

I'm okay with all other issues being left for debate.

That is why we need requirements to come up with list of issues that our
working group will want to solve as part of MTA-MTA signature verification
system.

---
William Leibzon, Elan Networks:
 mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/


<Prev in Thread] Current Thread [Next in Thread>