Re: [secdir] secdir review of draft-ietf-netconf-zerotouch-22

David Mandelberg <> Sat, 18 August 2018 00:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C03A3130FF0 for <>; Fri, 17 Aug 2018 17:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9F6VBR1BzYxC for <>; Fri, 17 Aug 2018 17:19:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A67D130FF4 for <>; Fri, 17 Aug 2018 17:19:33 -0700 (PDT)
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=KaWQikQD c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=dapMudl6Dx4A:10 a=bmmO2AaSJ7QA:10 a=48vgC7mUAAAA:8 a=BTUBnpS-AAAA:8 a=v_OVUiDecUYEfxGDTDQA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=pblkFgjdBCuYZ9-HdJ6i:22
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: ZHNlb21uQHJjbi5jb20=
Authentication-Results:; sender-id=neutral
Authentication-Results:; spf=neutral; sender-id=neutral
Authentication-Results:; auth=pass (LOGIN)
Received-SPF: neutral ( is neither permitted nor denied by domain of
Received: from [] ([] by (envelope-from <>) (ecelerity r(Core: with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 44/6B-45687-216677B5; Fri, 17 Aug 2018 20:19:31 -0400
Received: from [] (DD-WRT []) by (Postfix) with ESMTPSA id 47CF91C605C; Fri, 17 Aug 2018 20:19:26 -0400 (EDT)
To: Kent Watsen <>, "" <>, "" <>, "" <>
References: <> <> <> <> <> <>
From: David Mandelberg <>
Message-ID: <>
Date: Fri, 17 Aug 2018 20:19:18 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-netconf-zerotouch-22
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Aug 2018 00:19:37 -0000

On 08/14/2018 09:59 PM, Kent Watsen wrote:
> Hi David,
> Trimming down to just the remaining items...
>>> I was writing the Security Considerations for this when it seemed
>>> that the better thing to do here is to instead add "not-before" and
>>> "not-after" leafs to the zerotouch information artifact.  The draft
>>> would then explain that devices MUST ensure the current time is in
>>> between.
>>> Would such an addition resolve this issue for you?
>> Yes, that would work. It probably makes sense to say something in
>> the security considerations about keeping those validity intervals
>> short.
>> If you prefer to leave the data formats and implementations unchanged,
>> you could also consider using per-CMS EE certificates, like the RPKI
>> does: (I haven't
>> thought about how compatible that method is with zerotouch, I'm just
>> mentioning it as an alternative in case it happens to be easier for you.)
> Ah, this is an interesting idea.  Actually, I'd say that there is a
> near 1-1 correspondence between EE certificates and what this draft
> is calling the owner cert.  Section 3.2 says about owner certs:
>     The owner certificate CMS structure MUST contain the owner
>     certificate itself, as well as all intermediate certificates leading
>     to the 'pinned-domain-cert' certificate specified in the ownership
>     voucher.  The owner certificate artifact MAY optionally include the
>     'pinned-domain-cert' as well.
> While we conceptually think of the owner certificate as a singleton,
> there is nothing in the draft that prevents a unique owner certificate
> per device, which would allow for per-device validity and revocation to
> be supported.
> This being the case, I think that the following Security Consideration
> section should be added:
>     9.11.  Validity Period for Zero Touch Information
>     Zero touch information does not specify a validity period.  For
>     instance, neither redirect information nor onboarding information
>     enable "not-before" or "not-after" values to be specified, and
>     neither artifact alone can be revoked.
>     For unsigned data provided by an untrusted source of bootstrapping
>     data, it is not meaningful to discuss its validity period when the
>     information itself has no authenticity and may have come from
>     anywhere.
>     For unsigned data provided by a trusted source of bootstrapping data,
>     the availability of the data is the only measure of it being current.
>     Since the untrusted data comes from a trusted source, its current
>     availability is meaningful.

(nit) The only trusted sources of bootstrapping data are TLS servers, 
right? I think this paragraph would be a bit stronger if you explicitly 
mentioned that TLS's integrity guarantee and replay protection are what 
you're relying on here.

>     For signed data, whether provided by an untrusted or trusted source
>     of bootstrapping data, the validity is constrained by the validity of
>     the both the ownership voucher and owner certificate used to
>     authenticate it.
>     The ownership voucher's validity is primarily constrained by the
>     ownership voucher's "created-on" and "expires-on" nodes.  While
>     [RFC8366] recommends short-lived vouchers (see Section 6.1), the
>     "expires-on" node may be set to any point in the future, or omitted
>     altogether to indicate that the voucher never expires.  The ownership
>     voucher's validity is secondarily constrained by the manufacturer's
>     PKI used to sign the voucher; whilst an ownership voucher cannot be
>     revoked directly, the PKI used to sign it may be.
>     The owner certificate's validity is primarily constrained by the
>     X.509's validity field, the "notBefore" and "notAfter" values, as
>     specified by the certificate authority that signed it.  The owner
>     certificate's validity is secondarily constrained by the validity of
>     the PKI used to sign the voucher.  Owner certificates may be revoked
>     directly.
>     For owners that wish to have maximum flexibility in their ability to
>     specify and constrain the validity of signed data, it is RECOMMENDED
>     that a unique owner certificate is created for each signed artifact.
>     Not only does this enable a validity period to be specified, for each
>     artifact, but it also enables to the validity of each artifact to be
>     revoke.
> What do you think?

Looks good!

>>> Do you think it's worth adding a warning to operators somewhere to
>>> remind them to change the flag? Or maybe the "device SHOULD report a
>>> warning if the bootstrapping completes successfully but zerotouch
>>> bootstrapping is still enabled"?
> I forgot to respond to this comment of your before.  To address this
> comment, I added the following:
>     If the onboarding information was obtained from a trusted bootstrap
>     server, and the result of the bootstrapping process did not disable
>     the "flag to enable zerotouch bootstrapping" described in
>     Section 5.1, the device SHOULD send an "bootstrap-warning" progress
>     report.


>>>> I think it's already clear what an error in paragraph 6 is. What I found
>>>> unclear was what to do with errors in paragraphs 6 or 7. Yes, don't go
>>>> on to the next step, but what about: In paragraph 6, should the device
>>>> rollback any partial config update if there's an error? In paragraph 7,
>>>> should the device rollback all config from paragraph 6 if there's an error?
>>> This very same issue was raised to me separately and my response has been
>>> to essentially rewrite section 5.6 to be crystal clear on how errors are
>>> handled, especially with regard to state retained.  Please see attached
>>> for a preview of -23.
>> Much better, thanks!
> FIW, this text is going thru a WG churn, but the essence of what I attached
> before is being retained.

Sounds good.