ietf-mailsig
[Top] [All Lists]

Re: draft-delany-domainkeys-base-02.txt

2005-03-29 21:10:39

On Tue, 2005-03-29 at 21:54 -0500, Sam Hartman wrote:

    Douglas> This is extending assurances for the local-part.  This is
    Douglas> not an extension for this local-part mailbox address, and
    Douglas> the selector already permits per-user keys.

Yes.  But you need to scope a per-user key so that a key intended to
be used for accounts-outgoing(_at_)domain is not used say for
system-administration(_at_)domain(_dot_)

This may be more important for anti-phishing than anti-spam.

It seems a reasonable optional assertion.

This mechanism is the only means to make the validation of the
local-part explicit.  It may not be reasonable, if this causes a
proliferation of user-keys beyond normal capacity.  

    Douglas> Is it prudent for domainkeys to attempt making assurances
    Douglas> for the local-part of the mailbox address?  

Yes doing so seems like a requirement for per-user keys to be
reasonable from a security standpoint.  I do not see myself agreeing
to a proposal that supports per-user keys without scoping the set of
identities those keys are allowed to authenticate.

There is value having the domain validated that does not require any
assertions be made about the local-part of an address.  Remember, this
could be Sender: admin(_at_)remote-users(_dot_)mit(_dot_)com
           From: anyone(_at_)mit(_dot_)com

I offered a mechanism to quell phishing attacks in the
draft-otis-mass-reputation-01.txt. Domainkeys still needs additional
policy assertions beyond the current draft to address this issue. 
          
    Douglas> Not
    Douglas> accommodating this local-part assurance (via individual
    Douglas> keys), would acknowledge domainkey's relative weakness in
    Douglas> terms of its ability to scale in this manner.  

I failed to be able to assign semantics to this sentence.

In other words, verifying the domain should be the limit of the scope
when keys are given to individual users. 

    Douglas> Adding an
    Douglas> assertion (within the key or elsewhere, such as l=y/n)
    Douglas> could allow the domain to assert that the local-part is
    Douglas> valid, and permit any number of users to utilize a single
    Douglas> key.

I don't quite understand what you're getting at.  I don't think I'll
like it though;)

I did not want per-user key to have greater value than a shared key.
The reason is out of concern what hundreds of millions of users will do
to DNS, when each expects their own key.

    Douglas> The concern regarding the "g=" mechanism is that it
    Douglas> mandates per-user keys to achieve this assurance.  

I'm interpreting it as an important part of making per-user keys work.
I would tend to agree that using g= is only useful for per-user keys.

By ruling out this method, there are other methods that can be used.
Yes, you can have per-user keys, but they will require other means for
isolation.  Not having this mechanism ensures this does not impart any
perceived advantage or prestige.

    Douglas> Making
    Douglas> local-part assurances for portable private keys not
    Douglas> prudent, as it requires a mechanism that does not scale.

In general I don't think you will find security people in the IETF are
willing to support a scheme in which a single key is given to a large
number of parties.  So, yes, I think portable keys (by which I mean a
key that a mail composer can take with them) will tend to be per-user.

I agree.  Each user should be given a unique key.  This key should not
provide any perceivable advantage with respect to acceptability.  In
fact, the opposite should be true.  This type of use should offer the
user less advantage and not more.   

    Douglas> I fear its use.  A major feature of the signature, is
    Douglas> that it allows safe application of reputation.
    Douglas> Validation of the local-part is still trusting the domain
    Douglas> that makes the validation.

I'm very confused here.  It seems like you are coming from a very
different mental model; I think you will need to be significantly more
verbose for me to understand you.

The administrator controls access to the system. The administrator doing
a good job is where a reputation system will stop.  I doubt a reputation
service could offer each user their own rating.  With respect to abating
phishing, and other types of abuse, stop at the mailbox-domain and go no
further.

    Douglas> Any organization with the resources needed to establish
    Douglas> per-user keys, will also have resources to ensure mail is
    Douglas> submitted through their own servers.  

This statement is false.  I'll submit MIT as an example: I'm sure we
could set up a scheme to hand out per-user keys to anyone who wanted
them.  I'm equially sure we will never be able to convince everyone to
use our outgoing servers from all mail having an mit.edu from line.  I
suspect there are a lot of other organizations with similar
requirements.

The trick is already provided within domainkeys to allow the sub-domain
to work as a means of isolating these people without them changing any
of their habits.  They can use their desired outbound server, if they
like (assuming there is some signing software added.).  Just don't offer
the recipient any assurances regarding the local-part and you have
something that is still better than now, and yet it does not encourage
per-user keys as having higher value.

    Douglas> For remote users, a
    Douglas> means to indicate the local-part has not be validated
    Douglas> would seem more appropriate.  Such a domain could be
    Douglas> isolated, such as remote-clients.example.com, where the
    Douglas> key does not assert a validation of the local-part (l=n).

I do not think I could support such a proposal as the only option.  I
don't think many people could sell such a setup to their users.

I'm again struck by the significant disparity in ideas of how email
works between participants of this list and in what level of breakage
can be tolerated.  Personally, relegating remote users to some other
domain seems unacceptable.

The signature is relegated.  The world for the users does not change.
If they do not wish to go through the mit servers, their local-part is
not assured.  

    Douglas> I would also recommend that selectors be ASCII numeric
    Douglas> values 0-65535 to be compatible with KEY-TAG references
    Douglas> within RFC-2538, such as P1234.  If nothing else, this
    Douglas> adds a constraint on the selector mechanism.  With
    Douglas> concerns regarding rampant inappropriate use, I do not
    Douglas> think the "g=" mechanism is wise.

This seems like a bad idea.  First, it limits you to 65,536 keys.
Second, it prevents you from using hierarchy (and multiple zones) in
your selectors; it seems like for huge sites multiple zones may be
required.  Finally, RFC 2538 is quite clear that algorithm identifiers
and key tags are only for dnssec.

Limit the scaling of these keys and keep this in control.  Use of
sub-domains would be one method to expand when needed.  This would not
be for the personal email address, but rather just tracking the
signature in these special cases, where only validating the domain is
important.

I see advantages allowing the binary format for the resource records to
be copied, to minimize efforts creating a specific record for
domainkeys.  This happens later when going to large keys. 

-Doug


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