ietf-asrg
[Top] [All Lists]

Re: [Asrg] 6. Proposals - DNS + PKI - Yahoo's "Domain Keys"

2003-12-10 18:06:49
Markus,

At 05:20 PM 12/9/2003, Markus Stumpf wrote:
On Tue, Dec 09, 2003 at 04:28:05PM -0800, Mark Baugher wrote:
> A clarification...
>
>           +---------------+             +---------------+
>           | UA.o -> MTA.o | -> MTA.i -> | MTA.r -> UA.r |
>           +---------------+             +---------------+
>
> Are you saying that MTA.o signed it and a spammer captured
> the message and resent it?  Was it resent from MTA.o or from
> some other domain or does this not matter?

You don't need to capture.
The problem I addressed is "what to sign" to make it impossible to steal
the signing and use it in another context.
E.g. the message to the list I am replying to has headers:

Received: from mbaugher-w2k07.cisco.com (sjc-vpn3-38.cisco.com [10.21.64.38])
        by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hBA0S6iO027174;
        Tue, 9 Dec 2003 16:28:07 -0800 (PST)
Message-Id: 
<6(_dot_)0(_dot_)0(_dot_)22(_dot_)2(_dot_)20031209161256(_dot_)03afcbd0(_at_)mira-sjc5-6(_dot_)cisco(_dot_)com>

Both header lines are (or should be and probably are) unique. So you now
could use them, build a checksum, sign it with your private key and get
something like 'JK807JK8JK90KLKL'. Now you add a Header like
   X-Signature: sj-core-4.cisco.com; sign='JK807JK8JK90KLKL'
I can now (as the recipient) lookup your public key and validate,
whether the above two lines match the signature in the X-Signature:
line. So far so good.

But now, what stops a spammer from copying the two lines and the
X-Signature line and create a new email useing the stolen headers
like:

Received: from sj-core-4.cisco.com
        by mail.example.net with ESMTP id 1234567890;
        Wed, 10 Dec 02:02:32 +0100 (CEST)
X-Signature: mail.example.com; sign='908865KJGLSD0987'
Received: from mbaugher-w2k07.cisco.com (sjc-vpn3-38.cisco.com [10.21.64.38])
        by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hBA0S6iO027174;
        Tue, 9 Dec 2003 16:28:07 -0800 (PST)
Message-Id: 
<6(_dot_)0(_dot_)0(_dot_)22(_dot_)2(_dot_)20031209161256(_dot_)03afcbd0(_at_)mira-sjc5-6(_dot_)cisco(_dot_)com>
X-Signature: sj-core-4.cisco.com; sign='JK807JK8JK90KLKL'

How would you know that the message NOT really originated (or was sent
via) sj-core-4.cisco.com?

It would not verify if the signature design was secure.  That is,
one should not sign a piece of the message that could be cut and
pasted in this way.  I have not seen anything about the signing
proposal to suggest that they were doing this or even signing SMTP
trace record.

So yes, the problem you describe is a problem that's caused by a
poor signature design.


As a lot of software modifies/replaces/deletes both the message headers
and the message bodies you can't simply base your digest and signature
on this information.

What gets signed is an open question.  This does not strike me as
an insurmountable problem.


> If the spammer sends from MTA.o, then wouldn't we expect MTA.o
> to have a policy to not forward mail that it had previously
> signed?

No. Why?
If I get an eMail from a friend with an address at a public mail service
provider (aka freemail) and think it is funny, why should it not be
possible to bounce the message on to another friend at the same freemail
provider as the original sender? Or think of simple addresslists ...
   cat >> .forward   (for jokes(_at_)example(_dot_)net)
   joe(_at_)example(_dot_)com
   jane(_at_)example(_dot_)com
   jill(_at_)example(_dot_)org
Now bert(_at_)example(_dot_)org sends mail to jokes(_at_)example(_dot_)net and 
the mail will
go back to the originating system to jill(_at_)example(_dot_)org(_dot_)

I think of each message sent as a separate mail transaction that will
have a separate signature applied by the mail submission agent.


> If it comes from some MTA.x then a legitimate MTA.x might
> reasonably have a policy of not forwarding mail signed by
> some MTA.o unless (1) it has some MTA.i relationship
> with MTA.o, which will rarely be the case, and

How can you detect relationships between MTA.x and MTA.i?

You (i.e. MTA.r) do not need to detect this relationship.  What I
wrote above is "a legitimate MTA.x might reasonably have a
policy of not forwarding mail from MTA.o unless 1) it has some
MTA.i relationship with MTA.o, which will rarely be the case..."

What do you
mean with relationships between MTA.x and MTA.i?

I did not write about a relationship between MTA.x and MTA.i.
I'm apparently being unclear.  Please forget about MTA.x and let
me try this again.  I assume that in the vast majority of cases
there is no need for an MTA.i.  I assume that the MTA.i is required
where dialup is needed, in countries where online connectivity
is intermittent, or between planets, etc.  I am also assuming
that when MTA.i provides such a service to an MTA.o, then THEY
have a relationship.  Please correct me if I'm wrong.


> (2) it was in fact received from MTA.o.

To determine this is the problem ;-)

If MTA.o and MTA.r both do signing and verification, then
they have credentials (keys) to establish a TLS connection.


> If MTA.x is not legit, then won't MTA.r make a determination
> on the validity of the message based on the trust it places
> in the signature of MTA.x and not MTA.o?

How do you determine that "MTA.x is not legit"?

You (MTA.r) don't need to determine this.  In my note I was breaking
down the problem by cases, e.g. A or not A.

Is  dsl081-084-010.lax1.dsl.speakeasy.net  [64.81.84.10]  legit if it
can provide a certificate?

No.  Anyone can get a certificate.  But if it has a certificate that
MTA.r has issued, signed, or otherwise authorized then
I would expect that it would consider MTA.o to be "legitimate."
There would need to be some ceremony or procedure in place in which
people are involved - kind of like a key-signing party.  What I don't
like about the signing approach is that good security technology
requires trained personnel and this can be expensive.  What
might make this cheaper is the fact that the result of a temporary
security breach in antispam is not as serious as, say, accepting a
bad route in BGP.

What must be the object of the certificate
(sorry I don't know the correct english word, what is it that is
certified? Is it the name? is it the IP address?)

That's a good question.  I'm an SPKI bigot and don't think we necessarily
need a public key bound to a name.  The public key itself can serve as
the identifier.  But Yakov said that the key attests to the fact that
MTA.o is authorized to use an address.  Some would probably see use of
an X.509 cert that binds a public key to a domain name as being
the way to go.


If it tries to inject
an email with an envelope sender joe(_at_)example(_dot_)com and a recipient 
address
in your domain and it has a legit certificate (whatever that means)
how can you determine if the message really originated at MTA.o?

LMAP :?)


Yahoo's answer would be "look at the signature", but we've seen above
that it is hard to put a signature in a email and making it secure
and not stealable.

I think it can be done and you could reasonably ask me to prove it.
That would lead to a long thread on MTA signing, which I don't think
is germane to this list.  Instead, it would be better to agree to
disagree.

cheers, Mark


        \Maex

--
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



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