Re: [calsify] [secdir] [Last-Call] Secdir last call review of draft-ietf-calext-ical-relations-08

On 11/16/21 20:53, Benjamin Kaduk wrote:
> Hi Michael, Catherine,
>
> Catherine -- thanks for the review!
>
> Michael -- thanks for the proposed text.  It's certainly better than
> nothing, and we could iterate further if needed.
> In particular, I wonder if we actually want to duplicate some of the
> considerations from RFC 3986 that also apply to XML references, such as the
> lack of a stability guarantee that fetching the referred-to resource will
> actually produce the same results over time and for all entities that might
> be performing the fetch operation.

Thanks Ben.

I can do that. Clearly the security section in RFC3986 is applicable to 
any URI.

For XML documents it may also be the case that  the reference is invalid 
or becomes so over time.

=== OLD ===

10.  Security Considerations

    Applications using the LINK property need to be aware of the risks
    entailed in using the URIs provided as values.  See [RFC3986] for a
    discussion of the security considerations relating to URIs.

    The CONCEPT and redefined RELATED-TO property have the same issues in
    that values may be URIs.

=== END OLD ===

=== NEW ===

10.  Security Considerations

    Applications using the LINK property need to be aware of the risks
    entailed in using the URIs provided as values.  See section 7 of
    [RFC3986] for a discussion of the security considerations relating to
    URIs.

    In particular note section 7.1 "Reliability and Consistency" of
    [RFC3986] which points out the lack of a stability guarantee for
    referenced resources.

    When the value is a REFERENCE type the targeted data is an XML
    document or portion thereof.  Consumers need to be aware of the
    security issues related to XML processing - in particular those
    related to XML entities.  See [RFC4918] - Section 20.6.  Additionally
    note that the reference may be invalid or become so over time.

    The CONCEPT and redefined RELATED-TO property have the same issues in
    that values may be URIs.

=== END NEW ===

>
> Thanks,
>
> Ben
>
> On Mon, Nov 08, 2021 at 11:55:05AM -0500, Michael Douglass wrote:
>> On 10/26/21 14:49, Catherine Meadows via Datatracker wrote:
>>> Reviewer: Catherine Meadows
>>> Review result: Has Issues
>>>
>>> This draft describes increases the expressive and scope of relationships that
>>> can be defined in iCalendar.   It updates the already existing RELATED-TO by
>>> allowing UID and URI as values and introduces a GAP parameter to specify the
>>> length of time between two events.  It also introduces three new properties:
>>> CONCEPT (roughly, category), LINK (typed reference to external meta-data or
>>> related resources), and REFID(used to identify a key that identifies all
>>> components that use that REFID).  The syntax of the relationships is given and
>>> intended use cases are described.
>>>
>>> The introduction of greater expressiveness does not by itself introduce
>>> security considerations, but the introduction of references to external sources
>>> does, specifically for URIs, which are allowed as arguments of  the RELATED-TO,
>>> CONCEPT, and LINK properties. The authors of this document are aware of this,
>>> and refer the reader to [RFC3986] for more information.  I agree that the
>>> security considerations related to use of URIs proposed in this draft are
>>> covered by this RFC.
>>>
>>> I wonder though, if the document shouldn’t concern a similar warning about the
>>> data type REFERENCE.  This refers to an XML document or a portion of an XML
>>> document.  Since XML can also be used as an attack vector, a mention in the
>>> Security Considerations Section would seem appropriate.
>> I agree with the sentiment. I thought it would be easy to find a
>> document with such a section - however the XML spec itself doesn't have
>> a security section. There is at least section 20.6 in RFC4918 (WebDAV)
>> which talks about external entities. Perhaps something like this:
>>
>> When the value is a REFERENCE type the targeted data is an XML document
>> or portion thereof. Consumers need to be aware of the security issues
>> related to XML processing - in particular those related to XML entities.
>> See RFC4918 - Section 20.6
>>
>>
>>
>>>
>>>
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki:https://trac.ietf.org/trac/sec/wiki/SecDirReview