spf at anarres
Feb 22, 2004, 11:20 AM
Post #2 of 4
(1837 views)
Permalink
|
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 [at] domain2
> ^^^^^
> 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 [at] domain # "srs0"
> srs+abcdef+domain2+domain1+user [at] domain # "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 [at] domain
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 [at] domain
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 [at] domain
> user+domain1++abcdef [at] domain
> user+domain1+domain2+abcdef [at] domain
>
> 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 [at] v2
|
