Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt

Bret Jordan <> Mon, 15 July 2019 17:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AC291201E0 for <>; Mon, 15 Jul 2019 10:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7SHqOW4UMTtB for <>; Mon, 15 Jul 2019 10:02:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 296571201EC for <>; Mon, 15 Jul 2019 10:02:17 -0700 (PDT)
Received: by with SMTP id z75so8003468pgz.5 for <>; Mon, 15 Jul 2019 10:02:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bbvN+6WQO48xJUmt7zYKXGwf7rFwSwcvFIYLA3WzvWc=; b=JqYpU/+3gZVEotgozAgkr+oCXGhpepcz+6+U2yIyfzr+g/KEQ484n9xB4BAXsM7iEj J7H/5ZJ/CEtpxNxrg0FKaROOJp7x7myMpx1DhHHMjOC2/hghI8dffyFVl8bgV+HIAvDb EK7VTn2iPX3bqR+DdEAoo9/YorebtrCbfybOXxZmLPr1GxNUEuIHnNf9T16eFMCdN3Tg fVs2MGL1pr4SAV/AgUk3N+6Lw8X6fnoEmwd4CTjvtWmToM6KEqlG1FeW3qEgp5T5KUo3 v/6NA0zVR2vOU0b0QPi+O3aOJPf1tPHdbhjFREmGI9iLbTnC78LYTpcwDf6CW6ynRP1N PRIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bbvN+6WQO48xJUmt7zYKXGwf7rFwSwcvFIYLA3WzvWc=; b=Cyo8UqoLKztKGmNPy3KH9K0jM/86zRxjxM/YG1DEunFr/NuyyJ+AHPzX439qiSJWie xST7kxZJzeW4x4i17qcQR5IGhdAvuYwarOGvbVJh1CduF1iOJLlHUKGcExtaDFcim/NE rPgyn2aGtmALXzllYj5axgrw+V3XmhiaXheTF7d8+VkJlNWRDBrSzYXL6YDHm0SM13/n 8Ja98IxO1aEUs6ACkYi/z2D9lcQHhCtKoAFdP19Uj7IOtDq66wXNw07xtiYNRkzBx3nc 83QxEDs+Ako/s1C+uOzb2EV50g2kn2Tz6eZE7Bs9EGVUoQ0Lb/jUEOXdssSt6gbxUudT qwbQ==
X-Gm-Message-State: APjAAAUQqoE0MdEskbeVZBSUI4M4I4sCX55idwt9q0GQYik14js6SyCp 4ZMVt/hh4shn/gK+3E/GEFI=
X-Google-Smtp-Source: APXvYqyVk8cpVwKiB5S8sCwirFHGxRGUYU5B9+TE+rgqMY4DydfDEPqOJ0ug7UGZ8Df4lZ3tNhpwFQ==
X-Received: by 2002:a65:4cc4:: with SMTP id n4mr28980894pgt.307.1563210136582; Mon, 15 Jul 2019 10:02:16 -0700 (PDT)
Received: from ?IPv6:2605:a601:a990:4d00:a925:658c:7e16:1f17? ([2605:a601:a990:4d00:a925:658c:7e16:1f17]) by with ESMTPSA id e6sm21596962pfn.71.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 10:02:15 -0700 (PDT)
From: Bret Jordan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A11723D8-9DF2-4580-96FD-04AA3FEEDC82"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 15 Jul 2019 11:02:12 -0600
In-Reply-To: <>
Cc: Kathleen Moriarty <>, Eliot Lear <>,, Dominique Lazanski <>, IETF SecDispatch <>, Stephen Farrell <>
To: Eric Rescorla <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Jul 2019 17:02:26 -0000


It is not so much that it was designed wrong, but that when critical functionality was removed, there was no alternative method added to support critical use cases. So one can argue that some decisions were done from a myopic point of view, without realizing the problems they will create. 

There are many examples, but let us just take two for right now.  I am sure I will enrage people to no end and cause an uproar, but so be it. 

Hiding the Server Certificate
This is a wonderful thing for open internet sessions as it help prevent passive analysis of users traffic and where a user is going. So from that side, it is great. However, from the managed network stand point it is terrible. This feature/data is a critical element used in managed networks and is critical for ensuring regulatory compliance. The problem is not so much that the WG decided to hide it. The problem is the WG did not and has not yet provided an alternative solution to fill in the missing gap. So either the WG does not understand the operational security requirements around it, or they are just choosing to ignore them.

This is also a really neat idea. However, when you layer this with DANE+DNS_SEC you get to a point where installed trust anchors no longer become effective.  Further, managed networks really rely on DNS data for both first line defense and retrospective analysis of threat actor / CnC behavior.  So DNS over HTTPs by itself is not a bad thing.  But the way it is being implemented in products and the possibility of using it with other solutions like DANE can make operational security significantly more challenging if not impossible.  Threat Actors are already starting to use DoH to launch attacks, since it provides a way for them to get around some security controls. So it becomes critical that for things like DoH that products provide a way for it to be turned off, or for managed networks to specify their own DoH servers.  Further, managed networks need to start looking at locating their internal DNS servers on the WAN side of their proxies / firewalls so that they can create islands of trust and rewrite the DNS_SEC on the fly if they need too.  But all of this should be called out and where possible, we should provide ways for management networks to still do what they need. 

So I would like the security considerations to be updated to help ensure that we ask the questions, like “what is this going to do to operational security?”, “how is this going to impact incident response and network forensics?”.  I want to also be super clear that I am not against these technologies by themselves. But we need to ask these hard questions and provide solutions that can still enable managed networks to protect themselves.   Thinking that everything can and should be done on the endpoint is just outright naive. 

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jul 15, 2019, at 9:25 AM, Eric Rescorla <> wrote:
> On Mon, Jul 15, 2019 at 7:50 AM Bret Jordan < <>> wrote:
> Kathleen,
>> I do think there is work for the IRTF as well and would like to see that encouraged.  The shift to strong encryption is good, but upends the current security management models for many.
> This is one of the points I made during my talk at RSA.  These technologies by themselves, are all really great.  The problem comes is when you start using all of them together.  To the naive comment earlier that this is about vendors trying to sell product, no, this is about network and cyber defenders and SoC analysts trying to do their job. There are things like regulatory compliance that organizations and enterprises are required to follow. Some times I feel like we are so worried about one piece of the security pie, that we completely neglect the others. 
> Bret,
> As I said before, this is extremely general and hard to act on.
> What would be most helpful at this point would be for you to describe a few ways in which you think the IETF should have designed protocols differently, so that we can discuss them.
> -Ekr
> Here in the IETF everyone needs to better understand how SoC analysts and network/cyber defenders do their jobs, what they are asked to do, and what tools are available to them. 
> Bret