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

Bret Jordan <> Sun, 14 July 2019 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14E93120111 for <>; Sun, 14 Jul 2019 09:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Status: No, score=-1.996 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OUlB6YVp-R1h for <>; Sun, 14 Jul 2019 09:30:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 259D11201A0 for <>; Sun, 14 Jul 2019 09:30:59 -0700 (PDT)
Received: by with SMTP id i18so6573171pgl.11 for <>; Sun, 14 Jul 2019 09:30:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A6KaB+0FeELJ+g8S4mzLNBIXqTuFBYrE0A/xi0O1cxQ=; b=pXv5zImpmFU+TOCiBy28NdsDKih7CqeZcsHFMD/6cEGHx6zyj299ttX4Y2qclHMfe4 2x2uR5pftjJSxSZP04cVoAlOUsectRCtNPQWjx9yhTgRDIOJHFjjiCnw1pX+lpkkbMdP 7cjzUQUz7rgiV47c4sCwAIHDfbIBiZyqGBZiHVYjsNRYbI0PVIVomGYT9DVDftpWbPG0 8h5M/BW/IKoqBs0sqXTgbjbm1mxABDUnzTtFUOVjfjtjqmwbvRuRCASka69V4KnqSp4w YJcmRHPpRi56sg6NMFrllIdScfO8TAqLQ8JrT9SeT7rWPJpsJXRuW7z9yfo4Mke0Dpdm lnCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A6KaB+0FeELJ+g8S4mzLNBIXqTuFBYrE0A/xi0O1cxQ=; b=VdamQM2HWryu7XaAxWC/ES2f4qyEE7Kl1GbM5gYBVOGfqO/bszSd+XiPdh9Lr4rPCm BNyNhM0fpqvUYXEKVeDpJU3QN79aIJrc36Y2cCklnDGOi/B/N6WqstIHdPA+geTHg3o8 mCdsCycXnYPluXu4I7CjYhOMKpHhuczDXogJtiZFLiazKy6pYrunaVan06/dzIEym98R Vdly94vgO/Rk74OKt+t4rhLMpSxmejCMO0pIMYhdiuhjPf296pBDzUEQpclvZ+h2iBrg sChYX08ZpCCwHYCniHO6kGG68c08lxjiUkXn1KFVsS+TGMU0lkioGFifxp0ifGI4B/AT LxuA==
X-Gm-Message-State: APjAAAXVhTx280MSU2CaLHrbq8su5hst+AlEiU1bRN2peRyDuKM5LDRg 4xw2B/Vxg6KEhR8bQx7T6Mo=
X-Google-Smtp-Source: APXvYqzdkSd04SuumSvxqe7VCzG6AOSv0yqNmau17lcxYLMe02kbVYEdiBOtH7GbJJn9TqOOB6ouuw==
X-Received: by 2002:a17:90a:1b4c:: with SMTP id q70mr23692397pjq.69.1563121858616; Sun, 14 Jul 2019 09:30:58 -0700 (PDT)
Received: from ?IPv6:2605:a601:a990:4d00:98b:bcc4:5aa6:8504? ([2605:a601:a990:4d00:98b:bcc4:5aa6:8504]) by with ESMTPSA id j12sm4305511pff.4.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jul 2019 09:30:57 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-40EF9A22-193A-445E-987E-23C7497B9B72
Mime-Version: 1.0 (1.0)
From: Bret Jordan <>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <>
Date: Sun, 14 Jul 2019 10:30:56 -0600
Cc: Melinda Shore <>,,
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Eliot Lear <>
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: Sun, 14 Jul 2019 16:31:02 -0000

I personally think the biggest value at this stage is awareness and discussion.  So I would love to see this continue as a regular update item for sec dispatch.  I would also love to see regular and multiple side meetings.  I would also love to see SMART get officially chartered. 

I fully understand and get that we in the IETF generally focus on on-the-wire protocols.  However, I think we can design better and more secure solutions once we more completely understand the entire security pie.  Understanding operational security requirements and regulatory compliance requirements is critical for the success of the solutions we create here in the IETF.


Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Jul 14, 2019, at 4:56 AM, Eliot Lear <> wrote:
> Hi Melinda,
>> We
>> typically deal with wireline protocols and their support
>> structures, and I'm hoping that as the discussions progress
>> people can be clear about what they'd like to see from the
>> IETF.
> I think you’re primarily referring to leaky user databases here.  I agree with you that we cannot fix organizations’ bad internal code with a wireline protocol.  However, to exploit the vulnerability, the attack had to come from somewhere.  We already have one mechanism to address profiling with IoT that manufacturers can use to keep their systems from being exploited as BoTs.  The next question is whether we should be promoting or improving other mechanisms to provide people at home and elsewhere more visibility in terms of what their general purpose computing devices are doing.  I’m thinking of PCP in particular.  And while there may be more we can do, there may also be some limitations relating not only to privacy but also economics of web services.
> What I like about Dominique’s draft is that it gets us thinking in those directions (or at least it did me).
>> I do think that some of this may be appropriate for opsec,
>> as well, or at least should be called to their attention.
> Or an RG or a side meeting.  It would be fun to continue the discussion.
> Eliot
>> Melinda
>> --
>> Melinda Shore
>> Software longa, hardware brevis
> _______________________________________________
> Secdispatch mailing list