Subject: Injection-Info issues

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 2 Jun 2005 15:31:54 GMT

Draft-usefor-03 added proper texts for the various parameters of the
Injection-Info header, and draft-usefor-04 added <ext-param>s, and fixed a
problem with the <complainto-param>. But I still have a few issues I would
like to raise.

NOTE: There are further issues regarding the way <parameter>s are defined,
where CFWS is allowed and where quoting is needed, but I don't want to
discuss these here, because they are better resolved offline.

So, my issues:

1. We now have <ext-param>s, which allow for further parameters in
extensions. There is also a query:
   [[Should also allow for x-attributes?]]

I suggest the following text:
   <ext-params> are provided to allow additional <parameter>s to be
   defined in future extensions, and also to allow <parameter>s with
   x-attributes to be used in circumstances where the defined ones
   appear to be insufficient.

2. A major use of this header will be for killfiling by users on
particular parameters, or as an aid to detecting spams, spews, etc by
netcops (in the best sense of that term). There were a several features in
the old draft-13 to facilitate this:
   a) folding SHOULD NOT happen in silly places, and <comment>s should
come at the end (this provision is already in the draft).
   b) if several parameters are present, they SHOULD come in a prescribed
order (such as the order they are defined in the syntax) so as to
facilitate writing regular expressions.
   c) if a <post-account-param> is used, a given sender SHOULD always
show up as the same posting-account, at least in the short term.

I would like to see fetures b and c reinstated, plus an explanatory NOTE
mentioning killfiles. The texts in draft-13 could easily be reinstated or
adapted.

3. There is now a draft (with Ken's name on it) for SASL authentication
within NNTP. That may give rise AIUI to an "authorization identity" which
may or may not be in the form of a <mailbox>. An injecting agent might
then decide to use this identity in the Injection-Info header. Question:
do we need a seperate "SASL-identity" parameter for this, or can we just
use the "sender" parameter and, if so, should its syntax be extended to
suit?

4. Everyone on the WG heartily dislikes RFC 2231, and would like to
deprecate its use except where absolutely necessary. Assuming that we are
not in a position to get rid of RFC 2231 entirely (as Frank would have us
do in his parallel universe), we can still discourage its unnecessary
use. Here is a text that I have suggested before (though there may be a
better place to put it than in the Injection-Info section):

     NOTE: Although the provisions of RFC 2231 for Non-ASCII characters in
     <value>s of <parameter>s provide useful additional functionality,
     those for splitting <value>s over multiple lines offer no additional
     benefit, since the only length limit on header lines specified by
     this standard is an overall 998 octets. That latter mechanism is,
     moreover, somewhat gibbous, and as RFC 2231 itself recommends its use
     only where a real need exists, it is better avoided within Netnews.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Jun 2005 09:42:50 -0700

Charles Lindsey <[email-masked]> writes:

> within NNTP. That may give rise AIUI to an "authorization identity"
> which may or may not be in the form of a <mailbox>.

I think you mean authentication identity; authorization identity is the
thing that we had before.  The authentication identity may, in fact, may
often look like a <mailbox> but not actually be one in any traditional
sense.

> An injecting agent might then decide to use this identity in the
> Injection-Info header. Question: do we need a seperate "SASL-identity"
> parameter for this, or can we just use the "sender" parameter and, if
> so, should its syntax be extended to suit?

If anyone expects sender to be an actual mailbox, using it for the
authentication identity is a bad idea, since the authentication identity
may be indistinguishable from a mailbox but not be usable for the same
purpose.

SASL-identity is a bad choice since it unnecessarily restricts what the
field may be used for.  I'd rather use a more generic name.  The field
should be described as an opaque token that may only have meaning for the
originating site.

> deprecate its use except where absolutely necessary.

Not true.  I'm just tired of arguing about it.  I think it's a workable,
if ugly, solution to the (very hard) problem it was trying to solve, and
the *real* problem is using MIME-style parameters in places where they
don't belong.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Jun 2005 19:36:33 +0200

Charles Lindsey wrote:

 [CFWS issues for parameters]
> I don't want to discuss these here, because they are better
> resolved offline.

Is anything wrong with copying RfC 3834 opt-parameter-list ?
I'd be very interested if that's not more state of the art.

> 1. We now have <ext-param>s, which allow for further
>   parameters in extensions. There is also a query:

RfC 2231 <attribute-char> allows "x" and "-" among others.
Why reserve "x-" if there's no IANA registry ?  RfC 3834
has not a single additional word about opt-parameter-list.

>| allow <parameter>s with x-attributes

Is x-attributes a defined term ?  I know what you mean, but we
would get "[x] draft should try to avoid hacker slang" for it.

> a) folding SHOULD NOT happen in silly places

Let's better forget it.  An article format designed to simplify
"killfiling" can't be a good idea for USEFOR.  Maybe put it in
USEAGE.  Some uses of sender= or posting-account= are probably
against the law in my country, and some legal uses won't allow
"killfiling".

> b) if several parameters are present, they SHOULD come in a
>    prescribed order

See (a), it's not worth it.

> c) if a <post-account-param> is used, a given sender SHOULD
>    always show up as the same posting-account, at least in
>    the short term.

Dito, that's a legal nightmare, let's forget it, or discuss
it with some legal advisors and privacy officers - IANAL.

No idea for your point 3.  If you want to put something in a
sender= that's neither "verified" nor a mailbox you have to
allow it.  Unless this NNTP AUTH stuff has the syntactical
form of a mailbox of course.

> (as Frank would have us do in his parallel universe)

With the MUST in 2.3 I lose.  It's still strange, RfC 2822 and
mail manage to avoid this issue, why are we unable to do this ?
What's wrong with our zero-I18N newsgroup names etc., that we
still need this RfC 2231 MUSTard ?

> we can still discourage its unnecessary use

It does this by itself, we don't need to worry about this:

| IMPORTANT NOTE:  These mechanisms end up being somewhat
| gibbous when they actually are used. As such, these
| mechanisms should not be used lightly; they should be
| reserved for situations where a real need for them exists.

What we really need are some security considerations about the
MIME boundary parameter.  While we're at it we could also add
a note about the known message/partial risks, it's essentially
the same issue -  IIRC with a registered "MIME vulnerability"
number for the latter, we could even add it to the informative
references, if that's allowed and good style (?)  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 3 Jun 2005 13:40:19 GMT

>often look like a <mailbox> but not actually be one in any traditional

Whichever. I find the distinction made by the SASL standards far from
clear. Is a man allowed to choose any string he likes as his
"authorization identity", or does it have to be something previously
agreed with the server?

>may be indistinguishable from a mailbox but not be usable for the same

Yes, my feeling was that the <sender-param> was not the right place for
this.

>should be described as an opaque token that may only have meaning for the

OK, just call it "auth":

   Injection-Info: dodgy.net; posting-host=dialup-123.dodgy.net;
                   auth="some-string"

Or else use it in a "posting-account" parameter.

I just want to make sure that such authentication-identities can be used,
and that there exists a parameter clearly suitable for the purpose.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 03 Jun 2005 08:08:43 -0700

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> thing that we had before.  The authentication identity may, in fact,
>> may often look like a <mailbox> but not actually be one in any
>> traditional sense.

> "authorization identity", or does it have to be something previously

It's fairly clear if you understand the distinction between authentication
and authorization.  Authentication says who you are.  Authorization says
what you're allowed to do.  The authorization identity is the identity
you're assuming on the server and with which ACLs are associated -- it may
be, for instance, a group account shared by several people, or a role in
which you're acting.  The authentication identity is who you actually are,
namely some identified user who has access to that role.  Depending on the
authentication mechanism, the two identities may live in different
namespaces.

So, for instance, if I authenticate to my local news server with the
KERBEROS_V4 SASL mechanism, my authorization identity (the user string in
readers.conf that I'm assigned) is "[email-masked]", but my
authentication identity is "[email-masked]", which is a principal in
our Kerberos v4 realm.

Your authorization identity is generally going to be the thing that goes
into sender and the like.  Authentication identity is an additional trace
showing who was actually using a shared account or role that in many cases
will just be identical to the authorization identity.

This is fairly standard stuff in the security community, but Usenet
protocols have not, up until recently, really dealt with security in a
fashion consistent with the rest of the world.

>    Injection-Info: dodgy.net; posting-host=dialup-123.dodgy.net;

It's generally wise to never use the term "auth" in a security context
because it's ambiguous on whether you're talking about the authentication
identity or the authorization identity.  You need at least "authn" or
"authz", and it's probably better to just spell it out.

> Or else use it in a "posting-account" parameter.

That would be the authorization identity, not the authentication identity.

> I just want to make sure that such authentication-identities can be
> used, and that there exists a parameter clearly suitable for the
> purpose.

Yup.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 3 Jun 2005 12:12:52 -0400

> clear.

See FYI 36.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 3 Jun 2005 14:47:34 GMT

>I'd be very interested if that's not more state of the art.

That would cope fine with <ext-param>, but it does not help to show the
full syntax of, say, the <post-host-param> (it needs to be clear when
<quoted-string>s are needed, and that all sorts of RFC 2231 nonsense
can/may be used). The problem with RFC 3834 is that it defines no
parameters of its own, and thus sets no example of how to do so.

>has not a single additional word about opt-parameter-list.

RFC 2045 makes a special case for <x-token>s, and we want to buy into
that. But by the time we get to RFC 2231, <token>s have morphed into
<attribute>s.

>would get "[x] draft should try to avoid hacker slang" for it.

Yes, ir should be defined (RFC 2231 should have done it, but didn't).

>Let's better forget it.

Well, it's in the present text of USEFOR.

>  An article format designed to simplify

Whatever is wrong with designing formats that simplify the things that
people are going to use them for?

The Injection-Info provides a variety of paramaters, if some of them are
illegal in your country, then you will just have to use one of the others.

>See (a), it's not worth it.

It _could_ be a USEAGE matter, but it wasn't considered so in draft-13.

>it with some legal advisors and privacy officers - IANAL.

But that one definitely belongs here. It the "posting-account" parameter
runs into legal difficulties, then use a "logging-data" parameter which is
designed to be inscrutable without the cooperation of the ISP. But that is
just its problem. It is well known that spammers and other Bad Guys are
attracted to "uncooperative" ISPs (ones where abuse@ is diverted to
/dev/null, and which never make any attempt to discipline their
customers). The whole purpose of the "posting-account" parameter is to
identify the same source of articles when it turns up again (even if you
don't get to know the guy's real name or address).

We went through all these arguments when we designed the Injection-Info
header way back (see discussion in USEAGE 4.1.4). There were tensions
between those who wanted to ensure posters' privacy and those who wanted
to ensure that spammers could be traced. You cannot achieve both of those
ideals together. So the standard provides a variety of tools (some more
private than others), and it is left to the marketplace (perhaps with soe
guidance from USEAGE) to decide which of them get used.

>| reserved for situations where a real need for them exists.

Yes, but that is similar to my wording. My wording deliberately pinched
some text from RFC 2231 itself, in order to show that even RFC 2231 was
deprecating itself :-) .

>references, if that's allowed and good style (?)

Please be more specific which risks/vulnerabilities you are talking about.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 03 Jun 2005 19:28:58 +0200

> That would cope fine with <ext-param>, but it does not help
> to show the full syntax of, say, the <post-host-param>

You could also use the trick in the most recent SPF drafts -
not as good as an RfC, but the ABNF passed Bill's checker:

| header           = "Received-SPF:" [CFWS] result FWS [comment FWS]
|                    [ key-value-list ] CRLF
[...]
| key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
|                    [";"]
|
| key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )

| key              = "client-ip" / "envelope-from" / "helo" /
|                    "problem" / "receiver" / "identity" /
|                    mechanism / "x-" name / name
[.,.]
| dot-atom         = <unquoted word as per [RFC2822]>
| quoted-string    = <quoted string as per [RFC2822]>
| comment          = <comment string as per [RFC2822]>
| CFWS             = <comment or folding white space as per [RFC2822]>
| FWS              = <folding white space as per [RFC2822]>
| CRLF             = <standard end-of-line token as per [RFC2822]>

