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

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

On Thu, Mar 28, 2013 at 6:08 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.
>
> Fine.  But since the spec says:
>
>    if a parser finds a version after an authserv-id
>    that it does not explicitly know,
>
> then, a parser designed after 5451bis has to _guess_ that the one it
> knows is indeed "1".
>

Why?  This hasn't changed in the -bis document either.


>
> >> 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.
> >
> > 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.
>
> My point was that the producer needs to know the list trusted by the
> consumers, in order to remove spoofed fields.
>

This too is unchanged, and hasn't been identified as a burden yet.  The
producers and consumers need to know their own domain names as well (for
the obvious reasons) and that's never been considered a problem.


>
> > 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 agree that it shouldn't:  Section 1.2 is clear about being agnostic
> on the trust boundary.  However, if the local definition of "trust
> boundary" is such that a producer doesn't know the whole trust-list,
> then the MUST in the first paragraph of Section 5 is not actionable.
>

Why would the producer need to know more than one entry in the list?


> > Any modification, including removing or altering in place, risks
> clobbering
> > otherwise valid signatures.  They aren't different in that regard.
>
> Renaming by prefix insertion allows recovery at very small risk, with
> very simple code:
>
>   dkim_header(dkim, start + dkim_unrename,
>      eol - start - dkim_unrename);
>
> where dkim_unrename is either 0 or the length of the prefix inserted
> by the upstream agent.  Note that the code above doesn't know whether
> the field is actually signed or not.
>

You're doing this at the wrong layer.  This change would cause the DKIM
validation code to see something different.  It wouldn't cause the version
passed to the end user to be different.  You need to send the instruction
in the other direction, which makes it more complicated.

I'm not proposing to standardize renaming, since that should consider
> also conventions on what prefix to use, and maybe even how to sign in
> the presence of such prefix.  But I think the standard should avoid a
> "MUST delete", as dismissals by any other means sort the same effect.
>
>
I could also argue that renaming has the same effect as deleting; something
looking for "Authentication-Results" as a header field name will simply no
longer find it.  I'll see if I can write up some compromise text for the
next version.

-MSK