Re: [OPSEC] Review of draft-camwinget-opsec-ns-impact

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 19 June 2020 10:17 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64C03A094E for <opsec@ietfa.amsl.com>; Fri, 19 Jun 2020 03:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, 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 Ci3_zr9YXQ_H for <opsec@ietfa.amsl.com>; Fri, 19 Jun 2020 03:17:05 -0700 (PDT)
Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 696B33A094A for <opsec@ietf.org>; Fri, 19 Jun 2020 03:17:05 -0700 (PDT)
Received: by mail-qv1-xf2e.google.com with SMTP id d12so4195272qvn.0 for <opsec@ietf.org>; Fri, 19 Jun 2020 03:17:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=phDs7hLnKnbZEPNJs5Ke2aGQr70Km56CVlm3bere1rc=; b=eJGu719zUW99IQGL6XSOh4RHJLjB+TqwgifUAmPnmuRSXfrWV+tY1rpuX1fjPqM5Kr GY04q8gGKHW0d4cCXGdwgM6yZ6PnYjbgUfYsC5c9CNH2vwJd1NDSCGORYg2ItZq9Y1Tz AKCRBbPGfusUA4/NQp6jwkeqR9VJoDJKhHe5LqZVvDFlKPASEjAi4/40tzT0qr08UmrF Ef/HUooIJROb9e0f7n0ICTIqjJftt98DLBnXxVQdFAmcilFFG3ajvib7RyYILmEkeI8l Fx4qQB3gBiDgNd4K/iusrM4vMzoHtitary2uP/u1sctFjOG1tUv9NOyIFWmjArGsWQx5 yw4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=phDs7hLnKnbZEPNJs5Ke2aGQr70Km56CVlm3bere1rc=; b=iVugiz5Wxhu7075IYkwepD8FMVVS7YbVX1mMHBbeEUEyGylo1kf+VlwhDrb9s8CiEu GQOVrJLv9nMa+sgNoRv8wMAyAJm13qRiOKgduSYOfkV3/ThiRDhjLJ+1qceH/BuBcO2P TQAmsPVO0X1oF6opxEcT7UvKe7uOFvwa5uzO7daqu0OS6qKszAmeF+8QYuj2nnPypnqt kfNvR+0dsDMgyp0BdaDz8rlWY5A8HzcZOghZca/HSY45YiWfTNKYs1GoKQGaDrmJguZo r9hfPOmVu3Ng78xFBHY6qDg+hM9vH6UWPS63WHi+TgNz10gpdD3dGcmQwtqPBbYeFSAR LtMw==
X-Gm-Message-State: AOAM532yyBpRMTGwPS9Vz0wPg4O5AtHHYD8InHzGG2RdW61wbQuqj9xL lFKYRam2wekR5vjC3TRve92lh9FU
X-Google-Smtp-Source: ABdhPJyGAevuSqKFtIT3+IxpKjM4RQUtMn57AdR8G+KqpFOIF8gsBfCybf7IGEkDFRAMdSUrHF94OQ==
X-Received: by 2002:a0c:b256:: with SMTP id k22mr7782964qve.115.1592561824333; Fri, 19 Jun 2020 03:17:04 -0700 (PDT)
Received: from [192.168.1.2] (146-115-73-78.s5196.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.73.78]) by smtp.gmail.com with ESMTPSA id m53sm6103282qtb.64.2020.06.19.03.17.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 03:17:03 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-D4FA9EEF-60B1-4CD2-8276-20386B0AC2C6
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 19 Jun 2020 06:17:03 -0400
Message-Id: <0BC7FC53-BF56-47AB-9C11-3B0163B7FC3E@gmail.com>
References: <96E17BAE-82DF-4653-AADB-5FC7CA489FE7@cisco.com>
Cc: "opsec@ietf.org" <opsec@ietf.org>
In-Reply-To: <96E17BAE-82DF-4653-AADB-5FC7CA489FE7@cisco.com>
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/Z92LvT_kwkCDfZQR-M6gTDa_Pe8>
Subject: Re: [OPSEC] Review of draft-camwinget-opsec-ns-impact
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2020 10:17:08 -0000

Thank you for your response and updates.  I read the full message and responses look good.

Best regards,
Kathleen 

Sent from my mobile device

