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

Alessandro Vesely <> Fri, 29 March 2013 10:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 309BA21F938B for <>; Fri, 29 Mar 2013 03:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3SIUKzEhDryk for <>; Fri, 29 Mar 2013 03:33:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1FF7821F9366 for <>; Fri, 29 Mar 2013 03:33:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; t=1364553214; bh=Itxvep3gFkE7QXuIz66ESxtN5yRfQTRKPhJBlCVzTV0=; l=4242; h=Date:From:To:References:In-Reply-To; b=CuL8cPCmwAw6p0yXSwfATM4AwCFeA1YXHmXKIUFg30rIEyYlrDSnXqrpjH92//f8H /g78wz4ecWHXv1vYMfNsJUKgU/3cA09rXoOWlOaoRSpvD8lpu4h/axTKu+6GxXoSrd u6/QABjllKc9QgqActVIAzly13YgpnM9nJVudOjs=
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by with ESMTPA; Fri, 29 Mar 2013 11:33:34 +0100 id 00000000005DC04B.0000000051556DFE.000070EF
Message-ID: <>
Date: Fri, 29 Mar 2013 11:33:35 +0100
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Mar 2013 10:33:37 -0000

On Fri 29/Mar/2013 03:24:10 +0100 Murray S. Kucherawy wrote:
> On Thu, Mar 28, 2013 at 6:08 PM, Alessandro Vesely <> 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

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


> 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 :-)