Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-02.txt

"Murray S. Kucherawy" <superuser@gmail.com> Sat, 18 May 2013 23:06 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 90C9021F8C40 for <apps-discuss@ietfa.amsl.com>; Sat, 18 May 2013 16:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.397
X-Spam-Level:
X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 OHh5jFLHc14M for <apps-discuss@ietfa.amsl.com>; Sat, 18 May 2013 16:06:54 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 393F321F8C38 for <apps-discuss@ietf.org>; Sat, 18 May 2013 16:06:54 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id hr14so1171731wib.16 for <apps-discuss@ietf.org>; Sat, 18 May 2013 16:06:53 -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=8/lU/IQ+QWj5MlishLVvDRUJn7e+DiAwS5GPE5mBgBc=; b=PKKmTE+5ss9soGY0mEbtfC2DEgwT4AVXfbs2nEJKiNEYxrjoQ/XpYuXLVGbqf+vPOS L8DT4KB997W/LPiGcl4rqpd76IIzzVFceDgvvg+nsKZKLzPUzc3yYY4OwkXqdHBJPIYt KMBd1v7dq5dtyYmff5Ht0dRGoyt/bqEk/QvgAPydbOd9dak5IL8Dy3sqcJyDK77wLi85 KM/eZlRPmEZpeRJlhL5vX9B0t3q6JQubxhc0T8UPlObTJ9jeExyBaJOEWRRHYYE2SQJo x6vyomA3IbCwEQy4Rh/xqPPAERUKgHqOVZnI3WrCW34JMKw90Br4j8c7U51BzjS+D1Px Ucng==
MIME-Version: 1.0
X-Received: by 10.194.123.165 with SMTP id mb5mr7196602wjb.15.1368918413173; Sat, 18 May 2013 16:06:53 -0700 (PDT)
Received: by 10.180.14.34 with HTTP; Sat, 18 May 2013 16:06:53 -0700 (PDT)
In-Reply-To: <1675160.H9MT8MA6B2@scott-latitude-e6320>
References: <20130513045342.14228.40090.idtracker@ietfa.amsl.com> <1675160.H9MT8MA6B2@scott-latitude-e6320>
Date: Sat, 18 May 2013 16:06:53 -0700
Message-ID: <CAL0qLwZuMOky2rLBm4UYhgNJmyXaPyO25WhBGrrgK4DUKcAWqg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Scott Kitterman <scott@kitterman.com>
Content-Type: multipart/alternative; boundary="089e011831a8be6be704dd0627dd"
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-02.txt
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: Sat, 18 May 2013 23:06:55 -0000

On Fri, May 17, 2013 at 3:22 PM, Scott Kitterman <scott@kitterman.com>wrote:

> Comments:
>
> >    At the time of publication of this document, Author Domain Signing
> >    Practices ([ADSP]), SMTP Service Extension for Authentication
> >    ([AUTH]), DomainKeys Identified Mail Signatures ([DKIM])>, Sender
> >    Policy Framework ([SPF]), and Vouch-By-Reference ([VBR]) are
> >    published DNS domain-level email authentication methods in common
> >    use.  DomainKeys ([DOMAINKEYS]) and Sender ID ([SENDERID] are also
> >    referenced here, though they respectively have "Historic" and
> >    "Experimental" status, and are no longer common.
>
> I've also seen iprev in the wild and it's supported by the python authres
> module I helped develop.  We've also implemented DMARC based on the latest
> draft.  Iprev is in 5451, so I think it should be mentioned.
>
>
OK.


> >    Although SPF defined a header field called "Received-SPF" and
> >    DomainKeys defined one called "DomainKey-Status" for this purpose,
> >    those header fields are specific to the conveyance of their
> >    respective results only and thus are insufficient to satisfy the
> >    requirements enumerated below.  In addition, many SPF implementations
> >    have adopted the header field specified below, and DomainKeys has
> >    been obsoleted by DKIM.
>
> I think this overstates things with respect to SPF.  Most implementations
> have
> not adopted authres and even in the cases where they have, it's an option,
> not
> the default.
>

Seems to me adding "at least as an option" with respect to the SPF
implementations is probably sufficient.


>
> In the ABNF:
>
> I believe the change from:
>
> authres-header = "Authentication-Results:" [CFWS] authserv-id
>         [ CFWS version ]
>
> to:
>
> authres-header = "Authentication-Results:" [CFWS] authserv-id
>         [ [CFWS] "/" [CFWS] authres-version ]
>
> is an incompatible change and if you really want to make it, you should
> bump
> the version number.  I checked and with authres, your example is
> mis-parsed.
>
>         Authentication-Results: example.org/1; none
>
> In this example, the authserv-id is "example.org", but authres, using the
> RFC
> 5451 ABNF parses this and determines the authserv-id is "example.org/1"
>
> If you want to make this change, I think it needs to be version 2 because
> an
> existing version 1 parser can't parse the header field anymore.  Actually,
> I'm
> not sure that helps since a version 1 parser would fail to determine the
> message version.  I think you need to specif a minimum of one space between
> the authserv-id and the "/" for backward compatibility.
>
> The first two are editorial.  The last one is significant.  It's possible
> we
> implemented it wrong in authres, but that's how it looks for the moment.
> Let's discuss.
>
>
I made that change on two premises:

1) I've yet to see a single implementation that includes a version number
in its output, though there are some that do look for it.  It seems to me
it's a safe change to make on that basis.

2) The way versioning is done at that point in the header field is
inconsistent with where it's done adjacent to the methods.  It's nicer on
the eyes and easier for parsers if they're done the same way.  I consider
this a bug in RFC5451.  I never opened an erratum for this before just
fixing it in the -bis draft, but I think I probably should have.

I'd hate to see this recycle at PS just for this change, so either I can
back it out, or we could call it a bug fixed in this draft and leave the
version alone.  Although you're correct that strictly speaking it's
incompatible, it only affects consumers regarding a currently unused
protocol feature.

Does anyone else have an opinion here?

-MSK