> On Jun 18, 2020, at 6:04 PM, Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com> wrote:
> 
> 
> Hi Kathleen,
> Many thanks for the thorough review!  More comments below:
>  
> From: OPSEC <opsec-bounces@ietf.org> on behalf of Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
> Date: Thursday, June 11, 2020 at 3:29 PM
> To: "opsec@ietf.org" <opsec@ietf.org>
> Subject: [OPSEC] Review of draft-camwinget-opsec-ns-impact
>  
> Thank you for your work on this draft, it has come a long way since it was first written!  I support it's adoption and provided a review.  I am also happy to review again before final publication if helpful.
>  
> Introduction
> 
> I think it's worth adding a bullet that specifies a system that's not able to itself detect and repent threats as is needed when you embrace a fully E2E encrypted solution.  It will take a bit of time before those models are practical everywhere.
> There's a definite need to document this current situation as the network is one of the active methods used to detect and prevent threats today.  As such, I support this document being adopted and have a few comments for consideration.
> 
> [NCW] How about this as a bullet: “a single system may itself may not be able to detect and mitigate threats”
> 
> For the quote on RFC8404, I'd characterize that document as a catalog of what's impacted when encryption is deployed E2E to help develop new methods, where appropriate, to evolve with an E2E model.
> 
>    [RFC8404] documented such a need with the effect of
>    pervasive encryption on operations..
> 
> Even though it's said, I think it would help to make a tiny change:
>   [RFC8404] documented a need to evolve with the effect of
>    pervasive encryption on operations.
> 
> [NCW] That is fair and I can make the change.
> 
> 
> 
> Section 3
> 
> You may want to change the following sentence to fit in line with an OpSec practice documentation draft>
> From:"Each deployment scenario describes relevant operational practices."
> To:"Each deployment scenario describes current operational practices."
> 
> [NCW] Will do
> 
> 
> 
> The categorizations look good, I think this in new from my last review.
> 
> Section 3.1..1
> 
> I like how you've categorized the impact, but I think the display of it may make all the difference.  This is int he current document:
> 
> TLS 1.3 impact: reduced effectiveness.  Per Section 4.2, domain
>    categorization and application identification will be limited to IP
>    address and SNI information (beyond additional correlation possible
>    with other means such as DNS).
> 
> How about:
> 
> Impact Category: Reduced Effectiveness.  Per ...
> 
> [NCW] Will do
> 
> 3.1.2 uses a different format, so making these consistent would be good.  It says TLS 1.3 considerations.  I think leaving TLS out and just saying impact category makes the same point and may not be objectionable.
> Also for this section, the last line says the Certificate is not available.  I think it's that the ALPN response is encrypted that matters here as that tells you what cipher suites were negotiated.
> 
> [NCW] Thanks for catching it, we actually are using “TLS 1.3 considerations” we happened to miss the one in section 3.1.1
> 
> 
> 
> Section 3.1.4
> Do you want to add that the ALPN response is encrypted here as well?
> 
> [NCW] We can, I’ll confer with co-authors in how best to incorporate.
> 
> 
> 
> Section 3.2.2
> It should note that DLP can also be addressed on endpoints, whether or not you add a comment on scaling.
> 
> [NCW] OK
> 
> 
> Section 3.2.3
> You may not want to add alternate approaches, but I would think one designing this today would opt for use of a routing overlay protocol, no?
> 
> [NCW] I don’t think we are listing alternate approaches?  Overlay could be an alternate, but our point is not to suggest other approaches other than to state how the TLS proxies get used today and their impact.
> 
> 
> 
> SFC, NSH, GENEVE
> 
> Section 3.3.3 
> Just a note that I am not sure you'd want in the document, but web application firewalls are falling out of favor as a defense.
> 
> [NCW] OK; I think we included it based on previous feedback (to include as a consideration too)
> 
> 
> 
> Section 4 heading
> Consider changing from:
> Changes in TLS v1.3 Relevant to Security Operations
> To: Changes from TLSv1.2 to TLS v1.3 Relevant to Security Operations
> 
> [NCW] But the context is to summarize the 1.3; while some of the uses can apply to 1.2 the impact is really more due to the way 1.3 applies them.
> 
> 
> 
> Section 4.1 Please not that RC7525 has recommended against use of RSA static keys and has recommended use of AEAD cipher suites.
> 
> [NCW] OK
> 
> 
> 
> Section 5 Security Considerations
> Consider changing the initial sentence from:
> "This entire document discusses security considerations in existing
>    operational security practices interacting with TLS."
> To:
> "This document discusses the impact to common security monitoring and detection functionality with a move from TLSv1.2 to TLSv1.3 considering existing
>    operational security practices interacting with TLS."
> Or something that reads better with the same point :-)
> 
> [NCW] OK
> 
>  
> --
>  
> Best regards,
> Kathleen