Subject: RE: Submitter shown the DOR

From: Douglas Otis <[email-masked]>
Date: Fri, 16 Jul 2004 12:14:40 -0700

> On Tue, 13 Jul 2004, Douglas Otis wrote:
> >
> > Example of a Domain of Responsibility Tag:
> >
> > C: MAIL FROM:<[email-masked]>
> >      DOR:t:"ddddd.dddddd";x:"ddddd";a:"ttttt";
> >      s:"tttttttt";
> >      b:"tttttttttttttttttttttttttttttttttttt";
> >      d:"alumni.almamater.edu";
> >
> > (a:algorithm,
> >  t:time-stamp,
> >  x:expiry,
> >  b:base64 signature,
> >  s:selector,
> >  d:domain)
>
> Why not just get the originator's MSA to sign the original return path?
> This gives end-to-end authentication of the MSA, does not require any
> change to aliasing/forwarding systems or to SMTP, and works well with
> callback verification.
>
> Dave Crocker's BTAV draft is a start at a specification.

After reviewing the Bounce Address Tag Validation (BATV) specification further:
http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.html

It seems possible to constrain <original local part+timestamp>/sig-type/sig
where the local part and timestamp as to to validate the message.  The
order of these elements could be

 <localpart+timestamp>/signature/selector

where selector identifies both the algorithm and the domain key
selector.  Encryption excludes the selector where */selector may be used
to identify this type of local part address. The selector could be used
to perform the function of selecting the algorithm using a naming
convention and also selecting the key (tacked on the domain for a
DomainKey) such as selector.<domain>.  The  signature should allow the
recipient to check for forgeries where a expiry is determined by
convention as well.  Accurately accrediting the originating domain would
be possible while only requiring a single DNS access!  It could also
mean if the private portion of the key were shared with users, they
could send from any domain, but that would imply the domain was willing
to trust these individuals.  For this to be used from the MUA and the
MTA, the presents of a selector would need to override the MTA
operation.

-Doug

---

From: Tony Finch <[email-masked]>
Date: Fri, 16 Jul 2004 20:59:28 +0100

> http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.html

At the risk of being very off-topic, I'll say that I prefer a different
syntax for signed addresses than Dave's specification. I think my version
fits in with the spirit of RFC 822 better because it uses a pre-existing
token delimiter (i.e. ".") for separating parts (atoms) of the signed
email address. The following is something I sketched out in early May.
Here "ISSA" stands for "interoperable signed sender address".

    Mailbox		=	Local-part "@" Domain
    Local-part		=	Dot-string / Quoted-string
    Quoted-string	=	DQUOTE *qcontent DQUOTE
    Mailbox		=/	ISSA-Mailbox
    ISSA-Mailbox	=	ISSA-Local-part "@" Domain
    ISSA-Local-part	=	ISSA-Dot-string / ISSA-Quoted-string
    ISSA-Dot-string	=	ISSA-Prefix Dot-string
    ISSA-Quoted-string	=	DQUOTE ISSA-Prefix *qcontent DQOTE

The Dot-string or *qcontent of an ISSA-Mailbox are the same as the
Local-part of the unsigned Mailbox it is based on.

    ISSA-Prefix		=	ISSA-Tag "." ISSA-Data "."
    ISSA-Tag		=	"SSA" ISSA-Version
    ISSA-Version	=	1*DIGIT
    ISSA-Data		=	Atom

> selector.

In my syntax, the ISSA-Version number defines the both the syntax and
the verification semantics of the ISSA-Data, which includes the signature,
timestamp, and any other data required (as you suggest). ISSAs can always
be verified using an SMTP callback, but public-key ISSA-Versions may make
verification possible with just a DNS lookup. (This is where MTA
authentication ^W public key records in the DNS come in.)

This is effectively a lightweight version of DomainKeys with the
additional benefit of much better integration with already-deployed
systems. Like DomainKeys it can be extended to per-user keys (by defining
an appropriate ISSA-Version).

> It could also mean if the private portion of the key were shared with
> users, they could send from any domain, but that would imply the domain
> was willing to trust these individuals. For this to be used from the MUA
> and the MTA, the presents of a selector would need to override the MTA
> operation.

Part of the point of ISSAs is to define a family of formats so that MUA
software can in principle sign addresses on behalf of a domain or a user,
if the MTA software used by the domain supports the same format as the
MUA, and if the MUA is given the right privileged information (the private
key). It's also a way of detecting that an address is (probably) an ISSA
given no prior knowledge, and a way of recovering the unsigned address
that the ISSA is based on.

I'm planning to implement this form of forgery protection for the
University of Cambridge because it fixes all the bugs in SPF and
Sender-ID:

(1) it provides protection for my users from collateral spam without any
co-operation from the recipient of the forged spam or any other site

(2) it protects against original forgeries with a null return path

(3) it does not require any modification of forwarding services
which is important for a large percentage of my users

(4) it detects forgery before the transmission of message data without any
modifications to SMTP

(5) the same mechanism allows me to eliminate forgery within the
university

The main downside is that some filters (most frequently anti-virus email
gateways) are frequently incompetently implemented and produce malformed
auto-responses which are collateral spam without a null return path and
directed at a From: or Sender header instead of the original envelope
return path; BTAV doesn't eliminate this form of junk.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SHANNON: WESTERLY, BECOMING CYCLONIC FOR A TIME, 4 OR 5, OCCASIONALLY 6. RAIN
THEN SHOWERS. MODERATE OR GOOD.

---

From: Shevek <[email-masked]>
Date: Fri, 16 Jul 2004 21:38:24 +0100 (BST)

>  <localpart+timestamp>/signature/selector

Have the formats used by SRS and SES been considered here? There are
several arguments about format presented at
http://www.libsrs2.org/srs/srs.pdf.

Primarily, the localpart contains the largest possible character set, 
therefore it makes sense to put it last. The first few occurrences of the 
separator therefore separate (say) base32 encodings of the various special 
fields, and this separator is not a valid base32 character. Any remaining 
text is the original local part.

The ability to use a known fixed string followed by a separator character
at the beginning of the address makes it easy to identify mails with
'special' return addresses in the receiving MTA when they bounce.

S.

-- 
Shevek                                    http://www.anarres.org/
I am the Borg.                         http://www.gothnicity.org/

---

From: Tony Finch <[email-masked]>
Date: Sat, 17 Jul 2004 01:23:35 +0100

On Fri, 16 Jul 2004, Shevek wrote:
>
> Have the formats used by SRS and SES been considered here?

They are not designed for this purpose and so have a lot of irrelevant
features and wasted space. They do not allow for multiple cryptographic
algorithms, which I believe to be a requirement for Internet standards
(though I can't find the reference at the moment). They require the use of
callback verification to detect forgery, which does not scale well and is
not suitable for very widespread use on the Internet. Extensible crypto
would allow for the use of signatures verifiable by the recipient using a
public key obtained from the DNS, or per-user keys, or algorithm
replacement in case of compromise, etc.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHERLY 3 OR 4, OCCASIONALLY 5. RAIN OR THUNDERY
SHOWERS. MODERATE OR GOOD, WITH FOG PATCHES.