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

Alessandro Vesely <vesely@tana.it> Tue, 26 March 2013 19:27 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 023C421F8DBF for <apps-discuss@ietfa.amsl.com>; Tue, 26 Mar 2013 12:27:23 -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 xp3H05o72C5f for <apps-discuss@ietfa.amsl.com>; Tue, 26 Mar 2013 12:27:22 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9A621F8DC1 for <apps-discuss@ietf.org>; Tue, 26 Mar 2013 12:27:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364326040; bh=mTrb3Ze2tHb4VnIW3WwHA0bExbIB1zIKctGykViIRus=; l=7839; h=Date:From:To:References:In-Reply-To; b=mCBnD/BDA+Zh+VHCsmM12DqFtL6R9r7STHhykgVN4a05nAvLXjmyy4RJjO6q0dBh/ Nzkr47kcvW/PHFgrbRZlirTk/Q4YJLe4mSHlDUyKm2PAdcOcfzk+GaEucR1lD1ZyA6 izE2J5O3aDtyBLZmTVz+oZ0M+OQRFVfGwxM27D00=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 26 Mar 2013 20:27:20 +0100 id 00000000005DC039.000000005151F698.00003B41
Message-ID: <5151F698.60309@tana.it>
Date: Tue, 26 Mar 2013 20:27:20 +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> <CAKHUCzxfBtLTt3p3moGgEQx+p5kr=-e2Mn58xaqNvWFGiW=Lpw@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>
In-Reply-To: <CAL0qLwYU4CwN4=xFpb5wzSfjmsegxncy95KBP7M2irNf1gR1hg@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: Tue, 26 Mar 2013 19:27:23 -0000

On Tue 26/Mar/2013 16:35:28 +0100 Murray S. Kucherawy wrote:
> On Tue, Mar 26, 2013 at 5:41 AM, Alessandro Vesely <vesely@tana.it> wrote:
> 
>>>> 1. Identification of the ADMD for assessing trust relationships
>>>>    (and possibly also for POP3 MUAs to send back complaints,
>>>>    per Section 5.3 of RFC 6650),
>>>
>>> I don't see a reference to this work there.
>>
>> That possibility was voiced in the ASRG and elsewhere, but never
>> formalized --which is why I put it in parentheses.  AIUI, the
>> authentication server identifies the ADMD responsible for receiving a
>> message.  The means of identification, usually a registered domain
>> name, is consistent with the way each method identifies the ADMD(s)
>> responsible for /sending/ the message.
> 
> My point is that RFC6650 Section 5.3 says nothing about allowing POP3 MUAs
> to extract a reporting address from the Authentication-Results header
> field's authserv-id, so I don't understand why you used it as a reference.
> Such was never the intent.  It's fine to talk about it in ASRG or anywhere
> else, of course, but that's not in my view a good impetus for now adding
> that possible meaning here.

Point taken.  I mentioned it to stress that there are cases where
authserv-id is consumed outside the ADMD where it was produced.

>>>> 2. uniqueness of the identifier,
>>>
>>> This is key for identifying your own, but it doesn't speak to a
>>> necessary syntax.
>>
>> I'm dumbfounded by that statement.  How can a piece of software be
>> configured by an ADMD so as to determine whether A-Rs "have been added
>> within its trust boundary"[Section 5] if that software is unable to
>> distinguish the server id from, say, the queue id?
> 
> That logic presupposes that queue IDs have a known syntax, but they don't.
> I know of one that uses slashes and hyphens in its queue IDs, for example.

Yes,the queue id is just an example.

> But to answer your question directly, any software inside an ADMD seeking
> to use this field would be configured to look for a particular string right
> after the header field name and up to the first semicolon, and if that
> string matches the string it's looking for, then the field can (presumably)
> be trusted.

It has better be careful to exclude the queue id from the comparison.

>>>> 3. similar in syntax to a fully-qualified domain name,
>>>
>>> There's nothing saying an ADMD can't use a simple word or even a
>>> single punctuation here (so long as it fits the grammar).  Ideally
>>> it's most useful when it's in this form, but an ADMD could use "---"
>>> as an authserv-id and still get results useful to it.
>>
>> [...]
> 
> There is no obvious reason to preclude the possibility of not using a
> domain-name there either.

A domain name can be used effectively only if the consumer knows it is
a domain name.

