On Mon, Sep 26, 2011 at 10:06 PM, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Hi Robert,
Robert Burrell Donkin wrote:
On Sat, Sep 24, 2011 at 4:08 PM, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Aaron Stone wrote:
<snip>
In the case of a MUST, it means that a valid includes implementation
imposes a script naming restriction. If a site isn't using
managesieve, would that site really need to accept the name
restrictions?
If you don't make it a MUST, then nobody can be relied upon the rule.
I'm a little unclear why allowing people to rely on this rule should
be seen as good thing...
1. Can anyone think of a use case that could be satisfied best by an
author intentionally including a restricted script name?
ManageSieve script names are quite permissive: basically various control
characters are disallowed. IMHO, disallowing control characters in script
names is a good thing.
(I'd like to avoid second guessing the design choices made in RFC5804)
I just wanted to understand what benefit (if any) changing SHOULD to
MUST has for script authors. I assume this silence means there is no
benefit.
2. Allowing implementors to rely on this rule may create a false sense
of security, and so may encourage them to neglect proper checks on
names before accessing their backing store. What are the positive
benefits that outweigh this risk?
Quite the opposite: if the rule is a MUST, then implementations can validate
names and reject invalid ones.
Any reasonable, security-conscious implementation will reject
malicious names whether this action is allowed by the specification or
not. A well written, security-conscious specification would
acknowledge this behaviour and permit it.
A reasonable implementation supporting a related standard (whether
RFC5804 or some other future standard) will reject and allow script
names for reasons of compatibility whether this action is allowed by
the specification or not. A durable specification would acknowledge
this behaviour and permit it.
Therefore, I believe that authoring tools should strictly validate to
ensure wide portability but that servers should be allowed more
freedom for reasons of security and compatibility. So, I think that
perhaps something like [1] would be an improvement.
Robert
"Be conservative in what you do, be liberal in what you accept from
others." - Jon Postel
[1]
<original>
Implementations MUST restrict script
names according to MANAGESIEVE [RFC5804], Section 1.6. The script
name argument MUST be a constant string as defined in VARIABLES
[RFC5229], Section 3;
</original>
<replacement>
Before resource resolution, implementations MUST validate script
names. Before attempting to access the resolved resource, if an
invalid name is detected implementations MUST terminate execution by
raising an error. A name is invalid when:
* name resolution could compromise the security of the backing storage; or
* the name is incompatible with one or more standard supported by the
implementation.
After resource resolution, implementations MUST verify the rights of
the script owner to access this resource. If access is not permitted,
implementations MUST terminate execution by raising a runtime-error.
Creators of script authoring tools SHOULD validate script names to
ensure portability and MUST restrict script names
* to constant strings as defined in VARIABLES [RFC5229], Section 3;
* to MANAGESIEVE [RFC5804], Section 1.6.
</replacement>
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve