Re: [mile] Genart last call review of draft-ietf-mile-xmpp-grid-09

[Peter Saint-Andre <[e-mail]>]

Inline.

On 3/4/19 11:25 AM, Nancy Cam-Winget (ncamwing) wrote:
> Thanks Alissa and Christer, please see further comments below: 
> 
>  
> 
> On 1/4/19, 4:31 AM, "Christer Holmberg" <[e-mail]>
> wrote:
> 
>  
> 
>     Reviewer: Christer Holmberg
> 
>     Review result: Ready with Issues
> 
>    
> 
>     I am the assigned Gen-ART reviewer for this draft. The General Area
> 
>     Review Team (Gen-ART) reviews all IETF documents being processed
> 
>     by the IESG for the IETF Chair.  Please treat these comments just
> 
>     like any other last call comments.
> 
>    
> 
>     For more information, please see the FAQ at
> 
>    
> 
>     <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
>    
> 
>     Document: draft-ietf-mile-xmpp-grid-09
> 
>     Reviewer: Christer Holmberg
> 
>     Review Date: 2019-01-04
> 
>     IETF LC End Date: 2019-01-14
> 
>     IESG Telechat date: Not scheduled for a telechat
> 
>    
> 
>     Summary: The document is well written, easy to read, and technically
> I have no
> 
>     issues. However, as shown below, I do have some questions for
> clarifications.
> 
>    
> 
>     Major issues: None
> 
>    
> 
>     Minor issues:
> 
>    
> 
>     Q1: There is no explanation of what kind of security-related
> information is
> 
>     distributed. What kind of security? I assume it is some kind of
> application
> 
>     security, and not XMPP security.
> 
> [NCW] IODEF is one such exchange format that allows for security-relevant
> 
> Information to be shared.  As IODEF is “Incident Response”, it is a type
> of security information.
> 
> Once SACM has an Exchange format, we can show how that can be
> distributed using XMPP as well.

We might consider changing "security-relevant information" to something
like "information related to security incidents" and adding something
like "primiarily for the purpose of communication among between Computer
Security Incident Response Teams and associated entities".

>     Q2: Is there a reason why XMPP-Grid is only defined for security-related
> 
>     information? Isn’t XMPP-Grid a way of distributing ANY type on
> information in a
> 
>     secure manner?
> 
> [NCW] Yes it can distribute any type of information. The focus of this
> document is to show
> 
> how XMPP-Grid could be used for distributing IODEF security events.

Correct: this is a specialized application of XMPP technologies for
private communication among security teams and their associated
endpoints (etc.), not part of the public XMPP network.

>     Q3: It is not clear to me what XMPP-Grid provides that “normal”
> secure XMPP
> 
>     doesn’t. Is XMPP-Grid only an architecture, using standard XMPP
> components? If
> 
>     so, I think that should be made more clear.
> 
> [NCW] Yes, it is only an architecture that uses standard XMPP
> components.  The abstract and introduction states as much in that the
> “document describes how to use XMPP”.  We could update the first part of
> the introduction by making the following change:
> 
> “This document defines an architecture, e.g. “XMPP-Grid”as a method for
> using….
> 
> Doesthat help??

I think we also need to mention that this architecture is designed to be
used only by authorized entities.

>     Q4: While section 8 does reference RFC 6120 for the usage of TLS, I
> can’t find
> 
>     any references to other security considerations in RFC 6120. Is
> everything in
> 
>     section 8 XMPP-Grid specific?
> 
>   [NCW] Yes, Section 8 are specific to XMPP Grid architecture and the
> components of XMPP it proposes. But since the draft basically
> demonstrate the use of XMPP, it should absorb the considerations
> described in 6120 too.  We will adjust the Security considerations to
> state that as well.

+1

Peter