Note the ... / "x-" name / name
Argh, but stay away from "CRLF as in 2822", of course 2234bis.

Continued later, I've to Cc: this part to the SPF editor, bye.

 (it needs to be clear when

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 04 Jun 2005 02:18:48 +0200

Charles Lindsey wrote:

> RFC 2045 makes a special case for <x-token>s, and we want to
> buy into that.

2045 / 2048 define IANA registries for the Content-Type among
others, but AFAIK not for any attribute=value parameters.

And I won't buy into any "let's create another IANA registry"
scheme - unless my aim is a new IESG "[Discuss]" record... ;-)

> by the time we get to RFC 2231, <token>s have morphed into
> <attribute>s.

Our copies of 2045 are apparently not strictly identical, 2231
only adds initial-section and other-sctions to attribute, and
for that trick it removes "*" from the attribute-char set.

And maybe because they were lazy they also removed "'" and "%"
using the same attribute-char set also for the values, and not
only for the attribute.

2045 or 2231 don't do strange things with x-attributes, that's
a hallucination.  IMHO we don't need x-attributes.  As long as
the parameters are unique there's no additional 2231 problem.

> Well, it's in the present text of USEFOR.

Okay.  OTOH that's a general rule, 2.2.3 in 2822 says "folding
SHOULD be limited to placing the CRLF at higher-level syntactic
breaks".  For Injection-Info that's the semicolon.

> Whatever is wrong with designing formats that simplify the
> things that people are going to use them for?

If some Injection-Info parameters allow to identify users by
third parties without the user's consent no legit German news
server can use them, and so their potential "user-friendliness
for killfiling" is moot.  Forget it, that's irrelevant.

>>> they SHOULD come in a prescribed order
> It _could_ be a USEAGE matter

2045 says that "the ordering of parameters is not significant".

2231 adds that "while MIME does prohibit modification of MIME
headers during transport, it is still possible that parameters
will be reordered when user agent level processing is done."

If you want to "buy into" this 2231 I18N you get it wholesale.

> It the "posting-account" parameter runs into legal
> difficulties, then use a "logging-data" parameter which is
> designed to be inscrutable without the cooperation of the ISP

Okay, for USEFOR all we need is the syntax, no legal advice.

> Yes, but that is similar to my wording.

Sure, but either you want 2231 I18N, then gibbous or not it's
the way it is, or you don't want it, then the SPF trick with
its key-value-pair bypasses 2231.

Wanting 2231 and at the same time not wanting it is the weird
"MUST accept SHOULD NOT use" stuff again - I really hate this.

> Please be more specific which risks/vulnerabilities you are

http://www.kb.cert.org/vuls/id/836088

About 34,000 Google hits for "MIME partial vulnerability".  Is
US-CERT something we could reference in an IETF RfC, or is that
source too obscure ?

We could also mention the potential 2231 boundary problems and
forget the message/partial stuff, it's old news.  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 6 Jun 2005 18:23:45 GMT

>others, but AFAIK not for any attribute=value parameters.

AIUI, the IANA registry for each media type includes details of all the
parameters appropriate for that media type.

>scheme - unless my aim is a new IESG "[Discuss]" record... ;-)

No, we have not proposed an IANA Registry for Injection-Info parameters
(thoug we could if we were so minded).

>for that trick it removes "*" from the attribute-char set.

Which means that <attribute>s are different from <token>s, which is what I
said.

>a hallucination.

2045 most certainly did "strange things" with <x-token>s, and <attribute>s
inherit those same "strange things".

>  IMHO we don't need x-attributes.

Wwe have little choice. They come with the territory.

>for killfiling" is moot.  Forget it, that's irrelevant.

You just tell people that, if they post through your server, then the
Injection-Info header will identify them. If they don't like that, then
they have to go to a different server. That is the EU law (slightly
simplified, I grant you).

