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

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Hi EKR
(and thanks Kathleen for helping!),  please see further comments below:

From: Eric Rescorla <[e-mail]>
Date: Saturday, January 26, 2019 at 22:00
To: Kathleen Moriarty <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [mile] Eric Rescorla's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)
Resent-From: <[e-mail]>
Resent-To: "Nancy (ncamwing)" <[e-mail]>, Syam Appala <[e-mail]>, "Scott (scottp)" <[e-mail]>, <[e-mail]>
Resent-Date: Saturday, January 26, 2019 at 22:00



On Sat, Jan 26, 2019 at 7:48 AM Kathleen Moriarty <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-mile-xmpp-grid-09: Discuss
>
> ----------------------------------------------------------------------
> 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?
[NCW] It is a normative reference. Noted in Section 12.1 (e.g. Normative references)

>
>
> 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.

[NCW] Yes, it is a MUST as that is how the namespace is provided.

We can add a sentence after the “result” XML to state that the platform (e.g. consumer) can then
Discover the topics through the supported namespaces in the result.

>
>
>
> 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?

 [NCW] Thank you for catching this.  I’ve cleaned up the paragraph, so hopefully it is more readable now.

>
>
> ----------------------------------------------------------------------
> 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.
[NCW] The response itself doesn’t provide a full description of the topic, but further in Section 5
We do describe how the broker responds with the supported namespace.  Is that not sufficient?

>
>
> 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.

[NCW] We can clarify that this is an IODEF formatted incident by stating:

“Third, a Provider would publish an incident to the broker on MILEHost topic as follows:”

So that should be understood from the document that MILEHost is carrying the IODEF payload.

As to the format we do state after the snippet example that the payload is in adherence to

IODEF, e.g. RFC7970 and RFC 8274.


>
>
> 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?

[NCW] Yes. The expectation is the consumer, would understand RFC7970 and RFC8274

To be able to interpret the data.  XMPP is a pubsub mechanism so previous sections describe

How to discover the different topics (payloads) that are available by the Providers.


>
>
> 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"

[NCW] Thanks for pointing this out. We will fix it in the next revision.


>
>
> 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.
[NCW] We’ve updated the beginning of that section to describe the need for the CA.

>
>
> 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.

Thanks. I agree that TLS doesn't address attack by the XMPP relay servers and that object level encryption would help. What's confusing here, at least to me, however, is that this section is entitled "Network Attacks" and there is a separate section (8.2.2) that talks about what the XMPP-Grid-Controller can do. Moreover S 8.3.1 talks about requiring TLS and says "These protocol security measures provide protection against all the  network attacks listed in the above document section [I'm assuming 8.2.1 -- EKR] except denial of service attacks." So, these are odd read in context.

[NCW] I’m open to suggestions on reworking or shuffling to improve readability


-Ekr


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?

[NCW] Yes, it is only the case with unencrypted transport.


>
>
> 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.

[NCW] Actually Section 8.2 presents the Threat Model and the issues whereas

Section 8.3 presents the countermeasures to the issues.


>
>
> 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?

[NCW] As this is based on the current XMPP which uses TLS 1.2, I’m not sure we can make such a recommendation?


>
>
> 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

[NCW] I am not sure why you believe TLS solves passive monitoring (especially of metadata or general traffic analysis as noted above)?


>
>
> 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?

[NCW] No. It is Chris Inacio.


>
>
> _______________________________________________
> mile mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mile