Re: Working group last call on draft-ietf-sieve-include

Robert,

Robert Burrell Donkin wrote:

>On Mon, Sep 26, 2011 at 10:06 PM, Alexey Melnikov
><[email protected]> wrote:
>  
>
>>Hi Robert,
>>
>>Robert Burrell Donkin wrote:    
>>
>>>On Sat, Sep 24, 2011 at 4:08 PM, Alexey Melnikov
>>><[email protected]> 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?
>>>
This question looks entirely backwards to me.

>>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 don't see any point of having requirement on script authors (humans). 
However I believe knowing exact syntax and limitations has benefits for 
agents that generate and validate scripts.

>I assume this silence means there is no benefit.
>
SHOULD is pointless for syntactic restrictions, because no agent can 
rely that it will be complied with.

>>>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.
>
If you are arguing that these things are obvious and thus must not be 
document, then I strongly disagree.

>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.
>
This MUST is insufficient to have two interoperable implementations, 
because it doesn't suggest how this can be achieved. Unless the text 
below is really trying to explain how this can be done.

The rest of your proposed text seems Ok.

>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
[email protected]
https://www.ietf.org/mailman/listinfo/sieve