"Douglas" == Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
Douglas> On Tue, 2005-03-29 at 17:48 -0500, Sam Hartman wrote:
>> > Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
>> >
>> > There is some redundant information within domainkeys.
>>
>> http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-02.txt
>>
>> > I assume the following is saying the sending domain has >
>> confirmed the user is entitled to use the local-part of >
>> either the Sender or From header.
>> >
>> >|The current valid tags are:
>> >|
>> >| g = granularity of the key. If present with a non-zero >|
>> length value, this value MUST exactly match the local >| part
>> of the sending address. This tag is optional.
>> >|
>> >| The intent of this tag is to constrain which sending >|
>> address can legitimately use this selector. An email >| with a
>> sending address that does not match the value of >| this tag
>> constitutes a failed verification.
>>
>> I think the intent here is both to permit per-user keys and to
>> permit address extensions.
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 importang for anti-phishing than anti-spam.
It seems a reasonable optional assertion.
>> I don't see the problem you seem to see.
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.
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.
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;)
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.
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.
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.
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.
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.
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.