Re: [apps-discuss] The authentication server id, was rfc5451bis

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Mar 27, 2013 at 7:41 PM, Alessandro Vesely <[e-mail]> wrote:

> Another reason to review implementations is the version requirement of
> Section 2.4.  Don't you need to say explicitly that the field version
> being specified is "1"?
>

The version is indeed 1, but it is optional in the ABNF.


> It disables transitive extensions of trust.  The assumption that the
> producer has the same list of trusted identities as the consumer
> imposes restrictions on the trust boundary.  Substantially, it
> requires the trust boundary to be a single ADMD, or a set of ADMDs
> where the transitive closure of the trust relationship can be actually
> computed.
>

But this isn't a new requirement.  It has always been the case that the
consumers need to know how to identify the instances produced by its own
ADMD.


>
> For example, if you have Gmail and Yahoo accounts, you cannot
> configure your MUA to simply trust the corresponding identities unless
> both ADMDs vet A-R fields.  Otherwise, someone can send a message
> containing a forged trust-me.yahoo.com to your Gmail account, which
> would get through.  In a non-transitive trust scenario, your MUA can
> trust Yahoo IDs only when they come from Yahoo directly.  For
> transitive trust, if Gmail trusts Yahoo and you instruct Yahoo to
> forward your mail to Gmail, you may expect to find pristine Yahoo A-Rs
> in there, and have your MUA trust them when they come from any
> compliant ADMD.
>

I don't think this document (old or new) goes to great lengths to establish
transitive trust mechanisms, and shouldn't unless there are implementations
that do so.  (I know of some that tried and failed, in fact.)  We do
mention that a starting point for doing so would be to sign A-R fields
before they travel onward, and then the ultimate recipient would need to
know (a) that the external ones to be trusted were covered by a valid
signature, and (b) that they contained an authserv-id that can be trusted.

But this is more bikeshedding for, as John put it, something that's
unlikely to be implemented anyway.


> In this case, I think "complicated" is the right adjective.  Do you
> have an idea of what percentage of opendkim users configure those
> regexps complicatedly?
>

I don't think there are any regular expression configurations in opendkim
with respect to A-R.  There's one setting that enables the "/queue-id"
hack, if that's what you're talking about.  Either way, no, I have no idea
how many people are using.  I recall only one or two ever discussing it.



>
> > The document already goes as far as saying one can also remove all of
> them
> > if it chooses, just to be safe.  Renaming them is probably also fine, but
> > I'm skeptical about adding that here since you're renaming within a
> > registered namespace.
>
> Hm... I don't know if registering the renamed header would make sense.
>

Indeed it would not.


>
> >> Renaming rather than removing solves some issues with debugging and
> >> signature verification, so I'd consider it anyway.
> >
> > True, but the agent removing suspect header fields could also log or
> > otherwise record them as it does so.
>
> That needs to be done cleverly to avoid losing the field's position,
> and is unpractical for signature verification.  Another possibility is
> to comment out the field content.  Like logging, that allows
> additional explanations with it.  If the header was signed with the
> relaxed algorithm there's no need to worry about added whitespace.
>

Any modification, including removing or altering in place, risks clobbering
otherwise valid signatures.  They aren't different in that regard.


>
> Perhaps the spec can mention the three possibilities, delete, rename,
> and comment-out, and then pretend that the term "remove" means any of
> such dismissals, when used for the A-R header field in the rest of the
> document.  However, five times the I-D uses the term "delete" instead.
>

Do you know of any extant or proposed implementations of the non-delete
options?  I don't think it's appropriate to revise a Proposed Standard by
peppering it with a giant "maybe".

-MSK