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

[Alessandro Vesely <[e-mail]>]

On Tue 26/Mar/2013 16:35:28 +0100 Murray S. Kucherawy wrote:
> On Tue, Mar 26, 2013 at 5:41 AM, Alessandro Vesely <[e-mail]> 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.