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

"Murray S. Kucherawy" <superuser@gmail.com> Fri, 29 March 2013 02:24 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 3B00E21F8A66 for <apps-discuss@ietfa.amsl.com>; Thu, 28 Mar 2013 19:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DT57iAd7KzdR for <apps-discuss@ietfa.amsl.com>; Thu, 28 Mar 2013 19:24:12 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 04BFD21F8A18 for <apps-discuss@ietf.org>; Thu, 28 Mar 2013 19:24:11 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hj8so109843wib.14 for <apps-discuss@ietf.org>; Thu, 28 Mar 2013 19:24:11 -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=sF1EAV2LpvJz96nwHLjDQenV0RlVmPMLoM7hhTWovSE=; b=tivfAel2wIfzg0mEUnpc0kA5eHLbVPZK5qYkfPEzgXPQNJnXG40Ctxhh2qkJqmRX1V dqVRkP4XMa+++v5iSKxae/6mLIpEpRUH33DBcX6jEeC4wUaUFMgxJbvytioKUE7hPQAF aRHPWYK6HuDc6d1Nm60hnmjOwU3zKKWTemkC/9q980nHbx3XmPQrgEgG/KEuMA74Jz+b 3ibbp0V4ttAZggVbbVesTlzSq13PtODC84FSm6aNYa8//ah/SfEfstPwqSIaHzy6fzg1 X3C23dWk80YFfWJ7HkX8fcYJxTlPuRe/e5v5E79mwLisSmFi4CTs7dCuybBGc4PPgsfs z/lg==
MIME-Version: 1.0
X-Received: by 10.194.134.66 with SMTP id pi2mr989667wjb.51.1364523850943; Thu, 28 Mar 2013 19:24:10 -0700 (PDT)
Received: by 10.180.13.71 with HTTP; Thu, 28 Mar 2013 19:24:10 -0700 (PDT)
In-Reply-To: <515478F2.9070702@tana.it>
References: <CAL0qLwbgjnt8Msofok3ExKBmChtQPfMEFgrrZBimEzU5CYgSjA@mail.gmail.com> <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <CAKHUCzwBrEPSVc4VtJMKZLm+5it3h7dLiW+YZ=_xO2OwP_rLoA@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>
Date: Fri, 29 Mar 2013 03:24:10 +0100
Message-ID: <CAL0qLwYjBDLM_y2tm4udfJFAM6aa9DTTRwu+Hxqrpzsg6-bsdw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Content-Type: multipart/alternative; boundary=089e01228fbe6c52c304d906f74a
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 02:24:13 -0000

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.


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

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.


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


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

You're doing this at the wrong layer.  This change would cause the DKIM
validation code to see something different.  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.

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.

-MSK