From nobody Wed Aug 2 10:17:37 2023 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 ) id 1qRFTR-000CvW-L4 for acme@ietf.org; Wed, 02 Aug 2023 19:17:25 +0200 From: "Sebastian Nielsen" To: "'Mailing List'" References: <169099211414.11957.13218136675686326535@ietfa.amsl.com> In-Reply-To: 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: Subject: Re: [Acme] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-sweet?= =?utf-8?q?-iot-acme-04=2Etxt?= X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2023 17:17:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006C_01D9C575.F93ADC10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 7) Validity of certificates: = = https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-iot-dev= ice-certificates =20 >> I disagree with short validity. If the certificate is restricted to local domain names only, I suggest = allowing validity up to 10 years. =20 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. =20 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. =20 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. =20 Since the device SHOULD regenerate certificate (4.5) when a = =E2=80=9Cfactory reset=E2=80=9D is done, a device which changes owner = (through selling on marketplace as used product) will not pose a = security risk. =20 There could be good to impose a rule, that a IoT device, should, on each = power up: Set a flag =E2=80=9CNeverConnected =3D true=E2=80=9D Do power up connection. If a connection to a network for which it owns a certificate is found, = then: =E2=80=9CNeverConnected=E2=80=9D should be set to false. =20 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) = =E2=80=93 AND =E2=80=9CNeverConnected=E2=80=9D is set to true, then it = should do an automatic factory reset, or require a factory reset. =20 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. =20 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. =20 =20 Best regards, Sebastian Nielsen ------=_NextPart_000_006C_01D9C575.F93ADC10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

>> 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 =E2=80=9Cfactory reset=E2=80=9D 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 = =E2=80=9CNeverConnected =3D true=E2=80=9D

Do power up = connection.

If a connection to a network = for which it owns a certificate is found, then:

=E2=80=9CNeverConnected=E2=80=9D= 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) =E2=80=93 AND = =E2=80=9CNeverConnected=E2=80=9D 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.

 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Best regards, Sebastian = Nielsen

------=_NextPart_000_006C_01D9C575.F93ADC10--