Re: [Acme] Fwd: New Version Notification for draft-sweet-iot-acme-04.txt
Sebastian Nielsen <sebastian@sebbe.eu> Wed, 02 August 2023 17:17 UTC
Return-Path: <sebastian@sebbe.eu>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC110C14CE3F for <acme@ietfa.amsl.com>; Wed, 2 Aug 2023 10:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sebbe.eu
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 IHHn1_YyvR5C for <acme@ietfa.amsl.com>; Wed, 2 Aug 2023 10:17:31 -0700 (PDT)
Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CA4C14CF18 for <acme@ietf.org>; Wed, 2 Aug 2023 10:17:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Date:To:From:cc; bh=0LeX+z6nbdYEERsNC0tdA+B30ha1+uX6194vJlWHK8s=; b=bGRP4CMsJ8LtYi68/CUNfS4xLGH9CqfFFpf9Y2owjtGWPzPlRVmzCn6EZ2rCKAq+3alIW+n4Ml hqqVtkR8gFfvlJvZf6EGsbPPipydKcxrX27YpTOkmjuFkleSeEb4ycSEwz8IAotWYugQv0RGgApgl CjKIRbramwPwwPbLGfuU=;
Received: from localhost ([127.0.0.1] helo=sebastian-desktop) by sebbe.eu with esmtp (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1qRFTS-000CvZ-0B for acme@ietf.org; Wed, 02 Aug 2023 19:17:26 +0200
Received: from [192.168.1.188] (helo=DESKTOPA5BEHQI) by sebbe.eu with esmtpa (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1qRFTR-000CvW-L4 for acme@ietf.org; Wed, 02 Aug 2023 19:17:25 +0200
From: Sebastian Nielsen <sebastian@sebbe.eu>
To: 'Mailing List' <acme@ietf.org>
References: <169099211414.11957.13218136675686326535@ietfa.amsl.com> <C33D08FE-DB2A-4319-9FCD-45B6C2379D55@msweet.org> <CAOG=JU+Mp5SrP2mxeG==tRd+b9LLw3+KU3YcA7Dkx4yuk_G6Bg@mail.gmail.com>
In-Reply-To: <CAOG=JU+Mp5SrP2mxeG==tRd+b9LLw3+KU3YcA7Dkx4yuk_G6Bg@mail.gmail.com>
Message-ID: <006b01d9c565$35b148c0$a113da40$@sebbe.eu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01D9C575.F93ADC10"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFyCAfi5epXzZ2YAJPgq2oxnWYfWgE2sAicAkiqeYWwirilQA==
Content-Language: sv
X-Encryption-Target: external
Date: Wed, 02 Aug 2023 19:17:26 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/gorsT_JLb_7aoyprNDSGnu071bI>
Subject: Re: [Acme] Fwd: New Version Notification for draft-sweet-iot-acme-04.txt
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2023 17:17:35 -0000
7) Validity of certificates: <https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-iot-device-certificates> https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-iot-device-certificates >> I disagree with short validity. If the certificate is restricted to local domain names only, I suggest allowing validity up to 10 years. HOWEVER, if local certificates should be accepted by browsers as root, THEN there must be a mechanism, similar to DNS Rebinding protection, that prohibits an external site (that are not an RFC1918-IP or local resources) or a resource received externally (for example an email) from hyperlinking or redirecting to a .local resource, an private, loopback or local IP, or a mDNS resource. In the same thing, I see that reuse of key material, mentioned in 4.11 is no problem, as long as key material is NEVER reused along multiple devices (eDellSupport and such). If key material is reused among the same user only (same local network), I see no risks. 4.9 and 3.3 solves any issues that may exist with attacks, since each root certificate will only recongnize whatever exist on the very same local network. Since the device SHOULD regenerate certificate (4.5) when a “factory reset” is done, a device which changes owner (through selling on marketplace as used product) will not pose a security risk. There could be good to impose a rule, that a IoT device, should, on each power up: Set a flag “NeverConnected = true” Do power up connection. If a connection to a network for which it owns a certificate is found, then: “NeverConnected” should be set to false. IF a pairing of a new user is done to the device, AND the pairing is not done through a existing user (Pairing done with a button or similar) – AND “NeverConnected” is set to true, then it should do an automatic factory reset, or require a factory reset. However, if a new user is paired into the device through an old user, there is clear evidence the device is still possessed by the old user, and it does not make sense to reset the device otherwise. This ultimately protects a device which changes hands into a new user from any malicious attacks, even by the previous user, even if the new user does NOT factory reset the device. Best regards, Sebastian Nielsen
- Re: [Acme] Fwd: New Version Notification for draf… Amir Omidi
- [Acme] Fwd: New Version Notification for draft-sw… Michael Sweet
- Re: [Acme] Fwd: New Version Notification for draf… Sebastian Nielsen
- Re: [Acme] Fwd: New Version Notification for draf… Amir Omidi
- Re: [Acme] Fwd: New Version Notification for draf… Sebastian Nielsen
- Re: [Acme] [Iotops] Fwd: New Version Notification… Michael Sweet
- Re: [Acme] Fwd: New Version Notification for draf… Michael Sweet
- Re: [Acme] Fwd: New Version Notification for draf… Carl Wallace
- Re: [Acme] New Version Notification for draft-swe… Michael Sweet