Re: [mile] Benjamin Kaduk's Discuss on draft-ietf-mile-xmpp-grid-10: (with DISCUSS and COMMENT)

Peter Saint-Andre <stpeter@mozilla.com> Tue, 26 March 2019 02:12 UTC

Return-Path: <stpeter@mozilla.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 B92BF1201E1 for <mile@ietfa.amsl.com>; Mon, 25 Mar 2019 19:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=mozilla.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 ALNxY-5LN745 for <mile@ietfa.amsl.com>; Mon, 25 Mar 2019 19:12:25 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 6D4DF1201D9 for <mile@ietf.org>; Mon, 25 Mar 2019 19:12:25 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id 10so7336485pfo.5 for <mile@ietf.org>; Mon, 25 Mar 2019 19:12:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sXUQvRJnCre1T8ckKp1GDkGWkYlCPozfqhe+YTfhaFU=; b=EhJKT6u9hzKFDFBtl/RLlBEWeVzEcC/+RfCR6U+I9SVsa0PDojZwB1O4DBAh8FFv7B h/uW79OQxR4gyoyibb36JoBIkuvTomK+rGa4766fZWtZ/0+Xn4H7TDzAWVFERMNdSxmw 7zlFF1+ZRzHPR4oCFtkNxrCXBlaWUgJZ1mlT8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sXUQvRJnCre1T8ckKp1GDkGWkYlCPozfqhe+YTfhaFU=; b=YiYWl3odNnBmV6iLRQLy9ZdLFWBPPO81DvQiZikVBmdWULEvLuCp6XmBWWQJha4LfS BgvdsM2X+R52u8uPLcyRkXlSXQYqS6cbfImoSodohQh650TUguPLwLlvK4HkomP3V9gf Mo/IKxSAmKCGGnDv+g902Kt7M/EfcgGRKjbeVZWzoIw5jLAJU695vx0MN5p0Lzpeouco AsfcvuHv032RCl5dBcyPSM56F2aS25++DYTeAALPQ5OWKvZbAjB75ja0DgyxG2mneEOO B2qtKTqgZKuoukDVXRG7SlXoUBhPyMhJtJScMueE5+tsjtH21PYvLHfO5X/iCl99j569 D0FA==
X-Gm-Message-State: APjAAAUDiFVO2MmFKjTCaEGDELTNQc+OtFUzMVwJFafSI6FZpeJTDIx/ 9jAtdfyrRlKfPGqFai0C7+4s+A==
X-Google-Smtp-Source: APXvYqwpDNZDqYLIAvtdBootS/jtDKbsfpDgz4cH3I2Fu8IcVPdVmJzccBtjfY9WwuPF2rysjMxH5Q==
X-Received: by 2002:a63:7117:: with SMTP id m23mr19276618pgc.271.1553566344823; Mon, 25 Mar 2019 19:12:24 -0700 (PDT)
Received: from dragon.local ([74.85.93.170]) by smtp.gmail.com with ESMTPSA id w1sm27119321pfb.164.2019.03.25.19.12.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 19:12:24 -0700 (PDT)
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
Cc: draft-ietf-mile-xmpp-grid@ietf.org, mile@ietf.org, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, mile-chairs@ietf.org
References: <155355003226.24676.11013184390807731904.idtracker@ietfa.amsl.com>
From: Peter Saint-Andre <stpeter@mozilla.com>
Openpgp: preference=signencrypt
Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V
Message-ID: <92e77b7d-bf3e-6c27-d614-819295d69fdd@mozilla.com>
Date: Mon, 25 Mar 2019 20:12:20 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <155355003226.24676.11013184390807731904.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/U_e2vr5Po52PUuyYV1AFsiVcUeU>
Subject: Re: [mile] Benjamin Kaduk's Discuss on draft-ietf-mile-xmpp-grid-10: (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: Tue, 26 Mar 2019 02:12:30 -0000

Hi Ben, replies inline.

On 3/25/19 3:40 PM, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-mile-xmpp-grid-10: 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:
> ----------------------------------------------------------------------
> 
> Thank you for updating to describe this document as essentially an RFC206-style
> applicability statement; that helps a lot to frame what it is intending to deliver,
> and the other updates are improvements as well.
> 
> That said, I think a couple of my DISCUSS  points remain applicable:
> 
> Section 8.2.3 still has text about how an XMPP Grid Controller could obtain
> XMPP-Grid Platform credentials and impersonate the XMPP Grid Platform
> even after the breach of the XMPP Grid Controller is repaired.  The current
> MTI SASL mechanisms  do not give the controller that ability, and it's only
> bad mechanisms like PLAIN that involve sending cleartext passwords/bearer
> tokens to the server that give an attacker that compromises the controller
> this ability.  I think we need to clarify that this depends on the SASL mechanism
> used, and that the MTI mechanisms are not vulnerable to this attack.  Suggested change:
> 
> OLD:
>    o  Obtain and cache XMPP-Grid Platform credentials so they can be
>       used to impersonate XMPP-Grid Platforms even after a breach of the
>       XMPP-Grid Controller is repaired
> NEW:
>    o  Obtain and cache XMPP-Grid Platform credentials so they can be
>       used to impersonate XMPP-Grid Platforms even after a breach of the
>       XMPP-Grid Controller is repaired.  Some SASL mechanisms (including
>       the mandatory-to-implement SCRAM and EXTERNAL with TLS mutual
>       certificate-based authentication) do not admit this class of attack, but
>       others (such as PLAIN) are susceptible.

