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

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Jan 2019 05:48:28 -0800

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=[email-masked]'
>              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.

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?

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 26 Jan 2019 10:48:20 -0500

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 <[email-masked]> wrote:
> 

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 

> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 26 Jan 2019 21:59:43 -0800

On Sat, Jan 26, 2019 at 7:48 AM Kathleen Moriarty <
[email-masked]> 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.
>
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> 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.
>

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.

-Ekr