[Asrg] 3. Problems with domain keys and with message-body-authenticator

[William Leibzon <william at completewhois.com>]

On Thu, 27 May 2004, Everton da Silva Marques wrote:

> I take it back, MBA actually seems better
> (cheaper) than DomainKeys for some cases.
No, its not, not even close.

> There is an updated draft 0.03 of MBA:
>   Message-Body-Authenticator
>   http://nucleo.freeservers.com/mba/
> Would anyone care to comment or even

Your MBA is not scalable as it requires dns record for each message that
passes through the system. This is called message tracking and dns is not 
good procotol to be used for such purposes as frequent updates will need 
to be done to dns zone file (so TTL will have to be kept very low and
caching  is not possible, which is main advantage of dns protocol) as well 
as that dns zone file would become too large and that creates problems 
with DNSSec. This system is completely unusable for any large company. 

Its also not usable for same reasons as domainkeys because to work it 
requires absolutly every MTA in the mail path to support it and you can 
not make all MTAs upgrade at the same time. Read more about it below.
 
Now as far as yahoo domain keys, I think it needs to be rewritten completely.
The concept is not bad, the proposed implementation however is. Here are 
several main points that needs to be worked out:
1. We do have KEY dns record defined in RFC 2535 (its also unfortunetly 
   not allowed to use RFC2535 KEYs for email as originally proposed based 
   on update to it by RFC3445) and something like that should be used 
   instead of TXT record.
2. The 348-byte key size used for Yahoo domain keys is too weak and that
   means message can too easily be forged. Key size should be increased 
   to 512 bytes or preferably 768 bytes.
3. Using entire message with headers for calculating hash is bad idea 
   because headers often change in transmission and sometimes even message.
   For reliable operations, content of the message needs to have its own
   signature for each mime portion has and separate one for headers, 
   listing which ones are being used.

On the point 3, as I wrote in another recent message to this list,
domainskeys will fail if intermediate MTA does not know about domainkeys. 
Then it may change "To:" header or even "From:" header and not change 
anything else. That means that even if headers are encrypted separately, 
verification of that may fail if intermediate MTA changed them and did 
not know about domainkeys and made no attempt to enter header with new 
signature. So we should provide for that intermediate MTAs should
inform as part of the received header if they are domain-keys
compliant and  provide signature for just the received header
(I wrote about possiblity of doing it here:
http://groups.google.com/groups?selm=fa.idf7309.1r12639%40ifi.uio.no )
or new signature for all headers if they have been changed. 

But if received header does not inform that message has passed through 
domainkeys-compliant MTA, it should be assumed that it can not longer
be trused to be verified through domainkeys algorithm. In such case
only content may be checked and even there intermedia MTA may possibly
change it. And although personally I don't think intermedita MTA 
should be changing content, the real life is that many mail lists do 
(for example all isp-lists.com maillists to  which I subscribe) and add 
additional maillist identification information to the buttom of the 
message so even getting rid of the message if content does not verify 
would not work. 

Since we can not trust message that passed through intermediate system to
still carry valid domainkeys singnature it opens the system up to abuse.
All spammers have to do is to add some random yahoo domain keys signature
to the message and add additional forged received header to make it seem
that message passed through non-compliant mail list or forwarding system
that change the original. In such case, eventhough message still has yahoo 
domain keys signature, it can not be used for verification and as such
the message could have been forged but we really don't know for sure
eventhough domainkeys signature is present.
 
As result we end up with the fact that yahoo domain keys is only good for 
PtP verification between two compliant systems and in that case we might 
as well just use  stronger encryption and message verification anyway such 
as what can be done with TLS.

Now this does not mean yahoo domain keys is failure concept, it just means
it should be implemented differently. One possible way to do it is to have
signatures done in PGP-style by adding them to MIME content in such a way
that intermediate MTAs would not change it but add their own additional 
MIME content portions. The signatures should still come from MTAs and 
public keys be published in DNS. It maybe possible to even modify S/MIME
to work in this way, but right now S/MIME changes message so much as to 
require S/MIME compliant program on the other side and we just can't be 
sure that it would be the case and should provide for full backward 
compatibility.

---
William Leibzon
william at completewhois.com


_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg