Mailing List Archive

On Sun, 22 Feb 2004, Brian Candler wrote:

> I have a couple of thoughts about the SRS E-mail format, while it's still
> fluid enough to be changed.
>
> (1) Why not combine the timestamp and crypto hash into a *single*, opaque
> authentication stamp?
>
> srs0+sssss+domain.com+user@domain2.com
> ^^^^^
> replaces +ttt+hhh+
>
> (This field probably contains both a timestamp and authentication hash, but
> we don't reveal it as two separate parts)

I am fairly agnostic about this particular argument. My main reason for
not doing this so far is that it becomes possible to change the size of
the timestamp and the hash independently while a separator remains between
them, and this seemed like a significant forwards compatibility advantage
when compared with the removal of one character from the local-part, which
has a 5% chance of being rejected by a PIX, if anyone is silly enough to
use one with MailGuard enabled, and Cisco haven't fixed it yet.

> My reasoning is this makes it more flexible: the sender is entitled to use
> any timestamp-encoding and/or hash-validation scheme which they choose.
> Other machines handling the mail are unlikely to make use of the timestamp
> part by themselves, and also an explicit timestampt is information which
> could be useful to spammers. So why pass it in the clear?

The information is in the clear anyway since you have to decode it, and
the standard is published. Spammers can also read. They will know the
information is bipartite, furthermore they will know which part means
what. You could encrypt the timestamp reversibly, I suppose, but then you
need to pick a reversible encryption scheme for 12 bits of data, and bolt
that onto a nonreversibly encrypted ... (complexity out of the ears for no
significant gain).

If that opaque field is a database key, then you are presumably storing
(or capable of storing) the original sender in the database, rather than
publishing it. Therefore, you might as well use some form of rewriting
which isn't required to be SRS compliant and just use the database key as
your new local part. The only reason for being SRS compliant in such a
case would be to advertise to subsequent forwarding hops that
cryptographic checks were going to be done on the return path, thus SRS0
rewrites are not necessary, and following rewrites may use SRS1 only.

> Furthermore, it allows the sender to use whatever character set or encoding
> they choose, as long as it does not include '+'. So we can end the holy wars

Er. We use = not +. Except for the first separator. But anyway...

> about base64 vs base36 vs base32; implementations can choose whichever they
> like. Equally there are no holy wars about the best timestamp format, as
> each implementation can choose their own.

I think (and hope) we've solved that war by making a decision which solved
everyone's problems with the previous decision.

> It also saves a character or two in the LHS. Comments?

One. Comment above.

> (2) The difference between srs0 and srs1 is the presence of an extra
> forwarding host, so the two formats could be unified by including an
> explicit empty field in srs0. e.g.
>
> srs+stamp+forwardhost+orighost+user
> =>
> srs+abcdef++domain1+user@domain2 # "srs0"
> srs+abcdef+domain2+domain1+user@domain3 # "srs1"

By pulling the stamp/binary field out of the SRS0 address,
we are now requiring all SRS1 code to actually interpret SRS0
addresses. Currently, this isn't actually done, and thus an SRS0
host is really free to bung whatever the hell they like in the SRS0
address. It isn't recommended, but is possible.

Considerable extra checking and error reporting would be necessary
in the SRS1 implementation: What happens if we get an invalid SRS0
address? Currently, we can implement a very neat GIGO (garbage in
garbage out), since we're guaranteed to reconstruct whatever SRS0
address we started with, irrespective of whether it was an actual
SRS0 address or not!

However, under this proposal, the flexibility within the SRS0
address would be lost: hosts would no longer be able to add locally
interpreted fields.

Look at the implementation in Guarded.pm to find out quite how little
(nothing) is really done with SRS0 addresses!

> The length of an srs0 LHS is unchanged, and srs1 is one character shorter.
>
> By explicitly saying "empty fields are equal to the RHS domain", you also
> allow a third format:
>
> srs+abcdef+++user@domain1

But if there is a subsequent hop, then the RHS domain must be reinserted
by the subsequent SRS1 hop.

> Rewriting SRS addresses on forwarding is trivial:
> - if the orighost field is empty, copy the RHS there
> - else if the forwardhost is empty, copy the RHS there

Currently it's much simpler since we don't even have to interpret the SRS0
address on the SRS1 hop.

> (3) Not really a serious suggestion, but taking this to it's logical
> conclusion, you might also just drop "srs", and treat any address which
> starts with '+' and contains four or more '+'s as SRS signed:
> +abcdef+++user@domain1

The choice of the SRS prefix was suggested by the need to pick something
not currently common on the internet. Any shorter prefix about which you
are willing to make bets would also suffice.

Starting an address with a + is likely to make qmail and sendmail shit
themselves in nasty ways.

> That depends how many people are likely to be using addresses containing
> four or more '+'s already, which I guess is minimal :-) And as a final

But a nonzero impact, therefore such a scheme would not just blend in with
the existing internet. I suggest that such backwards compatibility is a
hard requirement.

> option, if you were prepared to parse the LHS from right-to-left you could
> turn the format around:
>
> user+++abcdef@domain1
> user+domain1++abcdef@domain2
> user+domain1+domain2+abcdef@domain3
>
> But keeping the 'srs+' tag does allow for future changes, so it's probably
> worth keeping. So I'm not too bothered about (3), but I think (1) and (2)
> are worth considering.

They are of merit.

As we increase the number of possibilities for SRS address formats, and
increase the interpretation required at every step, the complexity and
reliability of the system will drop. The number of interactions between
address formats is polynomial, not linear.

Currently, there are two formats, and there is one trivial interaction
with no interpretation of the input address on forwarding. Hosts need only
ever interpret locally generated addresses. I see this as a considerable
strength of the current design.

S.

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

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Sun, Feb 22, 2004 at 06:20:48PM +0000, spf@anarres.org wrote:
> > (1) Why not combine the timestamp and crypto hash into a *single*, opaque
> > authentication stamp?
> >
> > srs0+sssss+domain.com+user@domain2.com
> > ^^^^^
> > replaces +ttt+hhh+
...
> I am fairly agnostic about this particular argument. My main reason for
> not doing this so far is that it becomes possible to change the size of
> the timestamp and the hash independently while a separator remains between
> them, and this seemed like a significant forwards compatibility advantage
> when compared with the removal of one character from the local-part

I think you can do that anyway. I'm suggesting it's entirely a private
decision at the sender how many bits of hash and how many bits of timestamp
to have; so changing the format is no more work than rotating the secret.
You just have to accept both old and new formats for an interim period. If
the length of the combined stamp has changed then you can use that length as
a selector.

> > My reasoning is this makes it more flexible: the sender is entitled to use
> > any timestamp-encoding and/or hash-validation scheme which they choose.
> > Other machines handling the mail are unlikely to make use of the timestamp
> > part by themselves, and also an explicit timestampt is information which
> > could be useful to spammers. So why pass it in the clear?
>
> The information is in the clear anyway since you have to decode it, and
> the standard is published.

The standard need not specify a particular format. Yes I agree if you just
concatenate the values using a particular implementation, which the spammer
can easily guess, then they *can* extract that information. But it doesn't
have to be in a form which is useful to them.

> You could encrypt the timestamp reversibly, I suppose, but then you
> need to pick a reversible encryption scheme for 12 bits of data, and bolt
> that onto a nonreversibly encrypted ... (complexity out of the ears for no
> significant gain).

No, you don't necessarily have to do anything that complex; just leave it up
to the implementor's ingenuity. For example:

(1) you have the option of using a timestamp format which doesn't carry
long-term information: like my previous suggestion of just 3 or 4 bits,
allowing for bounces up to 7 or 15 days old, but including the full day
number in the hash calculation. A spammer who found one of these harvested
addresses would be unable to tell whether it could be re-used today or not.

(2) you can drop the timestamp entirely, calculate the hash over [secret +
address + utime/86400], and recalculate the hash N times for the past N days
to determine if it is valid or not.

(3) you could use a local store of validation checksums, allocated at random

and probably other ideas too.

> > Furthermore, it allows the sender to use whatever character set or encoding
> > they choose, as long as it does not include '+'. So we can end the holy wars
>
> Er. We use = not +. Except for the first separator. But anyway...

Oh sorry, I didn't read that properly :-)

> > about base64 vs base36 vs base32; implementations can choose whichever they
> > like. Equally there are no holy wars about the best timestamp format, as
> > each implementation can choose their own.
>
> I think (and hope) we've solved that war by making a decision which solved
> everyone's problems with the previous decision.

I can't remember the answer, but if it was "use base64 and screw the case
sensitivity", I would strongly object. And I think so would an IETF group if
you were taking this through to proposed standard.

> As we increase the number of possibilities for SRS address formats, and
> increase the interpretation required at every step, the complexity and
> reliability of the system will drop. The number of interactions between
> address formats is polynomial, not linear.

Absolutely. And if it were not for SPF, we wouldn't care, because
intermediate hops would have no need to mangle our envelope senders; and I
remain an SPF-sceptic.

Regards,

Brian.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Mon, Feb 23, 2004 at 10:15:50AM +0000, Brian Candler wrote:
> > > srs0+sssss+domain.com+user@domain2.com
> > > ^^^^^
> > > replaces +ttt+hhh+
> ...
> > I am fairly agnostic about this particular argument. My main reason for
> > not doing this so far is that it becomes possible to change the size of
> > the timestamp and the hash independently while a separator remains between
> > them, and this seemed like a significant forwards compatibility advantage
> > when compared with the removal of one character from the local-part
>
> I think you can do that anyway. I'm suggesting it's entirely a private
> decision at the sender how many bits of hash and how many bits of timestamp
> to have

And I forgot to add: if there is a single stamp field "sssss" the
implementor is still free to define her own delimiter and split it into two
fields (e.g. "aaaa:bbb"), or more than two.

I'm saying that the standard does need to *require* it to be split into
exactly two parts, nor to dictate a particular timestamp format or character
encoding scheme.

Regards,

Brian.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com