Re: [apps-discuss] draft-kucherawy-rfc5451bis

Dave Cridland <dave@cridland.net> Fri, 15 March 2013 11:34 UTC

Return-Path: <dave@cridland.net>
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 B3F2321F8D66 for <apps-discuss@ietfa.amsl.com>; Fri, 15 Mar 2013 04:34:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 5agJJM5aMWKj for <apps-discuss@ietfa.amsl.com>; Fri, 15 Mar 2013 04:34:03 -0700 (PDT)
Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7DB21F8ABD for <apps-discuss@ietf.org>; Fri, 15 Mar 2013 04:34:03 -0700 (PDT)
Received: by mail-oa0-f52.google.com with SMTP id k14so3192248oag.25 for <apps-discuss@ietf.org>; Fri, 15 Mar 2013 04:34:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uvoqz0MZEHKnBPZgbkN653+BMZ7CFM5If6e0mCvqcEk=; b=GNoXtQKWcOSD0vM7KP03kD0nU92VmRcOeCake/JoBA8b5jbJ4fppjRFdJTol+zGyml YS7emGDabcvkRGuwfORkYOQs1lDRRrrNwBAFonA+yk7wdtNqXap19xhlLuP+cahlZE23 WrgB0FonH/OXU52XAt8FTZQnmrDmJnRxlW238=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=uvoqz0MZEHKnBPZgbkN653+BMZ7CFM5If6e0mCvqcEk=; b=AtjaY4Qumckov25GEI6b6k3kspf1czSSSfVPbAWXzWlwvttrayW72utRSpCbMK3SCO qe7qKSwtvXy1+JcVVQ0UBvDSt//gpBG1yqf1wzA+FXk0xE40KlAxBMhOQBEqoH9y4P4m 52/lPxXVwTOhLT8zcr1kZBoHJtTeCFqpBu1j44YcVoDZDUd0i3qHGXd0xEZzNPymogC0 9RhCx84HS602HnITEUdCJb7obSe9wA0xu3t5Elub6jEnJ5aSw/x+tiSkZXhmP1XmVw/q Kg06MRsIKmC9Aax0U8i+9s+tlamMtnXiVuSu/CXBJSFVvBslzKqUuuwSUp75P40Op2Wi f6HA==
MIME-Version: 1.0
X-Received: by 10.60.10.226 with SMTP id l2mr2834490oeb.67.1363347243187; Fri, 15 Mar 2013 04:34:03 -0700 (PDT)
Received: by 10.60.22.105 with HTTP; Fri, 15 Mar 2013 04:34:03 -0700 (PDT)
In-Reply-To: <CAL0qLwbgjnt8Msofok3ExKBmChtQPfMEFgrrZBimEzU5CYgSjA@mail.gmail.com>
References: <CAL0qLwbgjnt8Msofok3ExKBmChtQPfMEFgrrZBimEzU5CYgSjA@mail.gmail.com>
Date: Fri, 15 Mar 2013 11:34:03 +0000
Message-ID: <CAKHUCzxfBtLTt3p3moGgEQx+p5kr=-e2Mn58xaqNvWFGiW=Lpw@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8fb1f8d022d7fe04d7f5047a
X-Gm-Message-State: ALoCoQmoQHLgFYVTflBUqMZrH5mBN10ZWy6vZDXfdOpAsQSv6yN3sJcYxR10bMubGbV9yyozLjl1
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-kucherawy-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, 15 Mar 2013 11:34:04 -0000

On Thu, Mar 14, 2013 at 7:40 PM, Murray S. Kucherawy <superuser@gmail.com>wrote:

> I've uploaded an update to draft-kucherawy-rfc5451bis for review.  It
> incorporates the feedback I've received over the last few months since the
> last version.
>
> https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/
>
>
I've not seen this document before, nor its predecessor, so I'm casting a
fresh pair of eyes on it. This may result in my not having understood the
draft, but I'll pretend that's the draft's fault rather than it possibly
being my own idiocy.

For the most part, this document looks fine and solid.

Two items concern me in a major way; one further item has me mildly nervous.

First, the minor one:

The header includes definition of a version ABNF production optionally
following the authentication server's identity. It took me some time to
find the note of how to treat this; I didn't see any examples with it
present either.

Second, the first major one:

The examples tend to imply, for the most part, a canonical form to the
header, which places CFWS is only particular places. In particular, all the
examples are of the form auth-srv-id "; " method "=" result, with some
optional properties and/or reason, with one single exception (which
includes a comment in lieu of a reason). It's not immediately apparent to a
comparatively novice reader that the following header field is valid:

Authentication-Results: foo.example.net (My mailserver) / (I am number) 1
(You see) ; dkim (Because I like it) /2 (Two yay) = (wait for it) pass ;
policy (And a dot can go here) . (Like that) fruit (which surprised me) =
(because I was not expecting it) banana

I appreciate it's always nicer to only write pretty examples, but given the
specification, providing a nasty one is probably needed, lest people expect
to take a whitespace delimited token and split it on '='. For some reason I
particularly wasn't expecting the CFWS around the dot. (Maybe that's
because I'm out of practise with header parsing).

In any case, highlighting this with an example seems appropriate and useful.

Thirdly, one more major concern:

You'll note that I included a version for the method in my example above.
The definition for this, from the comments in the ABNF, suggests that this
relates to the version of RFC 5451 and successors used, but this seems
unlikely - I'm also at a loss as to what a receiving implementation should
do with such a method, since the handling of version seems to be specified
only for the version number after the auth-srv-id.

I have a vague suspicion that the correct thing to do here may be to
deprecate the method version entirely, but I might be missing something -
still, it doesn't appear to relate to the method, but the header field.

Dave.