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

Eric Rescorla <ekr@rtfm.com> Thu, 24 January 2019 13:48 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: mile@ietf.org
Delivered-To: mile@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CB1130F16; Thu, 24 Jan 2019 05:48:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-mile-xmpp-grid@ietf.org, mile-chairs@tools.ietf.org, takeshi_takahashi@nict.go.jp, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, mile-chairs@ietf.org, mile@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.90.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154833770862.25104.14121457719973234955.idtracker@ietfa.amsl.com>
Date: Thu, 24 Jan 2019 05:48:28 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/t8EdZQdUze6RwzFmIgPqRJ6oqrc>
Subject: [mile] Eric Rescorla's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jan 2019 13:48:29 -0000

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='xmpp-grid-client@mile-host.example';
>              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?