But for servers that don't care to include names, there are other options.
In general, the Americans are less squeamish :-( .

>2045 says that "the ordering of parameters is not significant".

Indeed, and this makes a SHOULD exception. But I have already said USEAGE
would be good enough for that bit.

>Okay, for USEFOR all we need is the syntax, no legal advice.

USEFOR doesn't give any legal advice. It just provides some facilities
which which injecting agents may or may not choose to use. There might be
some legal advice in USEAGE.

>its key-value-pair bypasses 2231.

So? My wording was quite happy for the 2231 I18N to be used. It was the
multiline stuff that was being discouraged.

>"MUST accept SHOULD NOT use" stuff again - I really hate this.

There is no "MUST accept SHOULD NOT use" wording in any text proposed for
2231, AFAIAA.

>http://www.kb.cert.org/vuls/id/836088

That vulnerability is nothing to do with RFC 2231. It affects
message/partial which is hardly used in News, so I do not see any point
even in mentioning it in Security Considerations. But if people want it
mentioned, that is no problem.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 6 Jun 2005 17:02:03 GMT

>Continued later, I've to Cc: this part to the SPF editor, bye.

Then I need to wait for your "continued later", because what you have said
gives no guidance as to which <-atom / quoted-string> is syntactically
allowed for each of the various <key>s.

For example, "client-ip" presumably expects an <IPv4address> or
<IPv6address>. "envelope-from" expects an <addr-spec>. And so on.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 6 Jun 2005 16:56:12 GMT

>authentication mechanism, the two identities may live in different

Ah! So it depends what "hat" the guy is wearing at a particular time. E.g.
Alice and Bob may both be entitled to wear the "sysadmin" hat, but each of
them is not necessarily wearing that hat each time they authenticate (they
sometimes just post as themselves). So when Alice authenticates (as
Alice), she may (or may not) claim the authorization "sysadmin", and
presumably the server knows that Alice and Bob have "sysadmin" privileges,
but that Mallet most definitely does not.

>into sender and the like.

Hmm! I am not quite convinced of that. RFC 2822 (which we follow) is
fairly clear as to what goes into the Sender header.

>That would be the authorization identity, not the authentication identity.

Ah! That makes sense.

So I propose a new Injection-Info parameter
    authentication=<value>

Would people be happy with that?

---

From: Russ Allbery <[email-masked]>
Date: Mon, 06 Jun 2005 16:05:00 -0700

Charles Lindsey <[email-masked]> writes:

> Ah! So it depends what "hat" the guy is wearing at a particular time.

Right.  The authorization identity is the "hat," so to speak, and the
authentication identity is who you proved you were in order to get to wear
the hat.

> E.g.  Alice and Bob may both be entitled to wear the "sysadmin" hat, but
> each of them is not necessarily wearing that hat each time they
> authenticate (they sometimes just post as themselves). So when Alice
> authenticates (as Alice), she may (or may not) claim the authorization
> "sysadmin", and presumably the server knows that Alice and Bob have
> "sysadmin" privileges, but that Mallet most definitely does not.

Right.

>> Your authorization identity is generally going to be the thing that
>> goes into sender and the like.

> fairly clear as to what goes into the Sender header.

Yes, it's the authorization identity:

   The "Sender:" field specifies the mailbox of the agent responsible for
   the actual transmission of the message.  For example, if a secretary
   were to send a message for another person, the mailbox of the secretary
   would appear in the "Sender:" field and the mailbox of the actual
   author would appear in the "From:" field.

What's confusing is that there is yet another level of even weaker binding
in the From header, but the key part of the above is "the agent
responsible for the actual transmission of the message."  Whether Alice or
Bob sent the message, "secretary" was the agent that sent the message.
There are just various people who are authorized to use that agent and act
as the secretary.  Alice and Bob may not even *have* their own mailboxes;
they just have separate identities in the authentication system because
that's a good security practice.

The easiest way to think about it from the security standpoint is to
observe that, in general, the *only* thing that cares about the
authentication identity is your authorization component.  Once you finish
the authentication and authorization process, the authorization identity
is the effective identity for the rest of the application; the
authentication identity is used only for the authorization process and for
internal audit trails.  Sender is intended to capture the case where one
agent sends out mail on behalf of another agent, *not* the case where
multiple people can control a single agent. Authentication identity is
very internal to the application and not generally of use or interest to
anyone outside that application except for audit purposes.

> Would people be happy with that?

Works for me.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 07 Jun 2005 03:09:16 +0200

Charles Lindsey wrote:
 
> the IANA registry for each media type includes details
> of all the parameters appropriate for that media type.

Checking draft-lilly-text-troff-04.txt and RfC 3676, yes,
it does.

> we have not proposed an IANA Registry for Injection-Info
> parameters (thoug we could if we were so minded).

Not at the moment.  Add authentication= with a reference
to the new NNTPauth, Russ said that this is a good idea.
Alexey would warn us if NNTPauth is blocked.

> Which means that <attribute>s are different from <token>s,
> which is what I said.

That didn't change "x-", 2045 had attribute := token, and
x-token is a special case of extension-token unrelated to
attribute.  

x-token is only used in mechanism (7bit, 8bit, etc.), in
subtype, and in type (indirectly), not in any parameter.

Maybe I should test x-9bit for the nonets in RfC 4042. 

> 2045 most certainly did "strange things" with <x-token>s,
> and <attribute>s inherit those same "strange things".

In my copy <attribute> comes nowhere near to any <x-token>,
<extension-token>, <iana-token>, or <ietf-token>.  It's in
"appendix A - collected grammar", the last three pages.

"x-attribute" does not exist, it's a hallucination.  If you
say that you want to create it from scratch it's fine, you
could use the SPF trick.  Or merge it with 2231 <shudder />

> You just tell people that, if they post through your server,
> then the Injection-Info header will identify them. If they
> don't like that, then they have to go to a different server.
> That is the EU law (slightly simplified, I grant you).

Anoymous and pseudonumous access is a right in a German law,
and the threads discussing this issue put together in a row
are worse than our "Re: ferences" here.  I'm not directly
affected, my favourite server is news.clara.net in the UK ;-)

> In general, the Americans are less squeamish :-( .

They can't spell privacy without a dictionary.  They don't
understand why any @gmail address is begging for a *PLONK*.

> That vulnerability is nothing to do with RFC 2231.

It's about MIME, and this part of the debate was about USEFOR
2.3 "MIME Conformance":

| User agents MUST meet the definition of MIME-conformance in
| [RFC2049] and MUST also support [RFC2231].

2049 is "minimal MIME conformance", 2231 did not update 2049.
Anyway, for USEFOR we need security considerations about 2231:

  MIME security considerations are discussed in [RFC2046].
  Note that applying some [RFC2231] extensions for parameters
  like multi-line paramters on a boundary parameter as defined
  in [RFC2046] might be abused to bypass simple algorithms
  trying to analyze MIME parts.

That's all.  Bye, Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 07 Jun 2005 10:03:53 +0200

--On 6. juni 2005 16:05 -0700 Russ Allbery <[email-masked]> wrote:

> Authentication identity is

I think Russ made a very good argument that revealing the authentication 
identity in the Injection-Info is a mistake.  Name it 
identifier-that-the-sysadmin-can-use-to-figure-out-who-sent-this, and it 
may make sense.

                       Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 7 Jun 2005 13:28:29 GMT

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>...  Add authentication= with a reference

OK, that makes 3 people happy with that idea.

>subtype, and in type (indirectly), not in any parameter.

OK, I looked again, and x-token is for use in experimental media types
(text/x-my-funny-text) and encodings (x-yenc) that have not been
standardized or registered.

RFC 2048 (which is the proper place to say such things) is silent on
x-tokens used as attributes, though the folklore is certainly that they
are available for use, and would never be standardized/registered as
such.

But, coming back to Injection-Info, there is no media type involved, so we
write whatever we think fit. In which case, I most certainly think that we
should allow x-attributes for injecting agents that wish to include
further information that does not fit into any of the categories provided
(and that is also what we said in draft-13, so we have already decided it
once).

>  trying to analyze MIME parts.

Posibly. Does anyone else want to see that written into our Security
Considerations?

---

From: Russ Allbery <[email-masked]>
Date: Tue, 07 Jun 2005 10:13:53 -0700

> identifier-that-the-sysadmin-can-use-to-figure-out-who-sent-this, and it

I think it's important to distinguish between world-wide public newsgroups
and private newsgroups for a particular organization.  It may make quite a
bit more sense to include the authentication identity in the latter.

On the other hand, don't we already have an opaque token explicitly for
the use of the local sysadmin to encode trace information?  That might be
sufficient.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 08 Jun 2005 08:29:50 +0200

Charles Lindsey wrote:
 
>> Add authentication= with a reference to the new NNTPauth,
>> Russ said that this is a good idea.  Alexey would warn us
>> if NNTPauth is blocked.
 
> OK, that makes 3 people happy with that idea.

"Happy" isn't the correct word, it's more like "I really don't
see how Sam could kill us for it, and I hope that Alexey would
warn us in time".

 [x-attribute]
> the folklore is certainly that they are available for use,
> and would never be standardized/registered as such.
[...]
> we write whatever we think fit. In which case, I most
> certainly think that we should allow x-attributes for
> injecting agents that wish to include further information
> that does not fit into any of the categories provided

Okay, where's the ABNF, key-value-pair as in SPF, or a 2231
variant of it ?

  [security considerations about 2231]
>| MIME security considerations are discussed in [RFC2046].
>| Note that applying some [RFC2231] extensions for parameters
>| like multi-line paramters on a boundary parameter as defined
>| in [RFC2046] might be abused to bypass simple algorithms
>| trying to analyze MIME parts.
 
> Posibly. Does anyone else want to see that written into our
> Security Considerations?

That was meant as a request, not only as a proposal.  But the
wording is of course open for debate.

                          Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 08 Jun 2005 09:13:04 +0200

Charles Lindsey wrote:
 
> I need to wait for your "continued later"

For the latest and greatest SPF draft published yesterday see
http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-02.txt

The weird header is in chapter 7, grmbl, still with <... 2822>
for CRLF.  

Wait a moment, usefor-04 also says that 2822 defines CRLF, now
what is this, easter-eggs for Bruce everywhere ?  The ABNF for
CRLF is in 2234bis, not in 2822.

> "client-ip" presumably expects an <IPv4address> or
> <IPv6address>

All values are either dot-atom or quoted-string, the semantical
details are explained in prose.
                               Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 8 Jun 2005 12:27:34 GMT

>identity in the Injection-Info is a mistake.

And yet, in the bit you have quoted, he appears to support the inclusion
of that parameter.

The Injection-Info provides a variety of methods of indicating the article
origin, from which injecting agents can choose what suits them.

When this header was first introduced, there were long arguments between
those who wanted to protect the poster's privacy and anonymity, and those
who wanted to prevent malefactors hiding behind their privacy walls.

The upshot was the variety of tools that you see, with the choice being
left open (because standards don't deal with privacy issues). The
discussion of the tensions between the various viewpoints was therefore
moved to USEAGE, where you can still read it.

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 8 Jun 2005 18:59:17 -0400

[...]
> wording is of course open for debate.

Wording is a problem, given the fact that 2231 (and errata) have
amended 2045 and 2046.  The issue could more accurately be phrased
as
  naive methods of handling parameters, i.e. those which do not take
  errata, RFC 2231, and more errata into account are likely to botch
  some legal MIME messages.

To keep Charles on his toes, one might also remark about the need to
correctly handle all relevant base message format (RFC 2822) constructs,
and specifically mention that "find the first semicolon" is not a
viable approach.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2005 05:24:33 +0200

[...]
>  naive methods of handling parameters, i.e. those which do not
>  take errata, RFC 2231, and more errata into account are likely
>  to botch some legal MIME messages.

But that's not the security issue.  If something botches a MIME
message you normally get some more or less unreadable text.

The security issue is that an UA might get it right, and while
it's at it it installs and starts the mail worm, or opens the
GIF bomb, or whatever else these clever UAs might do.

The security problem is the simple / naive scanner supposed to
catch this malware _before_ it meets any software from Redmond.

> To keep Charles on his toes, one might also remark about the
> need to correctly handle all relevant base message format
> (RFC 2822) constructs, and specifically mention that "find
> the first semicolon" is not a viable approach.

Are you still talking about the boundary ?  In that case it's
more a 2045 / 2046 / 2231 issue, and semicolon is no bchar.

Or are you talking about 2822 CFWS between "=" and boundary,
where this CFWS includes a semicolon ? <sigh>  Yeah, a warning
about comments before or after the boundary is an excellent
idea.  Or maybe an example:

boundary (not=me) = ("yes ;-) simple (foo;bar") ; charset=utf-8

                              Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2005 06:46:54 +0200

Frank Ellermann wrote:

No, I didn't write nothing.  The raw article is here:
http://article.gmane.org/gmane.ietf.usenet.format:28712:raw

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 10 Jun 2005 05:58:59 -0400

> message you normally get some more or less unreadable text.

As opposed to the MIME structure specified.

> GIF bomb, or whatever else these clever UAs might do.

That itself (w/o specific user input) would be a MIME violation.
 
> catch this malware _before_ it meets any software from Redmond.

Yes, because it botched MIME parsing.
 
> Are you still talking about the boundary ?

"bOuNdArY" is just one attribute name. The parsing issue applies in
general, and broken "parsing" leads to problems.
 
> where this CFWS includes a semicolon ?

Not only comments, though that's one place where a semicolon
might appear.  Parsing has to use the specified syntax, and that's
not "find the first semicolon".

> <sigh>  Yeah, a warning 

Or
 Content-Type: multipart/mixed (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2005 20:51:32 +0200

Bruce Lilly wrote:
 
>> The security problem is the simple / naive scanner supposed
>> to catch this malware _before_ it meets any software from
>> Redmond.
 
> Yes, because it botched MIME parsing.

In a simple script looking at the first 50 lines of the body I
decided to use a heuristics instead of proper parsing for the
question "is there (maybe) a B64 part starting with TV or UE ?"

In that case it would delete the rest of the mail, that's not
completely uncritical, and "popstop.cmd" is a published script.
 
> The parsing issue applies in general, and broken "parsing"
> leads to problems.

Or to heuristics.  The problem with RfC 2046 is that it doesn't
mention these issues.

>> maybe an example:

Bad example, a multipart has no charset, corrected version at
<http://article.gmane.org/gmane.ietf.usenet.format:28712:raw>

> Or Content-Type: 
>     multipart/mixed (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")

Yes, that addresses the RfC 2231 issue.  Of course it's abuse,
2231 clearly says "don't do this if it's unnecessary", and for
a boundary it is unnecessary.  But they forgot a very critical
MUST NOT in 2046 / 2231.  And with both examples it should be
clear that it's not only a 2231 problem.

The complete line is too long (81), the body (67) is okay, we
could fold it in the "security considerations":

Content-Type: 
 multipart/mixed (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
Content-Type: multipart/mixed;
 boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy

Only the puzzle, no solution, I want readers to think about it.

                    Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 10 Jun 2005 23:26:01 -0400

> a boundary it is unnecessary.
[...]

In this case since the boundary delimiter is English text it could have
been language-tagged ('en'next%20part).

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Jun 2005 18:35:10 +0200

>> that addresses the RfC 2231 issue.  Of course it's abuse,
>> 2231 clearly says "don't do this if it's unnecessary", and
>> for a boundary it is unnecessary.
> [...]

> In this case since the boundary delimiter is English text it
> could have been language-tagged ('en'next%20part).

If an implementation supports RfC 2231 it won't display / spell
check / output / ... the MIME boundary value.  So I'd still say
that it's abuse to try these tricks with a boundary.

We could roll our own "updates 2046" to nail it, but for USEFOR
a short "security consideration" is good enough:

| MIME security considerations are discussed in [RFC2046].  Note that
| applying some [RFC2231] extensions for parameters like multi-line
| paramters on a boundary parameter as defined in [RFC2046] might be
| abused to bypass
-                  simple algorithms trying to analyze MIME parts.
+                  naive methods of handling parameters.  Two examples:
+
+ Content-Type:
+  multipart/mixed (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
+ Content-Type: multipart/digest;
+  boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
+

With that provision I'm willing to accept a "MUST support RfC 2231".

                                Bye, Frank