Re: [Model-t] Meeting to discuss how (and if) to continue

Mallory Knodel <mknodel@cdt.org> Thu, 11 November 2021 12:26 UTC

Return-Path: <mknodel@cdt.org>
X-Original-To: model-t@ietfa.amsl.com
Delivered-To: model-t@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE82D3A0EAE for <model-t@ietfa.amsl.com>; Thu, 11 Nov 2021 04:26:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.429
X-Spam-Level:
X-Spam-Status: No, score=-5.429 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, NICE_REPLY_A=-3.33, 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 (1024-bit key) header.d=cdt.org
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 p_ZR1OiS6U-7 for <model-t@ietfa.amsl.com>; Thu, 11 Nov 2021 04:26:07 -0800 (PST)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 517DE3A0EB4 for <model-t@iab.org>; Thu, 11 Nov 2021 04:26:07 -0800 (PST)
Received: by mail-qk1-x72a.google.com with SMTP id bi29so5578747qkb.5 for <model-t@iab.org>; Thu, 11 Nov 2021 04:26:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=65AicIvLQJss+XJFYI7bGE7RTVhviPoLS48MXUVwLoY=; b=VTvVK6ZlwOL8FdDKp3gDoFjIH7oTOUBCwD/0xwixOTxzwjwEytx0a6jovVCTpJjfvu tXuQH38pStBQeF4JpDeWgiMENTbtaO6DjWt64Fj0xdo84Wy9hxCrJEv4g0HxyCacxgn3 0GQDkrrXCxlcqXHBpZENpq/F/sKAnBTM43RpA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=65AicIvLQJss+XJFYI7bGE7RTVhviPoLS48MXUVwLoY=; b=tLHiHN2FB9vbJt4iwr0S+P0+Ybery78BmmUND5E4W+iAU5iipj+F7zjEcUUQCA3Plr NFb98HtC+NcQZmNiaAFhrFx6UnbjKpBvZ1eUcL8b1pyuGPGwldloiX2UdpWL12nRprRD dtFAQ1J7cZICDFbr3WtPLgHqN33V/dstLgPXkhNVWLXQQUpdxczI559m1wGZ3CybsHVM 6pXsjHOStPVbg+yUhMTfgQIt3YGTM+zgXQt1mKGU5mH3jMZvxmPoaL3an9CN1bFi8HlN 7H+flM9qlNmYG2Q2eAkQO0A3cdO0soozPII1YVRPUFE9doolzIyAdNtw7qV6XGVpb25j FEoQ==
X-Gm-Message-State: AOAM5304qorsFHPI7GsiB1lWlkadDAGMBmGnTRDYRQ6T7rjvy9wB29R1 cnQ32ypYJND7GkqCOfVg2tmN2TODV50hPw==
X-Google-Smtp-Source: ABdhPJzxHjA6/SOzkQfLvjMje+WF2T+G5gtuuKBNPtokkslEzP2IMNmbSE69QolzSuhvAul6EXgW5w==
X-Received: by 2002:a37:b386:: with SMTP id c128mr5666384qkf.426.1636633565342; Thu, 11 Nov 2021 04:26:05 -0800 (PST)
Received: from [10.0.3.86] ([50.239.129.122]) by smtp.gmail.com with ESMTPSA id c3sm1582204qtc.52.2021.11.11.04.26.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Nov 2021 04:26:04 -0800 (PST)
Message-ID: <0984577a-f34e-548d-deac-9e92ba1b21e6@cdt.org>
Date: Thu, 11 Nov 2021 07:26:03 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Thunderbird/94.0
Content-Language: en-US
To: Jari Arkko <jari.arkko@piuha.net>, model-t@iab.org
References: <6F924A7E-2119-41EB-A9EE-12881CE94C60@piuha.net> <D0A26433-975C-4172-9D0B-8C290DEAFB05@piuha.net>
From: Mallory Knodel <mknodel@cdt.org>
In-Reply-To: <D0A26433-975C-4172-9D0B-8C290DEAFB05@piuha.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/model-t/xOCyq9WmBuy5Q1vkdLTlpsxUc9w>
Subject: Re: [Model-t] Meeting to discuss how (and if) to continue
X-BeenThere: model-t@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model <model-t.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/model-t>, <mailto:model-t-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/model-t/>
List-Post: <mailto:model-t@iab.org>
List-Help: <mailto:model-t-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/model-t>, <mailto:model-t-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 12:26:13 -0000

Sadly not for me, in part because of the IAB "AID" workshop,

-M

