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

"Murray S. Kucherawy" <superuser@gmail.com> Fri, 29 March 2013 19:25 UTC

Return-Path: <superuser@gmail.com>
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 96EC821F8E94 for <apps-discuss@ietfa.amsl.com>; Fri, 29 Mar 2013 12:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.132
X-Spam-Level:
X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001]
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 9MuYG4kxtOPY for <apps-discuss@ietfa.amsl.com>; Fri, 29 Mar 2013 12:25:48 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5AF21F8E87 for <apps-discuss@ietf.org>; Fri, 29 Mar 2013 12:25:48 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id o45so538180wer.36 for <apps-discuss@ietf.org>; Fri, 29 Mar 2013 12:25:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Mj/RpdjS0gTNEY2cJVuofM/hqR/fVDK3yxdH4sIrqiA=; b=zf31Z2RS+E8ASrhEvO89KdmWmijSgY7ROUnMnEMNK8xk4l/CTomUh5aZ5FCx7cn53f TUe1iBoZ9p+s44EV7OU23VndW1iFu69ik1BBTCYGCkHGbA1AMbDIvng4MJyFY0teZdE8 EnmEMyq4xvOvfS6/uDEtv1oMgWvMIR2nc2j6VRs2NmrOGg6N/fpylWkEBuHHqpmyWu3H 2wDcWbQI6r0LpUURgK1vPn0Imcv61o46nSyoIb3oe6QeRQcMhsB0L7x7iVAMyIXG0ka2 tS7lEByRlaq+fpNrwZkZ4fztBfkkD+si4/68hi38VHLirtfsQQ9RXE0PhFm2PPnk4/4W sQTg==
MIME-Version: 1.0
X-Received: by 10.194.134.66 with SMTP id pi2mr5162414wjb.51.1364585147517; Fri, 29 Mar 2013 12:25:47 -0700 (PDT)
Received: by 10.180.13.71 with HTTP; Fri, 29 Mar 2013 12:25:47 -0700 (PDT)
In-Reply-To: <51556DFF.6000202@tana.it>
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> <51556DFF.6000202@tana.it>
Date: Fri, 29 Mar 2013 20:25:47 +0100
Message-ID: <CAL0qLwZGYN95axF=h4N0YWn+5Fb9rWi6RL=D4P0jiAkV36m_Zw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Content-Type: multipart/alternative; boundary=089e01228fbefbcfeb04d9153cfa
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
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 19:25:49 -0000

On Fri, Mar 29, 2013 at 11:33 AM, Alessandro Vesely <vesely@tana.it> wrote:

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

The version production is 1*DIGIT.  That's not a comment.


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

No.


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


Yes, when operating as a consumer of the field (for the purpose of
identifying the ones that need to be deleted), not a producer of 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.
>

It doesn't need the whole list when acting as a producer.  It needs one
string.


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

Consumers get to have a set that they consider "their own".  Producers can
only insert one string there, obviously.


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

Of course it is.  What you're feeding to dkim_header(), by changing it,
will invalidate the signature, if that field was signed.


> > 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 totally confused by what you're getting at here.

dkim_header() tells the DKIM layer what it's signing or verifying.  Why you
would want to change that is beyond me.  What you're trying to do is alter
the name of the field so consumers won't see it.  dkim_header() is
absolutely the wrong way to do that.  Rather, you need to tell the MTA to
do the rename operation, which might actually be a delete+insert
operation.  DKIM has absolutely nothing to do with that.

-MSK