Michael StJohns wrote:
There are at least two different classes of things where "SHOULD"
can be applied: behavior and feature.
The feature "SHOULD" tends to have less to quibble about - "An SMTP
server SHOULD implement DKIM and 8BITMIME" - and tends not so much to
need an "UNLESS" clause.
The behavior "SHOULD" absent a description of the "UNLESS" clause
tends to have a bit more downside:
"A DNSSEC aware recursive resolver SHOULD set the CD bit in an
upstream query" vs either
"A DNSSEC aware recursive resolver MUST set the CD bit in an
upstream query"
or
"A DNSSEC aware recursive resolver SHOULD set the CD bit in an
upstream query UNLESS specifically configured by policy not to"
That's just an example I'm particularly aware of (and the specific
language has a few more clauses).
Good points, but the subtleties are too wide spread to generalize,
especially dealing with integrated protocols and now there are
boundary layers related issues.
For example:
DKIM MUST|SHOULD|MAY validate its input stream for illegal
multiple 8222.From fields because this has been shown to cause
a potential security exploit.
or you can pass the buck in the name of fast tracking PS to IS, cross
the border with this concept:
SMTP Receivers MUST|SHOULD|MUST check for valid RFC5322 input
before feeding the stream to DKIM.
Some people view this as a boundary layer problem, others don't.
Some people (like me) see it a major security problem that negates
DKIM goals hence from an Software Engineering, Black Box IN/OUT
concept, believe DKIM has responsibility to validate its key input
fields especially when DKIM already had a strong security related mandate:
DKIM MUST hash-bind the 5322.FROM header to the signature.
And it is an RFC5322 violation to have two or more 5322.FROM fields.
But some believe its a boundary layer issue, don't believe its a
responsibility for security-based protocol called DKIM to make sure
there is no security violations in its blind input of RFC5322 data.
In this case, a SMTP server will probably do already, but can't
guarantee this? I don't think so and even when it does, there are
known illustrated cases where DKIM was used to bypass the SMTP RFC5322
check and as a result a double 5322.FROM were possible where the fake
5322.From was displayed to the user and DKIM signature was still valid
by hashing the original, but now hidden, 5322.From field.
Go figure.
--
HLS
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf