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

[Benjamin Kaduk <[e-mail]>]

Hi Michael,

Looks great.  Many thanks for putting it together!

-Ben

On Mon, Nov 22, 2021 at 11:45:36PM -0500, Michael Douglass wrote:
> 
> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/secdir
> >> wiki:https://trac.ietf.org/trac/sec/wiki/SecDirReview