Subject: Re: [Asrg] ASRG session at IETF

From: John Levine <[email-masked]>
Date: 24 Feb 2006 23:30:04 -0000

>Kind of sad that the asrg wiki is closed due to authentication
>problems, considering that authentication in wikis is a solved
>problem.

It'd be easy enough to put a wiki back up, but I figured that since
nobody had used it for several months, it wasn't worth the effort.

>I would be happy to synthesize what I recall into a rough draft (not
> a strawman

Feel free to call it whatever you want.  In IETF usage a strawman is
a draft intended to draw out opinions for further synthesis.

>Are there grants available for such things?

You're welcome to 100% of the $0 that all of us IRTF chairs get paid.

R's,
John

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "David Nicol" <[email-masked]>
Date: Tue, 28 Feb 2006 10:29:05 -0600

> a draft intended to draw out opinions for further synthesis.

With worries, remembering the time that a magazine editor responded
to my e-mailing him an article, with the question "I got the message,
but where's the article?" and then quoted the article text, here's your
straw man tagging proposal, which is essentially SJMDP

http://article.gmane.org/gmane.ietf.asrg.filtering/270

generalized to all tags, not just "junk" and with a verification method
described.  The verification protocol, GPTPV, is expected to compete
with a header line verification protocol that I don't know the rfc number for
and may or may not exist.

BEGIN NOTES DESCRIBING GENERAL PURPOSE TAGGING PROTOCOL (GPTP)

PRONOUNCIATION OF GPTP

Jeepy-tipi, alluding to the struggles of the Lakota.

HEADERS CONSIST OF LINES

e-mail headers consist of lines, which may become unordered, but which
remain intact, except for stretching whitespace as needed to wrap them
onto multiple length-limited SMTP lines as needed.

NORMALIZING WHITESPACE IN HEADER LINES BEFORE DIGESTING

part of GPTP describes taking hash-digests of header lines.  All whitespace
in a header line MUST be normalized to a single 0x20 space byte before
taking a digest.

KEY/VALUE PAIRS IN HEADER LINES

key/value pairs in a GPTP line are of the form

     KEY=VALUE;

where KEY matches the perl5 regex /^[a-zA-Z]\w*$/
and VALUE matches /^[A-Za-z0-9\.\-\_\ ]$/

The character sets here are a starting point -- someone who is better
at internationalization and whatnot should rewrite this bit.  Anyway, the
line is a sequence of key/value pairs and the value might have whitespace in it
so each pair is terminated with a termination char of some kind, such
as the semicolon.

HEADER LINE NAME

GPTP header lines are of the forms

      Is-TAG: (pairs)
      Old-Is-TAG: (pairs)
      If-TAG: (pairs)
      Old-If-TAG: (pairs)
      Is-Not-TAG: (pairs)
      Old-Is-Not-TAG: (pairs)
      If-Not-TAG: (pairs)
      Old-If-Not-TAG: (pairs)

A GPTPV proxy header, Verified:, is described as well.

where TAG is a kind of tag, of which a central registry of tags is maintained,
and new tags can be made for experimentation by prefixing X-VENDORSTRING-
to the name of the tag, so instaed of SA adding X-SPAM-Status: lines,
a compliant SA, still without Status appearing in the central registry, might
look like

Is-X-Spam-Junk: status=junk; salt=lkjh; origin=tagger.example.com; time=Fri, 24
   Feb 2006 15:56:04 -0800 (PST); p=95; q=05; digest=MD5,SHA1

whereas were Junk one of the registered tags, the line might look like

Is-Junk: status=junk; salt=lkjh23kjgb3; origin=tagger.example.com; time=Fri, 24
   Feb 2006 15:56:04 -0800 (PST); p=945; q=052; agent=exospam; version=0.93;
   digest=MD5,SHA1

VERIFICATION METHOD

to verify a gptp line, contact the origin host as listed, which should provide
an ESMTP greeting including a new capability, GPTPV, which stands for
GPTP Verification.  Origin value spec may include a port number so the
GPTPV can be on its own port instead of getting mixed up with ESMTP.

Anyway, the GPTPV protocol works by the client presenting the salt from
a GPTP line, and the server responds with a list of digest values, which is
all digest values associated with that salt, using the digest methods listed
on the lines.

Tagging agents are expected to use the same salt for all GPTP lines in
the same group, and to make a new random salt for every message that
is processed.

Why GPTPV works to verify a header line came from an origin:

digests are one-way functions.  What GPTPV does is essentially the same
as classic unix password encryption, with the full text of the header line
after normalizing whitespace and lopping an Old- prefix if any, used as the
encrypted password.  By connecting to the origin as claimed in the line
itself, forgery will be difficult without a dns attack or something like that.

GPTPV avoids key management issues involved in cryptographic signatures.

the database load in providing GPTPV service is small, as is the
communication load.

WHAT TO DIGEST:

lop the 'Old-' prefix, if it is there, normalize all whitespace, lop
the trailing newline,
digest what's left.

THE OLD- PREFIX

when a tagging agent processes a message that already has tags of the type
that it adds, it may rewrite them by prefixing Old- to them rather
than discarding
them.

Is-

Is-TAG means that TAG applies to the tagged message.

Is-Not-

Is-Not-TAG means that TAG would not apply to the tagged message.

If-

If-TAG provides instructions for tuning the tagging engine, which
something is tagged as Is-Not but you think it should be tagged as Is.

If-Not-

If-Not-TAG for tuning the other way

Instructions in If and If-Not tags contain URIs or e-mail addresses, as contents
of key-value pairs.  If- lines and Is- lines that are concerned with
the same designation
should have the same salt.

P and Q

when provided, the p key means confidence in the is- direction and the q value
means confidence in the is-not direction.  p and q mean the same in both is and
is-not lines.  P and Q both can be interpreted by prefixing 0. to
them.  There is
no limit on their length.  They (after predixing zero-dot) do not need
to sum to 1.0.

Verified-SALT line

A host that has performed GPTPV verification on a salt/origin set may include
that result in a header line of the form

Verified: vsalt=sfgkjbafglkhjbgrs;
origin=intermediate.host.example.org; salt=kjub;
    alg=SHA1; digest=rtwrterwq,dshsdty5ey,qaewrtaqwert,gsfagasg;

in which (vsalt) is the salt that was verified, (salt) is the salt on
this line in case you
want to verify it against this line's origin, (alg) is the digest alg
supported by (origin),
(digest) contains the list of digests which match lines with a salt of (vsalt).

Agent

an agent key identifies the software providing the designation

Version

the version of the agent

Time

the time at which the line was added

Adding GPTPV data to non-GPTP header lines and the non-interdependence
of GPTPV to GPTP

GPTP is concerned with the Is- and If- and Old- lines.  Anti-forgery measures
of some kind are important.  GPTPV is a proposal for an anti-forgery measure.
Adding salt=PAIR; to any old header line (such as Received:) in order
to GPTPV-enable
it is entirely possible and practical:  GPTPV uses the origin, alg, and salt
key/value pairs.  When any header line at all has those three keys in
it, a GPTPV
operation can be performed on it by connecting to the origin host, presenting
the salt, and comparing the digests given in the response against a digest of
the normalized line, made with the specified alg(s).

Before:
    Received: by 10.11.120.36 with HTTP; Fri, 24 Feb 2006 15:56:04 -0800 (PST)

After:
    Received: by 10.11.120.36 with HTTP; Fri, 24 Feb 2006 15:56:04 -0800 (PST);
       origin=gptpv.gmail.com; salt=654165khgc; alg=md5;

COPYRIGHT AND LICENSE GRANT:

the above is a draft proposal suitable for discussion.  It is
copyright 2006 david nicol
and publicly licensed for use as a standards-track protocol document, including
required assignment of license for creation of derivative works as
appropriate to
the standards process, provided that David Nicol, Tipjar LLC, Post
office box 45163,
kansas city, missouri USA 64171-8163 remains associated with the derivative work
in lettering no smaller than that used to identify subsequent authors.

END OF DRAFT PROPOSAL