ietf
[Top] [All Lists]

Re: 2119bis

2011-09-01 19:55:28
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>