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

"Murray S. Kucherawy" <> Wed, 27 March 2013 12:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63CD721F8FEC for <>; Wed, 27 Mar 2013 05:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.039
X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FlbPm0khnIsp for <>; Wed, 27 Mar 2013 05:56:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CF69021F8FDF for <>; Wed, 27 Mar 2013 05:56:29 -0700 (PDT)
Received: by with SMTP id a12so441078wgh.21 for <>; Wed, 27 Mar 2013 05:56:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=J4jeB/sJdegnLK1pyAu4q1HIRDO67lZKaS18knplH94=; b=msHoz7VxRYzm9dNty/NvOGC2kIwvL5RuOQ4O9T2ol4QXONNLSEezVP6NPa3YJXWMAd 55uZp8N9gnDv7Soi8q6L53CkvF530dHIwax3fNRqcVk9kgIROK32Hf1ar/SQkskgtH36 YQQHS3x5xy6WXedHhOUxl6kUegQTSZH47ha8k+qymQ6aoU0WuLRi6RVNGuaPFqwB5GpK 3VcYC6dUPeETCaV3v3Qa/NapJdGG6cEEHbMcxsU/j1NNCMslrnKQdv1rOqrHmF6vJ07+ Gtje4b30xsJKwqFoeYLhkhBjSlFok4yqqDttuB1TKDYs/D6AXyBq7lgPw6deN+wQYP12 HKrw==
MIME-Version: 1.0
X-Received: by with SMTP id wr3mr31109666wjc.35.1364388989013; Wed, 27 Mar 2013 05:56:29 -0700 (PDT)
Received: by with HTTP; Wed, 27 Mar 2013 05:56:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 27 Mar 2013 13:56:28 +0100
Message-ID: <>
From: "Murray S. Kucherawy" <>
To: Alessandro Vesely <>
Content-Type: multipart/alternative; boundary="089e013d1da8069a2104d8e7919e"
Cc: IETF Apps Discuss <>
Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Mar 2013 12:56:31 -0000

On Wed, Mar 27, 2013 at 1:15 PM, Alessandro Vesely <> wrote:

> >>> What [would transport tracing data and such be useful] for?
> >>
> >> Anything that it might be useful for.  If we think it isn't useful,
> >> then the spec should not allow it.
> >
> > So why doesn't making authserv-id a "value" accommodate that case?
> It would overkill, considering that we'd tend to discourage
> complicated stuff.  A "dot-atom" can have a slash, but perhaps we can
> live with that.  Otherwise, a "token" can be fit.

A quoted string is complicated?  They've been used in email header fields
for quite a long time now.

> >> It is quite complicated to let trusted domain's A-R pass through.
> >
> > Why is it quite complicated?  Trusted authserv-ids is merely a set of
> > strings.  If you're looking at an A-R header field whose authserv-id is
> in
> > that list, you've decided explicitly that its content can be trusted.
> > Anything else should either be ignored or removed (depending on which
> agent
> > is looking at it).
> IMHO, the first paragraph of Section 5 is too mild.  It could be
> hardened like so:
>  For security reasons, any MTA conforming to this specification MUST
>  delete any discovered instance of this header field that claims, by
>  virtue of its authentication service identifier, to have been added
>  within its trust boundary and that did not come directly from another
>  trusted MTA.
>  For security reasons, any MTA conforming to this specification MUST
>  remove or rename any instance of this header field that was not added
>  within its trust boundary.  The authentication service identifier
>  (authserv-id) is used to identify the agent which added the header
>  field, with the limits described in Section 7.1.
> If an MTA kills only the A-Rs that it can clearly identify as
> forgeries, it would let thru any A-R field bearing some unknown
> identifier.  Those identifiers may be forged.  If they match a trusted
> id at the next ADMD (MTA or MUA), then if the latter trusts the
> former, it has no obvious reason to suspect.  It gets complicated if
> one tries to derive trustworthiness from routing considerations.

If consumers are already looking only for A-Rs that use an expected
authserv-id, and ignoring others, what's the harm in letting the other ones

The document already goes as far as saying one can also remove all of them
if it chooses, just to be safe.  Renaming them is probably also fine, but
I'm skeptical about adding that here since you're renaming within a
registered namespace.

> Renaming rather than removing solves some issues with debugging and
> signature verification, so I'd consider it anyway.

True, but the agent removing suspect header fields could also log or
otherwise record them as it does so.

> I don't understand the "(border or otherwise)", still in the first
> paragraph.  If it is an internal MTA it shouldn't delete fields added
> by the border MTA of  The rest of the section becomes
> more stringent, which seems to be correct.

Yeah, I don't know what that means either.  If I can't come up with a good
reason to keep it, I'll remove it in the next version.

Here's the alternative text I promised above:
>                                               Consistently with the
>  scope limit outlined in Section 1.2, the grammar does not constrain
>  the authentication identifier to be a domain name.  Improper use
>  could thus consider appending a delimiter such as "#" and following
>  it with useful transport tracing data such as the [SMTP] queue ID or
>  a timestamp.

Isn't that materially the same as what's already in Section 2.3?