Yes, that's better.

> The secdir review notes that the full implications of the
> participants' access to plaintext data are not covered.  (This also relates
> to Ben's discuss point (2).) 

For the avoidance of doubt, in a note earlier today I proposed adding a
new subsection under "Countermeasures" in the security consdierations:

8.3.6.  End-to-End Encryption of Messages

   Because it is expected that there will be a relatively large number
   of Consumers for every Topic, for purposes of content discovery and
   scaling this document specifies a "one-to-many" communications
   pattern using the XMPP Publish-Subscribe extension.  Unfortunately,
   there is no standardized technology for end-to-end encryption of one-
   to-many messages in XMPP.  This implies that messages can be subject
   to eavesdropping, data injection, and data modification attacks
   within a Broker or Controller.  If it is necessary to mitigate
   against such attacks, implementers would need to select a messaging
   pattern other than [XEP-0060], most likely the basic "instant
   messaging" pattern specified in [RFC6121] with a suitable XMPP
   extension for end-to-end encryption (such as [RFC3923] or a more
   modern method such as [XEP-0384]).  The description of such an
   approach is out of scope for this document.

> Some of them are covered by existing text,
> e.g., the trust model's instistence that the platforms preserve the
> confidentiality of sensitive data, but others are not.  I repeat here the
> portions of the COMMENT section that seem relevant:
> 
> Section 8.1.3
> 
> The controller is also trusted to preserve the integrity (and
> confidentiality against unauthorized parties) of the data flowing through
> it.
> 
> Section 8.2.2
> 
> The authorized platform could advertise data that is incorrect with the
> intent to lead to incorrect actions by the recipients, without needing to
> exploit vulnerabilities in other systems or compromising them.
> 
> Suggested additions:
> 
> Section 8.1.3:
> 
>    o Preserve the integrity (and confidentiality against unauthorized parties)
>      of the data flowing through it.
> 
> Section 8.2.2
> 
>    Advertise false data that leads to incorrect (e.g., potentially attacker-controlled
>    or -induced) behavior of XMPP-Grid Platforms, by virtue of applying correct procdeures
>    to the falsified input.

Thanks for the suggested improvements, we'll incorporate those.

I'll also look more closely at your comments (below), since I'm sorry to
say that I didn't do so earlier.

