In addition to the mechanism for defining the set of IP addresses there is
also the issue of flags and possibly operators. I think that to do this and
preserve extensibility we have to consider the possibility of additional
authentication mechanisms even though at this point we will not define their
semantics. EG:
SSL (Params)
S/MIME (Params)
If we leave asside for a moment the question of on the wire syntax it is
useful to introduce the type of notation that might be used for config of
BIND etc.
A number of flags have been proposed:
Completeness:
Is the set of IP address records or other auth method complete, such
that failure to authenticate indicates that the purported server is
definitively bogus?
Test:
The record is set up for test purposes only and may be inaccurate.
Direct Only / Phishing Target:
Mail from this domain should only be accepted direct from the
source, or possibly the weaker statement that the source is likely to be
impersonated..
Accreditation Claim (Params):
An accreditation claim is asserted with the specified parameters.
Since some syntax is necessary to express structure and since Z does not
work in email, lets use a functional style notation. I loathe S-expressions,
yeah we all know you can flatten out all operators to functions, so what?
Newton, Leibnitz and the other guys who invented math notation knew the
value of a good notation.
Question one is the level of structure we might require, can we get by with
a list or do we need some additional structure?
For example, do we need to express statements like "every email message from
anybank.com has a source IP address of 10.0.0.1 or comes from the mx server
and presents SSL authentication, and presents S/MIME authentication"? i.e.
AND (OR (MX, IP=10.0.0.1), (SSL=(params), (SMIME=(params))
We clearly need the OR operator, OR (MX, IP=10.0.0.1) etc. appear all the
time in SPF records, we are certain to want to write stuff like OR (MX,
SMIME(params)) in the future to say 'either it comes from the home mail
server OR it is SMIME signed.'
In this notation it becomes easy to say 'mail that does not authenticate MAY
still be legit'. We can simply introduce a NULL authentication mechanism,
this then allows us a lot of pretty nifty expressibility.
OR (MX, IP=10.0.0.1, NULL) translates to the IP address is definitely
genuine if it is the same as the MX record or it is equal to 10.0.0.1, but
any other value MAY be genuine.
AND (OR (MX, IP=10.0.0.1, NULL), (SSL=(params)) translates to 'here is an IP
based auth that is possibly incomplete but every legit server will always
offer SSL'.
Since OR is the more common operator, from now on I will assume it to be
implicit:
AND ((MX, IP=10.0.0.1, NULL), (SSL=(params))
Question 2: How many layers of nesting would be required?
I think the answer here is never more than 2. There is an old logic
result that says something to that effect I had to learn as undergrad. This
form may be unnecessarily verbose but this is not likely to be a big
problem, its only the IP address versions I would expect to become really
complex.
Question 3: Where do attributes go?
In trad. comp security decomposition you authenticate the subject by
whattever means and as a result find that certain attributes apply. You do
not differentiate attributes according to the mechanism used for
authentication in general, you sometimes have policies that differentiate
but not attributes. So this would indicate that we do not mix the
authentication statements and the attribute claims:
AND ((MX, IP=10.0.0.1, NULL), (SSL=(params)) CLAIM
(DNSA=class3.verisign.com)
Question 4: How do we handle Include?
There are basically two ways to handle include. This can be as a
purely lexical operator that adds in a section of text or as a referent to
an abstract data structure. This is like the difference between #include in
the C preprocessor and the using operator of C#.
The current fashion is towards the 'using' style. This has one big
advantage, it is not necessary to re-evaluate the included content each
time.
What this would mean is that
INCLUDE (inc.example.com) INCLUDE (inc.example.com) only reads the include
once. This reduces DoS potential.
We might want to have a parameter to include to allow it to be made
conditional on the from address. This would help for the bulk use case, i.e.
INCLUDE (from=customerservice)