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

Bret Jordan <> Mon, 15 July 2019 00:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1CA112018E for <>; Sun, 14 Jul 2019 17:45:28 -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 64T3UMyQWlTJ for <>; Sun, 14 Jul 2019 17:45:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 146EB1200DB for <>; Sun, 14 Jul 2019 17:45:25 -0700 (PDT)
Received: by with SMTP id n9so642424pgc.1 for <>; Sun, 14 Jul 2019 17:45:25 -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=gyoGR8Vw+tWFHlSz5+QiQ4kpvJ/bOGeNbks2BNstQSU=; b=oXm42KdhX7CY96ozikbQ2Z5KzAN2JSFN8A2qAzvat+UXxoFGbq7ZVkB3i62nLAHfaQ h0e/QX9Sn9hWLaQXPftmH5VVSsou7UiTwgB/8EhA0pOjBSiKnSjfMwo2ZLo/CuOYtlLn 1RTBLhQINyJdrzmUliCZcpdmwordA3H9ykX5fd3d1EJ//e6Cr/EnOvHNjYkTdZ1X3/Nj BYixkbb3YXn+b1dIyuYlI9gFoOotzGTkcngNmL2WgA/od0FaI81b+X4Ol9KOr7Hz408+ cnXROZ1L0sNAW37gNBEisf190KH/WcVzYjkcCqC2752qB8I7NFUyq/g/vKMzHAVtLLbW sKsw==
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=gyoGR8Vw+tWFHlSz5+QiQ4kpvJ/bOGeNbks2BNstQSU=; b=A+yoDmuY9P5V8/2CM53VX74ax1ctP4lt8gHAR+jyrn4ytvDpQanD/dzoNoSl6RlZKh vG7Ov431MWbZeL+hQKYPXqqxGdldzkUYwBNmI8AF1BTtfS8RuYrWscXo6t2drJLthXIL +uEdo8otUMBHtdauWjfenEawpUyLXE+/O2xti/rOhX5zedWPuLXgP/kzwNCAq4WGsJQk onbzpiQdvNf+NJD/m45Dtk7Z1hThTAgKjxDhz/onI2cHnGEcdfFlBn8ZH19Kbcw1nPRz xxtchjj93ZHu2cbXOiDY+O+fcJB8k/oyOshzdyHWepHW6zkzgbGZBhQZryLmIouBRsz2 2uJA==
X-Gm-Message-State: APjAAAUznPSNi4YQEZJo7ja9N5R+rhwg5glY9HQASUx7VuVP326KcNrJ 3Oqf+ht9wrOY7yuJWi8CtPo=
X-Google-Smtp-Source: APXvYqymkA/GonY23/ji9lkTi1ZmoPlR4IV5VGQ6oPEm62OUKbGXn5H+e4TeQFTUo+JBflfRV7rIOQ==
X-Received: by 2002:a17:90a:5806:: with SMTP id h6mr25488907pji.126.1563151524648; Sun, 14 Jul 2019 17:45:24 -0700 (PDT)
Received: from ?IPv6:2605:a601:a990:4d00:6893:ce36:fd8f:62a0? ([2605:a601:a990:4d00:6893:ce36:fd8f:62a0]) by with ESMTPSA id k36sm16589396pgl.42.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jul 2019 17:45:23 -0700 (PDT)
From: Bret Jordan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_89C7521D-F535-4D79-BC7F-913F8135617D"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 14 Jul 2019 18:45:21 -0600
In-Reply-To: <>
Cc: Phillip Hallam-Baker <>,, Kathleen Moriarty <>, 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 00:45:29 -0000


> Hmm... restricting the requirements according to what problems we think we know how to solve seems to be a bit of a systematic problem in the industry. 
> Without taking the position on the industry as a whole, the E in IETF stands for "engineering", so I think trying to solve problems we know how to solve is prudent. As the list of things we know how to solve increases, then we ought to attempt to solve those as well.

Yes, but first we need to make sure we have the open discussions in a congenial manner.  We also need to full understand what is needed by operational security to prevent threat actors and intrusion sets from destroying their networks, users, systems, and data.  

There are many good eco-systems that have very advanced security engineers in them, we should work with them and communicate with them. It would be good for some of us from the IETF to go to these groups and explain what we are working on, why we are working on it, and then ask for feedback from their perspective.  

I believe a document written by the IETF that talks more plainly about the whole security pie, and what parts the IETF is going to try and work on, would be helpful.  We can not boil the ocean.  Further, some parts are better solved outside of the IETF.  We just need to make sure the things we do, do not make other elements of operational security impossible.