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

[Alessandro Vesely <[e-mail]>]

On Fri 29/Mar/2013 03:24:10 +0100 Murray S. Kucherawy wrote:
> 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.

In RFC 5451 it was indicated as a comment to the "version" production
rule, as in the current draft.  That might be slightly inappropriate
since that rule works also for the methods, which have their own
versions.  Since -bis has a section on version tokens, readers may
expect to find that statement there.

BTW, would sender-id have had "2.0" there?

>> 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.

Yeah, producers don't mind extra-ADMD consumers who may want to trust
them.

>>> 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?

That's usual.  Doesn't opendkim take a list of identities and compare
each A-R against it?  If it doesn't have the whole list --and admins
may worry about allowing write access to their remardb to any possible
downstream consumer-- then there's nothing it can do about it.

As John said, the point of the authserv-id is to allow a system to
recognize its own A-R headers.  The "its own" part is what limits free
extensibility of the trust boundary.

>> 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.

Different from what the rest of the system sees, but hopefully not
different from what the signer signed.

> It wouldn't cause the version passed to the end user to be different.

Yup.

> You need to send the instruction in the other direction, which makes
> it more complicated.

What do you mean?  I cannot tell the sender that I don't trust it, so
it should stop cluttering messages with its A-Rs.  An A-R for the auth
method, for example, can only be written there.

OTOH, it is possible to recognize that a sender/signer is trusted and
unrename its A-Rs after verification too, when changes are committed
to disk.  I'm not going to code such complication, for the time being.

>> 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.

Thank you :-)