Peter

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1
> 
> In the vein of Alissa's comments, I think this section is missing a
> high-level technical view, perhaps something like:
> 
>   The XMPP Grid does not introduce any new protocols or technologies, but
>   rather describes a scheme by which XMPP pubsub functionality is used to
>   quickly and efficiently distribute information relating to security
>   incidents and their detection, potentially scaling to 100,000s of
>   subscribers.  XMPP service discovery allows for entities to learn about
>   content distributed via the XMPP Grid via the registered "pubsub#type"
>   identifiers, which also indicate the format of the data being distributed.
> 
> It could also benefit from some more text placing this tool within the
> broader MILE scope.
> 
> Section 4
> 
> The Platform in item (a) is only listed as having a source of security
> data, in which case I would expect the "typical" workflow to only involve
> it needing to publish, and not necessarily to subscribe or query.  While I
> recognize that a typical workflow will include both publishing and
> subscribing, it may be worth mentioning that this Platform also desires to
> receive some information as well as having a source for it.
> 
> Section 5
> 
>    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]):
> 
> Isn't this more of a "the MILE XMPP grid won't work at all if you don't
> include a pubsub#type field that indicates iodef payloads"?  I could see
> doing this as descriptive text about what happens, or as a MUST, but the
> SHOULD just doesn't seem right.
> 
> Section 8
> 
>    An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid
>    Platforms such as Enforcement Points, Policy Servers, CMDBs, and
>    Sensors, using a publish-subscribe-search model of information
>    exchange and lookup.  [...]
> 
> This jumps in quite quickly, using these terms that have not previously
> been defined and are part of a broader architecture that is not directly
> relevant to understanding this protocol.  Is it necessary to mention them
> just in passing like this without other discussion?
> 
> Section 8.1.3
> 
> The controller is also trusted to preserve the integrity (and
> confidentiality against unauthorized parties) of the data flowing through
> it.
> 
> Section 8.2.2
> 
> The authorized platform could advertise data that is incorrect with the
> intent to lead to incorrect actions by the recipients, without needing to
> exploit vulnerabilities in other systems or compromising them.
> 
> Section 8.2.3
> 
>    o  Mount an even more effective denial of service attack than a
>       single XMPP-Grid Platform could
> 
> There seem to be a number of ways in which the DoS effectiveness could be
> increased by a controller (compared to a platform), whether by inducing the
> many platforms to perform the same operation in an amplification-style
> attack, completely refusing to pass any traffic at all, sending floods of
> traffic to (certain) platforms or other targets, or otherwise.  Do we care
> to make a distinction among them, or is that not helpful at this level of
> granularity?
> 
>    o  Obtain and cache XMPP-Grid Platform credentials so they can be
>       used to impersonate XMPP-Grid Platforms even after a breach of the
>       XMPP-Grid Controller is repaired
> 
> This would require that platforms are using things like SASL PLAIN
> authentication, and would not be possible if TLS mutual authentication or
> some other proof-of-possession-based authentication scheme is used for
> client authentication and authorization.  It seems important to reiterate
> this distinction and point out the risks inherent in transmitting passwords
> to the remote party for verification.
> 
> Furthermore, since Section 8.3.1 instructs us that we can only use SASL
> EXTERNAL or SCRAM, this sort of credential scraping would only occur if the
> EXTERNAL mechanism used permits it (which I believe to be somewhat
> unlikely), or if clients were misconfigured to allow non-permitted SASL
> mechanisms (which is, unfortunately, fairly likely to be the case
> somewhere).  This behavior, particularly the risk of client
> misconfiguration, should be called out somewhere in the security
> considerations.
> 
>    o  Obtain and cache XMPP-Grid Controller administrator credentials so
>       they can be used to regain control of the XMPP-Grid Controller
>       after the breach of the XMPP-Grid Controller is repaired
> 
> (This also requires the use of non-proof-of-possession authentication
> schemes.)
> 
> Section 8.3.1
> 
>    be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in
>    [RFC6120] and updated by [RFC7590].  The XMPP-Grid Platform MUST
> 
> Citing RFC 8446 (TLS 1.3) for TLS 1.2 is rather strange.
> 
>                     The selection of which XMPP-Grid Platform
>    authentication technique to use in any particular deployment is left
>    to the administrator.
> 
> But from a very short list of options!  Why do we need to prevent the usage
> of other, equally secure, SASL mechanisms, for example, all the GSS-API
> mechanisms available via GS2 bridging?
> 
> Section 8.3.2
> 
>                                                            The XMPP-Grid
>    Controller MAY provide functional templates so that the administrator
>    can configure a specific XMPP-Grid Platform as a DHCP [RFC2131]
>    server and authorize only the operations and metadata types needed by
>    a DHCP server to be permitted for that XMPP-Grid Platform.  [...]
> 
> Why is DHCP so privilged to be the only application protocol called out
> explicitly here?  It seems that this is just an example and the same
> profiling/resterictions could be applied for any application protocol.
> 
>    unusual XMPP-Grid Platform behavior.  XMPP-Grid Controllers SHOULD
>    make it easy to revoke an XMPP-Grid Platform's authorization when
> 
> I don't think "SHOULD make it easy" is particularly actionable for
> a normative requirement.  Similarly for "SHOULD be hardened" in the next
> paragraph.
> 
> Section 8.3.3
> 
>               Administrators SHOULD NOT use password-based
>    authentication but should instead use non-reusable credentials and
>    multi-factor authentication (where available).  [...]
> 
> [see previous remarks about permitted SASL mechanisms]
> 
> Section 8.3.5
> 
>    While XMPP-Grid is designed for high scalability to 100,000s of
>    Platforms, [...]
> 
> Where is this documented?
> 
> Section 8.3.6
> 
> nit?: I would not really describe CT as a "guideline for proper CA
> security", but rather a tool for discovering failures to maintain proper CA
> security.
> 
> I think we need to be careful about recommending pinning, since it
> introduces a new DoS vector when there is a legitimate need to change
> certificates.  If we're talking about pinning, we would presumably also
> want to recommend against pinning EE certificates and only intermediate or
> root CAs, and to have monitoring for imminent expiration events.
> 
> Section 9
> 
>    Another consideration for deployers is to enable end-to-end
>    encryption to ensure the data is protected from the data layer to
>    data layer and thus protect it from the transport layer.
> 
> It's probably worth a(nother?) reminder that the mechanisms for doing so
> are out of scope for this document.
> 
>