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

[Eric Rescorla <[e-mail]>]

> ----------------------------------------------------------------------
> > 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?
>
>
I'm not following you here. My point is that the topics are just described
in some freeform text field, so there's no way to automatically subscribe
to them based on some taxonomy.


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

Why don't you just remove these bullets. They don't seem relevant. And
maybe sharpen that these are capabilities of the controller.

>
>
>
>
> -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.=
>
>
But unencrypted transport is forbidden by this document.
> >



> > 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.
>
>
Well, usually at this point I would just state that this is a 3552 attacker.


>
> >>     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)?
>
>
Well, I certainly hope it solves passive monitoring of the plaintext.
That's the point of TLS, after all. I agree that it doesn't stop traffic
analysis.

But it's not *me* who says it, it's this document which says it. My point
is that it's not useful to describe a bunch of threats that would happen if
this traffic were unencrypted when it's always encrypted. Anyway, this is
just a comment, so you are free to ignore.

-Ekr


>
>
> >
> >
> > 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]
> > https://www.ietf.org/mailman/listinfo/mile
>
>