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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Sat, 26 January 2019 15:48 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FED130DEA; Sat, 26 Jan 2019 07:48:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qriWi_9iMXyW; Sat, 26 Jan 2019 07:48:24 -0800 (PST)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA6B130DD6; Sat, 26 Jan 2019 07:48:24 -0800 (PST)
Received: by mail-qk1-x733.google.com with SMTP id c21so7146402qkl.6; Sat, 26 Jan 2019 07:48:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AAjzvcf0lt3QPYZ2reyx+bMpe56myJImqmd3RIknqeo=; b=WNNvXf98N80/p+PMyU2p2EqV4bGjcZoz/MXMPpiwkjgK0qgDzJwkaMmZdWtkVRFh2B 7j58A+VJkJtmdsCquR1YVvOrqn2lM5Zipp5iJE2ICor3XDT54AFDv+diRsJS5NHdTg49 aJ9i5h244X2QypKz5Ln1tDX/1AdPpdiwIGLEvSNWCisBOMIzurp6n4qScscR4i1yzb73 vlDNua72RH4YxZZbJAqlz2fuxPFK4BTnEZ5IkAUYoYy/8UTI0mwlO8QvYDddwTSlU/Hr hAkix8Vk5uC8/Lkd/QlbONmefuinJmc0RufPkA3QPr+cuc1eeyhgfeqR5AhRb18f/p7I bxsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AAjzvcf0lt3QPYZ2reyx+bMpe56myJImqmd3RIknqeo=; b=MPhpImVPoQhSjkZpTCxx0HMNliLhwywF13HLlfRX5x4K8hHq9P9vaanqqvJMk6qJzf yzeIPuhQ/GmSOVqGeW51+hspJ1KKiaD8xM/BOY3gXQvadgBcTNOhqb8pGh+vAW7VOkOj yuz/2Kqq1Lp88/qJLxuvaSkm6jGVdAvhbsSgE61LDDSX/iZoyNU5hyDG+EI6TYZqPNP2 /Qciltkr2zbrmm9cMmjpiwr7IjwpopdxOiWudCViQVKjpTiHZFEGdQPJiK1vMYrY2OqI gw7Uc2XG8TIVezFLUqfyfDkDzm199XRw1RCTCOlbQbCgl1oTB4IbUa8WipN1iQyrAJ4Y vajA==
X-Gm-Message-State: AJcUukenTR1rnkASxupNmoh5MKC6iXY8vhuc1Pq45TQR56gQ+JWmaRY6 Gmh/o5f0d9fZwEiO5CMs3FMDJVSd
X-Google-Smtp-Source: ALg8bN4cGg70ToRkSP2cJlns+SSzpJ2tx/nwwyutBTpBY08MVFdp9YtP0y+1JBaQNy8g+SXaZob+0g==
X-Received: by 2002:ae9:e8d7:: with SMTP id a206mr13459189qkg.317.1548517703111; Sat, 26 Jan 2019 07:48:23 -0800 (PST)
Received: from [10.111.222.210] (209-6-124-146.s3472.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.146]) by smtp.gmail.com with ESMTPSA id 5sm97208262qtw.50.2019.01.26.07.48.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Jan 2019 07:48:22 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: iPhone Mail (15E216)
In-Reply-To: <154833770862.25104.14121457719973234955.idtracker@ietfa.amsl.com>
Date: Sat, 26 Jan 2019 10:48:20 -0500
Cc: The IESG <iesg@ietf.org>, mile@ietf.org, mile-chairs@tools.ietf.org, draft-ietf-mile-xmpp-grid@ietf.org, mile-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <312B7C3D-8DFA-4539-9E31-E4B1E8ADDDE3@gmail.com>
References: <154833770862.25104.14121457719973234955.idtracker@ietfa.amsl.com>
To: Eric Rescorla <ekr@rtfm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/ZvOY4vmWkx3kJ4eXpuBOzEecit8>
Subject: Re: [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
Precedence: list
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: Sat, 26 Jan 2019 15:48:27 -0000

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 <ekr@rtfm.com>; 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='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.
> 

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