>> One ADMD could be doing authentication service for lots of domains,
>>> but it's still one ADMD.
>>
>> It's their choice whether to masquerade or not.
> 
> Indeed.  And there's no reason to constrain such masquerading to
> "domain-name", is there?

There are pros and cons.  Similar arguments hold for the choice of
domain that an ADMD uses as d= to sign messages...

>>> If I run a service that does email authentication for tons of
>>> domains, why could I not use "Murray's Authentication Service" for
>>> an authserv-id?  Or even the empty string?  As long as the producer
>>> and consumer are consistent in their uses of it, all of your stated
>>> requirements are met.
>>
>> In principle, I agree.  However, producers and consumers can consist
>> of software developed by several independent programmers.  Those
>> agents can interoperate only if programmers agree on a common syntax,
>> so that agents can be configured in ways compatible with one another.
> 
> Isn't that the point of publishing a standard, i.e., this entire exercise?

Yes!  My point is that is a producer is allowed to stuff a queue id
somewhere besides the server id, then the consumer has better to
expect that possibility.

>>>> 4. transport tracing data such as the SMTP queue ID or a timestamp
>>>> [...]
> 
> You seem to be advocating for giving the queue ID its own token in
> the header field different from the authserv-id in a normative
> sense.

Exactly!

> What for?

Anything that it might be useful for.  If we think it isn't useful,
then the spec should not allow it.

>>>> 5. version identification,
>>>
>>> That's not part of the authserv-id itself.
>>
>> Right, it's similar to #4 in this respect.
> 
> Then I don't understand you claimed it as a separate requirement.

They are both specified.  I think it is difficult and useless to have
them both to coexist.  I'd drop the authserv-id's version.

>>>> 6. examples of valid authentication identifiers are "example.com"
>>>>    "mail.example.org", "ms1.newyork.example.com", and "example-auth".
>>>
>>> The last string in that list is not what most people think of as a
>>> fully-qualified domain name, but as you point out, it's perfectly
>>> acceptable.
>>
>> Yes, albeit that may preclude A-Rs produced that way to cross domain
>> boundaries.
> 
> I don't understand.

It is quite complicated to let trusted domain's A-R pass through.
Using identifiers that are not domain names forces an additional level
of indirection, and I'd figure average admins would rather remove them.

>> > The overall grammar is pretty clean right now: break on unescaped
>> > semicolons and you get paragraphs of useful information; the first
>> > paragraph is the authserv-id stuff, and everything else is
>> > "method=result" followed by relevant method parameters; any unescaped
>> > "/" followed by a number is a version.  Is there a reason to
>> > complicate that?
>>
>> My attempt is for simplifying, not complicating.  The "value" syntax
>> would allow:
>
> I don't see how the additional grammar you proposed previously (which was
> half a page long on my screen) simplifies anything.

Importing grammar from external sources doesn't make it simpler.

>>    Authentication-Results: "Murray's Authentication Service;
>>       used with permission since version /1. ;-)" / 2;
>>       dkim = pass header . d = example.com (...)
>>
>> You'd have to extend the acid test in C.7 to account for that.
> 
> I'm fine with extending the convoluted example to show this possibility.

And the (possibly minor) incompatibility with RFC 5451?

>>> How does it conflict?
>>
>> For example, assume my MTA is set up such that I can tell from the
>> queue id whether a message arrived to port 25 rather than 587, and I'd
>> like to use that info downstream, e.g. for logging something.  It is a
>> hack, admittedly, but the A-R producer I use happens to let me
>> configure it for appending the queue id, so I use that and roll my A-R
>> consumer hack.  Now, I also run another A-R consumer, for example
>> spamassassin, which is --will be, hopefully-- able to use existing
>> results rather than computing them from scratch.  What should it do
>> when it finds A-R-producer.my-host.my-ADMD/12345?  If that is a
>> version number that it knows nothing about, it should discard the field.
> 
> Attaching the queue ID as part of the authserv-id means you're effectively
> using a new authserv-id for every message, which is clearly not the
> intent.  It's incumbent on the consumers to figure out what that means.  I
> don't think that (or any hack) should be encoded into the document.

But then why do you write:

                                              Moreover, some
 implementations have considered appending a delimiter such as "/" and
 following it with useful transport tracing data such as the [SMTP]
 queue ID or a timestamp.
?

You can allow or prohibit that, but not both at the same time.