IETF Logo Mail Archive

Re: [COSE] Paul Wouters' Discuss on draft-ietf-cose-countersign-09: (with DISCUSS and COMMENT)

Paul Wouters <paul.wouters@aiven.io> Fri, 09 September 2022 00:36 UTC

Return-Path: <paul.wouters@aiven.io>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E11EC1522B2 for <cose@ietfa.amsl.com>; Thu, 8 Sep 2022 17:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uLr8Zutj8pG for <cose@ietfa.amsl.com>; Thu, 8 Sep 2022 17:36:38 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76658C1522B7 for <cose@ietf.org>; Thu, 8 Sep 2022 17:36:38 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id z191so257121iof.10 for <cose@ietf.org>; Thu, 08 Sep 2022 17:36:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date; bh=qVMu9MYT0Ya03fbFkWktIvS1RhIeEz2rwRIm+BsYSBw=; b=EkNHKkg2w3zrZiVMth/dXnLH2fA6fkqRwWQF4af1wXLBeGIA9EM9vmz0emC7Ax+8wq 71OwbyZbgl6Ct44p3/bqvrpPs90Cz4QGg+lEv7x2TrRcld/CyboYG6N90zZAG3y5xGaj MuQ5jINjEE3qJKOpodOWUeWm4Ga3iXrU+30Ec=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date; bh=qVMu9MYT0Ya03fbFkWktIvS1RhIeEz2rwRIm+BsYSBw=; b=v9ls9IRJ9k7jm6e5uXgZIbRFNzLQAOS9oInJ5MywgOIfc4PASFldwwWYl0i1Cchcnn GD9AKxiOlW8/nWTdppfzRYmEWv6hSsdxafS1Igx660/t/YxbCLKsyO3Xh3MKWaSDIZeW WQEHlniO81/+CMncFJriqIhS7HUdgRCEgScqh8Th4spa/UiUzB8CB8DHM0kYwC0BEWjK rmqLImbWGN4p/nHMp/fc6FCnsaTSkZXjg3paS4ZHGI86KCBtY7H5cOC86RTr8elh4zkz lI492tyJnuneXC+0tUNe868eJlRzcODEfOn625J2ABMP+wElqr/gFUHdWyR8Uahb34Es 330g==
X-Gm-Message-State: ACgBeo1GSe8zWMyCWtdPg8GMogH/HPldie0XaoExnlt/hBG5W+fhIP3j P72C3sXB//Mu6APK1HHzNIAi/A==
X-Google-Smtp-Source: AA6agR6vOuGOL3sq1g328Owp5gNvqJT8RqUgoFDWotOmmtJFi6P2aoDlk37wZK2Ba+3RX3Znc/qGRg==
X-Received: by 2002:a05:6638:1396:b0:357:148d:8705 with SMTP id w22-20020a056638139600b00357148d8705mr5213403jad.61.1662683796843; Thu, 08 Sep 2022 17:36:36 -0700 (PDT)
Received: from smtpclient.apple ([2605:8d80:64b:b891:15e1:c93b:25d2:ed7a]) by smtp.gmail.com with ESMTPSA id t33-20020a05663834a100b0034f465bbd52sm192097jal.42.2022.09.08.17.36.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Sep 2022 17:36:36 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-C522491D-8F34-4315-A162-43347444C115"
Content-Transfer-Encoding: 7bit
From: Paul Wouters <paul.wouters@aiven.io>
Mime-Version: 1.0 (1.0)
Date: Thu, 08 Sep 2022 20:36:33 -0400
Message-Id: <FC9567D0-B3D7-4ED5-BB83-CCCC1A343613@aiven.io>
References: <E226CF54-4C8C-490A-839A-6B0E3DF34EFC@vigilsec.com>
Cc: Carsten Bormann <cabo@tzi.org>, IESG <iesg@ietf.org>, draft-ietf-cose-countersign@ietf.org, Cose Chairs Wg <cose-chairs@ietf.org>, cose <cose@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
In-Reply-To: <E226CF54-4C8C-490A-839A-6B0E3DF34EFC@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: iPhone Mail (19G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/uKOZcbskH1F1fQxInBa4h7x8vPI>
Subject: Re: [COSE] Paul Wouters' Discuss on draft-ietf-cose-countersign-09: (with DISCUSS and COMMENT)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2022 00:36:43 -0000

I am fine with a pointer to a downloadable source which can also contain the commands to install the software. Upon compromise, the pointer can be updated to protect the immutable RFC text. Wether it points to GitHub or IETF or elsewhere doesn’t matter to me.

Paul

Sent using a virtual keyboard on a phone

> On Sep 8, 2022, at 16:04, Russ Housley <housley@vigilsec.com> wrote:
> 
> 
> 
>> On Sep 8, 2022, at 1:47 AM, Carsten Bormann <cabo@tzi.org> wrote:
>> 
>>> On 2022-09-08, at 04:14, Paul Wouters via Datatracker <noreply@ietf.org> wrote:
>>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>>       gem install cbor-diag
>>> 
>>> I am concerned about adding install commands for "programs from the internet"
>>> within an RFC. If the rubygem for some reason becomes malicious, we cannot
>>> pull it from the RFC (even if we pull it from the datatracker link, it would
>>> still live on in copies of the RFC elsewhere and malicious people could point
>>> to copies of those original RFCs to point people to downlod the malicious rubygem.
>>> 
>>> I would be okay with an iet.org download location of a ruby gem.
>> 
>> “gem install” is the appropriate way to install rubygems software, not a “location of a rubygem”.
>> 
>> What you seem to be asking for is some indirection so we can swap out the name of the gem in case cbor-diag becomes rogue.  That does make some sense to me, but we’d need to install that indirection somewhere in a place maintained by the IETF.
>> 
>> ➔ “Please consult https://www.ietf.org/software/cbor-diag for the way to install this software”.
>> And that page would contain instructions including “gem install cbor-diag” until that goes rogue.
>> 
>> Can we get such a infrastructure of pages recommending software up and running?  Do we mire ourselves in process issues (who gets change control etc.)?
>> 
>> Data point from a quick search:
>> The RFCs that already suggest installing rubygems via a direct “gem install” include RFC 8152, RFC 8610, RFC 9052.
>> 
>> (In reality, I’d expect the rubygems organization to act more quickly on a report of cbor-diag going rogue than the IETF would.)
>> 
>> Grüße, Carsten
> 
> 
> Paul:
> 
> Are you satisfied with this explanation? Or, would you prefer the pointer to https://www.ietf.org/software/cbor-diag
> 
> Russ
>

v2.23.0 | Report a Bug | By Email