On 11/11/21 3:47 AM, Jari Arkko wrote:
> Updating time to avoid Thanksgiving.
>
> Would Thursday Dec 2nd, 22:00 Paris time, for one hour work? This is Thursday Dec 2nd, 13:00 San Francisco and Friday Dec 3rd, 08:00 Melbourne
>
> Jari
>
>> On 3. Nov 2021, at 14.18, Jari Arkko <jari.arkko@piuha.net> wrote:
>>
>> Hi,
>>
>> We’ve obviously not made much progress. This was discussed in previous IABOPEN session meeting in the summer, the IAB also discussed it subsequently.
>>
>> We could discuss why…. and have to some extent. Long story short, my opinion is that has been due to leadership problem (i.e., me) of not organising the group even to have meeting, despite fairly broad set of contributions. Secondly, in hindsight the original decision to focus on RFC 3552 updates may have been a mistake. IAB activities tend to do well on writing about architectural trends, principles to follow, etc, as we’ve seen with for instance RFCs 8546, 8558 or 8890. Thirdly, IAB activities other than one-time workshops are best done as something where there’s a strong drive and participation from IAB member(s), kind of as an extension of IAB helping to complete something, preferably something very specific.
>>
>> But we could also discuss what to do now, if anything. I personally still believe this is an important topic, perhaps one of the most important ones in the Internet, at least from my perspective. The question is perhaps how. The good things are that we do have plenty of contributions, we have interested people, we’ve also heard offers from volunteers to help with leading efforts, and so on. But what’s the best way to organise activities, and what activities make sense to begin with? And what to focus on?
>>
>> If we look at the different drafts, they can in my mind be classified into (1) general observations about attacks and trends with them, (2) architectural or security principles, and (3) updates of IETF guidance in RFCs 3552, 7258, etc. All of this is interesting, but have different nature. I think it is difficult for the program to get to a final result for the third category, for instance, simply because we don’t decide that in the end. And maybe the bar for that is too high anyway. The first category is very useful, but is also very dynamic in nature. And it is unclear to me to what extent there’s research in the academic world that would document some of that. Does someone know? I have a feeling that the drafts are more examples than comprehensive surveys, so more work would be needed.
>>
>> But perhaps there is some room for focused progress in the second category, documenting principles. For instance, Martin’s draft (draft-thomson-tmi) is an excellent contribution that addresses “intermediaries” and when/if they need to be involved. And what principles can be applied to ensure the involvement of intermediaries is done in reasonable manner. His concept is broader than middle boxes, by the way, covering even things like routers. I think this might be a potential direction for useful work, documenting principles such as those in Martin’s document. FWIW, I’m not suggesting that we must limit ourselves to that specific document — for instance, I think it would be useful to also discuss the role end-to-end services and how sharing of data with them can be done in a reasonable manner :-) But Martin’s document is certainly the one that in my mind is clearest and furthest ahead in this direction.
>>
>> Anyway, if we were to focus on more actionable architectural advice, then maybe it would be easier to see what we could do together. For instance, perhaps we could re-define model-t to work on 1-2 specific pieces of advice expressed as principles to follow. I’d personally be happy to work on that or help guide a document forward.
>>
>> But these are just my opinions. What do others think?
>>
>> Perhaps it would be useful to discuss this on a call, and also to review documents in light of the above. I’d tentative suggest the following time slot for the meeting: Thursday Nov 25th, 22:00 Paris time, for one hour. This is Thursday Nov 25th, 13:00 San Francisco and Friday Nov 26th, 08:00 Melbourne. Would this be a reasonable time, or do people see major conflicts? If I don’t hear loud objections in the next couple of days, I will set up the call and send a calendar invite.
>>
>> See below for a list of drafts related to the model-t discussions and my slide deck about the model-t situation from the summer IAB discussions.
>>
>> Jari
>>
>> ——
>>
>> draft-arkko-arch-internet-threat-model-guidance	
>> draft-arkko-arch-internet-threat-model	
>> draft-mcfadden-smart-endpoint-taxonomy-for-cless	
>> draft-lazanski-smart-users-internet	
>> draft-arkko-farrell-arch-model-t	
>> draft-lazanski-users-threat-model-t	
>> draft-lazanski-protocol-sec-design-model-t	
>> draft-mcfadden-smart-threat-changes	
>> draft-thomson-tmi	
>> draft-arkko-farrell-arch-model-t-7258-additions	
>> draft-arkko-farrell-arch-model-t-3552-additions	
>> draft-arkko-farrell-arch-model-t-redux	
>> draft-arkko-iab-data-minimization-principle
>>
>> <model-t-status-2021aug.pdf>--
>> Model-t mailing list
>> Model-t@iab.org
>> https://www.iab.org/mailman/listinfo/model-t

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780