Re: [mile] Eric Rescorla's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)

[Kathleen Moriarty <[e-mail]>]

Just trying to help on some of the comments as one point in the draft may need further clarification in the draft if EKR is raising this point since he knows the underlying protocol.

Sent from my mobile device

> On Jan 24, 2019, at 8:48 AM, Eric Rescorla <[e-mail]> wrote:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-mile-xmpp-grid-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4730
> 
> 
> I have marked a number of places where I do not consider this fully
> specified.
> 
> DETAIL
> S 4.
>>             |                      | Request Topic Creation  |
>>             |                      | (XEP-0060)              |
>>             |                      |<------------------------|
>>             |                      | Topic Creation Success  |
>>             |                      | (XEP-0060)              |
>>             |                      |------------------------>|
> 
> Why Isn't XEP-0060 a normative reference?
> 
> 
> S 5.
>>     </iq>
>> 
>>     The Broker responds with the "disco#info" description, which SHOULD
>>     include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field
>>     that specifies the supported namespace (in this example, the IODEF
>>     namespace defined in [RFC7970]):
> 
> This seems underspecified.  What does the consumer look at to
> "determine the exact nature of each topic"? This text implies it's the
> 'pubsub#type' but doesn't quite say so. I am imagining changing this
> SHOULD to a MUST and then stating how the consumer behaves.
> 
> 
> 
> S 8.3.1.
>>     mechanism [RFC4422] or using the SASL SCRAM mechanism (with the
>>     SCRAM-SHA-256-PLUS variant being preferred over the SCRAM-SHA-256
>>     variant and SHA-256 variants [RFC7677] being preferred over SHA-1
>>     varients [RFC5802]).  XMPP-Grid Platforms and XMPP-Grid Controllers
>>     using mutual certificate-based authentication SHOULD each verify the
>>     revocation status of the other party's certificate.  All XMPP-Grid
> 
> I am having trouble reading these two sentences together. Is the
> implication that I must use SCRAM and may also use mutual certificate
> auth?
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> S 5.
>>         <item node='NEA1'
>>               name='Endpoint Posture Information'
>>               jid='broker.security-grid.example'/>
>>         <item node='MILEHost'
>>               name='MILE Host Data'
>>               jid='broker.security-grid.example'/>
> 
> Assuming I am understanding this correctly, there's no machine-
> readable description of the topics; they are just freeform
> descriptions and then some human has to decide what to consume.
> Assuming that's correct you should state it upfront.
> 
> 
> S 6.
>>             jid='[e-mail]'
>>             subscription='subscribed'/>
>>       </pubsub>
>>     </iq>
>> 
>>     Third, a Provider would publish an incident as follows:
> 
> The "as follows" here also seems underspecified. You need to define
> exactly where the payload goes and what permitted payloads are.
> 
> 
> S 6.
>>        </publish>
>>      </pubsub>
>>    </iq>
>> 
>>     (The payload in the foregoing example is from [RFC7970]; payloads for
>>     additional use cases can be found in [RFC8274].)
> 
> Just to be clear: there's no negotiation here or even advertisement of
> payload types? The Consumer just takes whatever it gets?
> 
> 
> S 6.
>> 
>>     (The payload in the foregoing example is from [RFC7970]; payloads for
>>     additional use cases can be found in [RFC8274].)
>> 
>>     The Broker would then deliver that incident report to all Consumers
>>     who are subscribe to the Topic:
> 
> Nit: "are subscribed"
> 
> 
> S 8.1.4.
>> 
>>  8.1.4.  Certification Authority
>> 
>>     The Certification Authority (CA) that issues certificates for the
>>     XMPP-Grid Controller and/or XMPP-Grid Platforms (or each CA, if there
>>     are several) is trusted to:
> 
> Well, any trusted CA, whether or not it is actually issuing
> certificates.
> 
> 
> S 8.2.1.
>>     o  Network traffic can be passively monitored to glean information
>>        from any unencrypted traffic
>> 
>>     o  Even if all traffic is encrypted, valuable information can be
>>        gained by traffic analysis (volume, timing, source and destination
>>        addresses, etc.)
> 
> This text is kind of misleading because below you require TLS.
> 

The point here is that data is exposed at relays and a grid is used where data may be exposed on XMPP servers that are not the source or destination.  The need for object level encryption is important when sensitive data is exchanged.

If this is clearer, then it addresses several comments as TLS doesn’t suffice in this case.

Best regards,
Kathleen 

> 
> S 8.2.1.
>>     o  Network traffic can be blocked, perhaps selectively
>> 
>>     o  A "Man In The Middle" (MITM) attack can be mounted where an
>>        attacker interposes itself between two communicating parties and
>>        poses as the other end to either party or impersonates the other
>>        end to either or both parties
> 
> How would this be possible? Is it only in the case of unencrypted
> transport or something else?
> 
> 
> S 8.3.1.
>> 
>>  8.3.1.  Securing the XMPP-Grid Data Transfer Protocol
>> 
>>     To address network attacks, the XMPP-Grid data transfer protocol
>>     described in this document requires that the XMPP-Grid messages MUST
>>     be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in
> 
> It would have been useful to state this earlier.
> 
> 
> S 8.3.1.
>>  8.3.1.  Securing the XMPP-Grid Data Transfer Protocol
>> 
>>     To address network attacks, the XMPP-Grid data transfer protocol
>>     described in this document requires that the XMPP-Grid messages MUST
>>     be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in
>>     [RFC6120] and updated by [RFC7590].  The XMPP-Grid Platform MUST
> 
> Perhaps you should require 1.3 at this point?
> 
> 
> S 8.3.1.
>>     authentication technique to use in any particular deployment is left
>>     to the administrator.
>> 
>>     These protocol security measures provide protection against all the
>>     network attacks listed in the above document section except denial of
>>     service attacks.  If protection against these denial of service
> 
> This is a bit hard to read in context. It seems almost like you wrote
> the "network attacks" section as if TLS wasn't required and then added
> the TLS requirement? In any case, if all those attacks are prevented,
> I would rewrite that section
> 
> 
> S 11.
>> 
>>     The authors would like to acknowledge the contributions, authoring
>>     and/or editing of the following people: Joseph Salowey, Lisa
>>     Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay,
>>     Steve Hanna, and Steve Venema.  In addition, we want to thank Takeshi
>>     Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave
> 
> "Ignacio", right?
> 
> 
> _______________________________________________
> mile mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mile