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

[Alessandro Vesely <[e-mail]>]

On Wed 27/Mar/2013 20:53:32 +0100 Murray S. Kucherawy wrote:
> 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.

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

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

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

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

Oops, I thought the patterns in "RemoveARFrom" were regular
expressions rather than plain strings.

> Either way, no, I have no idea how many people are using.  I recall
> only one or two ever discussing it.

Yeah, not worth overworking on that.  Sorry I raised that point.

>>> The document already goes as far as saying one can also remove
>>> all of them if it chooses, just to be safe.

Besides simplicity and security, that choice allows extensibility of
the trust boundary.

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

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.

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

Courier-MTA does rename.  That will go in Debian and other distros
when released.  I discussed the A-R issue with Sam Varshavchik and was
initially unhappy with the solution he came up with.  Now that I have
experienced configuring and coding my filter to work that way, I must
say he was right:  It's simple, secure, and can be undone at will.

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.