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

[Alessandro Vesely <[e-mail]>]

On Wed 27/Mar/2013 13:56:28 +0100 Murray S. Kucherawy wrote:
> On Wed, Mar 27, 2013 at 1:15 PM, Alessandro Vesely <[e-mail]> wrote:
> 
>>> So why doesn't making authserv-id a "value" accommodate that case?
>>
>> It would overkill, considering that we'd tend to discourage
>> complicated stuff.  A "dot-atom" can have a slash, but perhaps we can
>> live with that.  Otherwise, a "token" can be fit.
> 
> A quoted string is complicated?  They've been used in email header fields
> for quite a long time now.

Yes, sorry for picking the wrong adjective.  The "complication" is
just the annoyance to modify the parser.  It is not that much of a
burden, but asking developers to do so only for accommodating a hack
that we'd discourage anyway is what I'd call overkill.

And, yes, at this point it is bikeshedding...

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

>>>> It is quite complicated to let trusted domain's A-R pass through.
>>>
>>> Why is it quite complicated?  Trusted authserv-ids is merely a set of
>>> strings.  If you're looking at an A-R header field whose authserv-id is in
>>> that list, you've decided explicitly that its content can be trusted.
>>> Anything else should either be ignored or removed (depending on which agent
>>> is looking at it).
>>
>> IMHO, the first paragraph of Section 5 is too mild.  It could be
>> hardened like so:
>>
>> OLD
>>  For security reasons, any MTA conforming to this specification MUST
>>  delete any discovered instance of this header field that claims, by
>>  virtue of its authentication service identifier, to have been added
>>  within its trust boundary and that did not come directly from another
>>  trusted MTA.
>>
>> NEW
>>  For security reasons, any MTA conforming to this specification MUST
>>  remove or rename any instance of this header field that was not added
>>  within its trust boundary.  The authentication service identifier
>>  (authserv-id) is used to identify the agent which added the header
>>  field, with the limits described in Section 7.1.
>>
>> If an MTA kills only the A-Rs that it can clearly identify as
>> forgeries, it would let thru any A-R field bearing some unknown
>> identifier.  Those identifiers may be forged.  If they match a trusted
>> id at the next ADMD (MTA or MUA), then if the latter trusts the
>> former, it has no obvious reason to suspect.  It gets complicated if
>> one tries to derive trustworthiness from routing considerations.
> 
> If consumers are already looking only for A-Rs that use an expected
> authserv-id, and ignoring others, what's the harm in letting the other ones
> through?

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.

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.

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?

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

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

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.

>> Here's the alternative text I promised above:
>>
>>                                               Consistently with the
>>  scope limit outlined in Section 1.2, the grammar does not constrain
>>  the authentication identifier to be a domain name.  Improper use
>>  could thus consider appending a delimiter such as "#" and following
>>  it with useful transport tracing data such as the [SMTP] queue ID or
>>  a timestamp.
> 
> Isn't that materially the same as what's already in Section 2.3?

Materially, yes, but it took me multiple messages to finally grasp the
intended meaning.  Again, maybe it's me, but the discussion starting
at the next paragraph doesn't seem to characterize the stuffing of a
queue id as improper use, and the somewhat relaxed grammar can
complete the misunderstanding.