[ietf-dkim] Local-part and user-key risk

[Douglas Otis]

On Aug 17, 2005, at 2:30 PM, <domainkeys-feedbackbase02 at yahoo.com>  
<domainkeys-feedbackbase02 at yahoo.com> wrote

Jim Fenton wrote:
>> Don't you need to look at the localpart to determine whether the g=
>> constraint was complied with?  If the answer is "yes, to determine if
>> they match, but I'm not going to do anything else with localpart"  
>> than
>> we're in agreement.
>>
>
> Quite so. The localpart and g= are two of the inputs into the  
> verification
> logic. The outcome is either "email is verified" or "email is not  
> verified". I
> see that form of verification failure as comparable to a selector  
> lookup
> failure or a malformed signature line.
>
> Sure. For diagnostics reasons one may want a more fine-grained  
> explanation of
> the verification failure, but in many cases one can only guess as  
> to the true
> cause. Was it really a g= vs localpart mismatch or did some  
> "helpful" transit
> MTA re-write the signature line incorrectly?


How the 'g=' key extension ends up being deployed is highly  
speculative regardless of an error message.  If the local-part is not  
a function of DKIM, then removing this delegation artifact should not  
impact DKIM results.

Creating an expectation that key delegation requires revocation when  
abused, and entails a level of risk associated with the trust  
conferred, this will discourage the use of key delegation.  As DKIM  
is currently structured, there is an incentive to abuse DNS when  
deploying an inordinate number of user-keys.  Part of this incentive  
includes a lack of replay solutions.

There are a few things that could lessen concerns when removing  
'g='.  The obvious risk of not checking the local-part is that the  
local-part name space may be abused.  Perhaps a greater risk would be  
the damage to the main domain's reputation should this trusted party  
prove untrustworthy in perhaps many ways well beyond abusing the  
local-part name space.  A solution may be able to deal with these  
concerns and with the domain assertion issue as well.


A different approach-

  1:  Delegated Keys should be within a sub-domain of the  
administrative domain. (protects reputation)

  2:  Delegated Keys to poorly trusted entities should be restricted  
to act only as a third-party signer. (explained later)

  3:  Assert a signature flag that prohibits additions of Sender, or  
Resent-* headers. (simplifies domain assertions not bound to headers  
and reduces the number of domain-wide assertions checked.)

To overcome the potential risk of local-part corruption, perhaps the  
source routing syntax, or something similar within the pretty name,  
could convey to the recipient in which name space the local-part  
resides, when the 'third-party' flag is detected in the key.  Assume  
this syntax would be synthesized as part of the checking to avoid  
disrupting email delivery, and stripped when submitted as well.  This  
process would be at the option of the MDA provider.

The signing domain is:
  ad-agency.example.com

The from mailbox address is:
  promotions at example.com

This gets displayed as: (assuming MUAs still handle syntax.)
  @ad-agency.example.com:promtions at example.com


Non-header binding domain-wide assertions:

Email "purporting at some instance" domain checks-

1- Allows TP signing.
2- Allows sub-domain TP signing.
3- Disallows all TP signing.


-Doug