ietf-dkim
[Top] [All Lists]

[ietf-dkim] Re: Responsibility concerns with DesignatedSigning Domains

2006-08-27 07:59:10
Douglas Otis wrote:
 
You should review a draft where this assumption was tested.

Yes, I looked briefly into it, as you might recall, working
under a "no original research" doctrine can be hilarious ;-)

straw-man proposal regarding the designation concept is at:
http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-dfsp-00.txt

What exactly means "strawman" ?  Looking shortly into it:  an
example or two with an a= vs. d= explanation would help.  I'm
no fan of n= constructs, nobody will read this.

Maybe use <ANY> instead of <WC>, a matter of taste, it didn't 
take me long to find out that it stands for "wildcard".  I've
some difficulties to parse 3.3 and 3.4, anything else is clear.

The A:O and N parts are fine, that's IMO a useful minimum of
flags, with Hector's proposal as maximum.  I can't tell if
anything critical is missing, you have the f=A a= d= case (if
that's how an empty list is supposed to be defined).

Hector proposed to focus on first party signatures.  That
reduces his 1+3*3 to 1+3 cases, and apparently you also have
1+3, where your "1" is the f=A a= d=.

With semicolon as separator I'd stay away from comma or colon
as secondary separator if plus is available, but probably you
want the same look and feel as in base.

a= lists domains where the 2822.From address is assured.
d= lists domains where the 2822.From address is not assured.

What's "assured" ?  With a mail 2822-From: joe(_at_)user(_dot_)isp(_dot_)example
I'd try to get the DFSP of user.isp.example, and then what ?
Or is that already a bad idea for all PRA != 2822-From cases ?

BTW, I'd be surprised if IANA offers to reserve domain labels.
Actually I'd ask them if they're mad if they try to pull this.

You'd need a trick like 7.4 in "base", bind a IANA registry to
_dfsp TXT.  With that everybody is still free to use _dfsp for
other purposes (and if that doesn't work it's her/his problem).

The only reserved domain labels I'm aware of are noted in 2016,
three example SLDs under the cno TLDs, and four TLDs.  And of
course some syntactical classes like "--" as third and fourth
character.  You can't "reserve" _dfsp everywhere.

Either of these lists could be infinitely extended by using a single
query in the form:
 
<signing-domain>._policy-labels.<from-domain>

At some point you'd meet a critical 253, where you'd need some
compression / truncation tricks.

<ehlo-domain>._policy-labels.<mail_from-domain>

Nice idea, where it fits into the 253 limit.  It would force
folks to organize their "include emulation" in a reasonable
way, and it limits unnecessary queries for an unrelated ehlo.

Unfortunately three years too late for the existing versions.
If ISPs offer an includable neutral record passing for their
infrastructure it's no issue, and if they don't do this and
their users try to guess they'll find out what happens next -
unhappy users getting their "include emulation" wrong, likely.

There are alternatives to using i=syntax.  This could be some
added parameter added to both the key and the signature field
making a rather simple assertion:
 
 2822.From address is assured valid.

This would provide clearer semantics and overcome i= syntax 
limitations regarding outside domains.

If that's the case make it so, I didn't follow all discussions
about i=.
 
Those advocating DKIM should not expect all 2822.From domains
will be signed by the same domain

For PRA != 2822-From cases that's anyway impossible, from the 
old Sender: secy@ example up to Resent-* cases, plus some more 
interesting gateway cases.
 
Only the signer identity can be verified, and only the signer
can safely be held accountable. Simple.

Well, folks wanting some kind of DFSP might also want that some
mails claiming to be 2822-From them are rejected.  I can't tell
how that's supposed to work for PRA != From, "not at all" would
be okay.

I've not yet got the essence of your proposal, the a= and d=
lists.  Add some examples please, if it gets too long shrink
chapters 1 and 2.

Frank


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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