I reference draft-ietf-marid-core-02.txt
The basic aim of the MARID Sender ID appears to me to be the presentation to the
end-user of a validated PRA.
The MTA which receives an incoming message is required to determine and validate
the PRA. If a valid PRA is found, the message may be delivered to the intended
recipient.
The draft recommends (albeit only in section 6.3 when discussing a particular
mode of attack) that MUAs should display the PRA, and, by implication, the user
of that MUA may trust that the PRA has been validated.
There is no recommendation that I can see anywhere in this draft that the MTA
should inform the MUA that a PRA test was successfully undertaken.
Now consider the situation of a user who receives her eMail from an ISP.
The ISP may make a one-off announcement that it is now "supporting Sender-ID".
This would be taken by the user as an invitation to trust the ISP to be applying
the test to all messages.
If she has a compliant MUA she sees one or more addresses displayed.
What she does not see is any indication of where any of these addresses have
been validated.
- Suppose the message has arrived at a back-up MTA which has not yet been fitted
with the Sender-ID tests.
- Suppose the main MTA has been mis-configured or some other fault.
- Suppose the ISP has changed its policy and is no longer undertaking this test.
- Suppose that the ISP has been required to cease use of a PRA-related patent
by the issuer of its licence.
How is the end-user supposed to know whether or not to trust any of the
displayed addresses?
The whole essence of the 'implied security contract' of Sender-ID is that the
end-user is assured that the PRA has been validated, and can therefore be
trusted.
I contend that this inability to communicate to the MUA whether or not the
Sender-ID test has been applied to any particular message is a significant
security flaw.
HTH
Chris Haynes