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

Alessandro Vesely <vesely@tana.it> Fri, 29 March 2013 10:33 UTC

Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309BA21F938B for <apps-discuss@ietfa.amsl.com>; Fri, 29 Mar 2013 03:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SIUKzEhDryk for <apps-discuss@ietfa.amsl.com>; Fri, 29 Mar 2013 03:33:36 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF7821F9366 for <apps-discuss@ietf.org>; Fri, 29 Mar 2013 03:33:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; 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 [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 29 Mar 2013 11:33:34 +0100 id 00000000005DC04B.0000000051556DFE.000070EF
Message-ID: <51556DFF.6000202@tana.it>
Date: Fri, 29 Mar 2013 11:33:35 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <CAL0qLwbgjnt8Msofok3ExKBmChtQPfMEFgrrZBimEzU5CYgSjA@mail.gmail.com> <51458A59.8040206@tana.it> <CAL0qLwYEe9Wmvr-+eZL_yqChRf+a+11zRXCmW2Md9PGvH9PK-g@mail.gmail.com> <514DFAC8.7040406@tana.it> <CAL0qLwbqNUbPOYbXQEzM6X4=RLiqCQG2TbsO9A8PaE+a3Z3oNQ@mail.gmail.com> <514EEBB7.40205@tana.it> <CAL0qLwZZ3iB1BwtfK6TxooEzbTwSxm-KZYgcMMdPUp3OyMpMag@mail.gmail.com> <515040D2.1080409@tana.it> <CAL0qLwa4+na-bAauXN1cySyxLxrKWETONcVLc-Ncf5tdyhY+4w@mail.gmail.com> <51519767.4060808@tana.it> <CAL0qLwYU4CwN4=xFpb5wzSfjmsegxncy95KBP7M2irNf1gR1hg@mail.gmail.com> <5151F698.60309@tana.it> <CAL0qLwZKJ1mGPcXDhYFNA_ZM7jByEP3WWHMmHEx-pTVtGNT9jQ@mail.gmail.com> <5152E2DB.4030807@tana.it> <CAL0qLwZ5-GAJDAS1Wd4y9cFaOk5zfM2UDNdzUh82v+Y=0wRvkA@mail.gmail.com> <51533D3D.20702@tana.it> <CAL0qLwap9XuD0ahnoT4R33Nnbus4i_Ksg9QDS7RsVzqWi8xc2A@mail.gmail.com> <515478F2.9070702@tana.it> <CAL0qLwYjBDLM_y2tm4udfJFAM6aa9DTTRwu+Hxqrpzsg6-bsdw@mail.gmail.com>
In-Reply-To: <CAL0qLwYjBDLM_y2tm4udfJFAM6aa9DTTRwu+Hxqrpzsg6-bsdw@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=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 <vesely@tana.it> 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 :-)