Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

Kent Watsen <kwatsen@juniper.net> Mon, 07 January 2019 21:13 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1049212DF71; Mon, 7 Jan 2019 13:13:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level:
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 OzTVoJpgZ1qf; Mon, 7 Jan 2019 13:13:00 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC4912D7EA; Mon, 7 Jan 2019 13:13:00 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x07KveGo004134; Mon, 7 Jan 2019 12:58:58 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=yeC2MXWH4n9Ih/D0eWkDQoRMHWcpvpmte5lQdkcpqSQ=; b=a6e32BoMD0b0n4bDeammnLqtB4g03CnvAMMWUD+bHwVWnn+MBtxpKpYE68S6T284FrRQ bXgVVIU5LbwG5kSSbKNFawVc572etBVjJ4T3DWbKs3R/0WCMuTZHnuoE2UIgWTeVKmx3 8DTpzOiDxpdE9Dagur8IDomBqc0KPl72G7hJszdXjZ1Vh7OWoDQ14DryyTXPsjfaozPu sZ2kysYd0qkYJm+7cnulq8u8PVxAuPH6XNJPnSapcSpM+mkIrs5tKSvYY9YpN8xSg+27 E0509/s4p3AgtVJVR3FmHhHVkJqycDxdrd/E+wT3exr6puFu86ndK/fV96K0F1ji5Ydo Qw==
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2051.outbound.protection.outlook.com [104.47.32.51]) by mx0a-00273201.pphosted.com with ESMTP id 2pv4q30uwu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 07 Jan 2019 12:58:58 -0800
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4921.namprd05.prod.outlook.com (20.176.112.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.7; Mon, 7 Jan 2019 20:58:55 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::c9e6:54c9:90c8:211e]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::c9e6:54c9:90c8:211e%2]) with mapi id 15.20.1516.010; Mon, 7 Jan 2019 20:58:55 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "draft-ietf-netconf-zerotouch@ietf.org" <draft-ietf-netconf-zerotouch@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-dnsop-attrleaf@ietf.org" <draft-ietf-dnsop-attrleaf@ietf.org>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
Thread-Index: AQHUi5qky69pAtgeuk6GIUpsNSYi7qVz1VIAgCLBFICAB70FgIADj4qAgAJJm4A=
Date: Mon, 7 Jan 2019 20:58:55 +0000
Message-ID: <35A436B3-5D57-4015-A51E-5F9A1E349D31@juniper.net>
References: <154390493154.31734.13025584839857369253.idtracker@ietfa.amsl.com> <F526DA60-77EC-45D6-ADE0-B345020A89BF@juniper.net> <20181230003002.GC57547@kduck.kaduk.org> <5DCD6C74-7918-45AB-BEA7-2C1A020B4411@juniper.net> <20190106050255.GJ28515@kduck.kaduk.org>
In-Reply-To: <20190106050255.GJ28515@kduck.kaduk.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.5.181209
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4921; 6:eg0tX9UXAq3CcpmJoLfWGOQUYc1OA4fmFbjaD625a4pU57Sp3m2TsphA8gqxnKXK0tma8UXFGmbbO8AdmjmWS5SEI7e0Ve7tUaSq1fpUC0A+QOox2YOajxTHWMk4wyHCebnJNNu1AWSQJBezNPHn7yWsXTmRG4WTnAP1GDyicQwE3G09uQBYwnqET0N9Zoxhee85Kx8ebmX7G4T245lqriBb8VQZIP7Ephk8W4AE3ThpldwPKVv0r06NLcVXEPOtHAMzvHMvyXThxEB54X86zuFlbQ5takAZG76CACt3V8wPbuOskazzpLM0fVjmzdLSoUGMCmf4SmC0cLePeXm7XW5MCxbhHx8knBRiNgl2/SrzZDcj9/+z+ZsXuKeE43Xp+nFrG2Ogj0xIQjQmPPFF2/v28/c/CXpYeWR1q0bnasIL6vJeCxJt6IDSSlZCBddGtPSHdK4D7yAVl/Y35b78dA==; 5:3WF3EJelygIWR5OSm+2kRL+imIvBCeGcxyiwKl+JuZ0+jZPVbOyfjg40k991oFjjYLRFm9hxcPTNRxbk0unP5f75HODw9gVo67geuSQ3Hj9YFJliRg7OrHk7b5v9eML+sKhR3QykHR3GW7IST1Z4P4VBuUw24hfUJfAaHXm4JX4ftfnOp3WYBqwsp/wqQO9I6sQ1gYlyBk6eXcZ856zxJw==; 7:OHH7bRcQL3saCD16+Hz9Hlvc8a7feZVWQdEZ2S9TIqQftMfUZ8XTkw8cwddFx22NpjvwHC/6VHXmqSoNneaEP8aIiutWfCtm7tKF0rgJOJsgyK9gAvVbWmhA26pjYMF/s/lgDDam3+pLp2BKx/QpCg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 3252404a-93a1-4f6b-0a12-08d674e2efe2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4921;
x-ms-traffictypediagnostic: DM6PR05MB4921:
x-microsoft-antispam-prvs: <DM6PR05MB49215A63ECEF2F3B97005350A5890@DM6PR05MB4921.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3231475)(944501520)(4982022)(52105112)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4921; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4921;
x-forefront-prvs: 0910AAF391
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(376002)(346002)(136003)(39860400002)(51444003)(53234004)(189003)(199004)(51914003)(58126008)(561944003)(54906003)(14454004)(36756003)(71190400001)(102836004)(76176011)(6436002)(6506007)(68736007)(316002)(6246003)(26005)(83716004)(66066001)(99286004)(4744004)(53946003)(6512007)(93886005)(345774005)(71200400001)(53936002)(6306002)(4326008)(33656002)(2171002)(25786009)(11346002)(446003)(305945005)(2616005)(186003)(7736002)(476003)(14444005)(256004)(478600001)(6916009)(8936002)(97736004)(3846002)(6116002)(2906002)(966005)(81156014)(8676002)(86362001)(229853002)(106356001)(5660300001)(6486002)(105586002)(486006)(82746002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4921; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: xeHR7Oi1OfcOaUHDAz0soOERqbbfFhEgomVxfcDm6ajSmLWNr+tqU1i/OXSLELimcNcjwwrIGM5TihQLMKUZ4YBk6EwVZIaIW7m+zrBUW211QADyczrL38qu9bL4AnxAMFA1IDIOiRqotPb8VJaD2SLMN3H3XU6gkXc8OxFGw+hhG9Nec8yf1sNg9C1aDvmjwsm7gpNqsdnIBA/83EwGAvoD3BjuWdisYDyZdB0i7buRMdeqZyNSZIiaiypcIvRRxq8BjI7Qj/+WmqppEkYvkrB6ULInb14zWAsDKhY5VTR+L4R9Pp/40euDVZINAR9V
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5C619BCDA7888C4898480F28E8ECEDCF@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 3252404a-93a1-4f6b-0a12-08d674e2efe2
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2019 20:58:55.3962 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4921
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070173
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/yf2g3W5Yb-iDNt6BhmtuQyhX_60>
Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2019 21:13:04 -0000

[adding Dave, author of the draft-ietf-dnsop-attrleaf]


Hi Ben,

  I have trimmed the below response down to just the remaining open items.


Hi Dave,

  Could you please search for "draft-ietf-dnsop-attrleaf" in this thread,
  which regards this Section 4.2 of the zerotouch draft [1], and provide
  your opinion?  In particular, since _sztp is under _tcp, does that mean
  that it is not a globally scoped entry?
 
  [1] https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-27#section-4.2),


Thanks,
Kent


>> >> > ----------------------------------------------------------------------
>> >> > DISCUSS:
>> >> > ----------------------------------------------------------------------
>>
>> >> > (3) Nonce length
>> >> >
>> >> > Section 7.3 describes the nonce leaf:
>> >> >
>> >> >         leaf nonce {
>> >> >           type binary {
>> >> >             length "8..32";
>> >> >
>> >> > There is probably some discussion to be had about the minimum nonce
>> >> > length (not necessarily in the document itself).  Do you have a 
>> >> > pointer handy to previous disucsions or do we need to have it now?
>> >> > (I do see that this is just following RFC 8366, so hopefully this
>> >> > is an easy question.)
>> >> 
>> >> 
>> >> I sent email to my RFC 8366 co-authors, as they were behind setting
>> >> this min nonce length.  I have yet to hear back from them, but will
>> >> let you know when I do.
>> >
>> > [covered in separate thread]
>> 
>> [Bringing back into this thread]
>> 
>> I emailed the RFC 8366 authors (CC you) regarding your concern with the
>> minimum-allowed nonce length.
>> 
>> As for this draft, I feel that the easiest solution is to change the YANG
>> as follows:
>> 
>>        leaf nonce {
>>          type binary {
>> -          length "8..32";
>> +          length "16..32";
>>          }
>> 
>> It is within the range allowed by RFC 8366 (i.e., no compatibility violation)
>> while eliminated the low-end that you objected to.  I can't imagine there
>> being an issue in asking a low-end device (even a measly IoT thing) to generate
>> an extra 8 bytes of random data.
>> 
>> I've made this change in -27.
>
> Sounds good.  This is certainly the easiest way forward, and if there are
> no objections there's not much reason to not just go with it.  I may have
> some generic desire in the abstract to fully understand whether it's
> needed, but I am pretty sure I can suppress that desire if needed :)

Okay, let's just go with it.  You may want to engage Michael Richardson, from
that fork in this thread, to consider if there is a true need.



>> >> > ----------------------------------------------------------------------
>> >> > COMMENT:
>> >> > ----------------------------------------------------------------------
>> 
>> >> > I a little bit wonder if we want references for TLS and/or HTTP client
>> >> > authentication.  Section 2.5 of RFC 8040 might be enough (though it is
>> >> > of course not citing TLS 1.3).
>> >> 
>> >> This draft's use of TLS and HTTP authentication is exclusively for
>> >> RESTCONF (RFC 8040).   I'm generally hoping to just reference that
>> >> RFC and let it speak for itself.
>> >> 
>> >> Correct, RFC 8040 does not cite TLS 1.3 explicitly, though TLS 1.3 is
>> >> allowed, as Section 2.1 says:
>> >> 
>> >>    RESTCONF does not require a specific version of HTTP.  However, it 
>> >>    is RECOMMENDED that at least HTTP/1.1 [RFC7230] be supported by all
>> >>    implementations.
>> >> 
>> >> BTW, does this comment regard Section 9.6?  
>> >
>> > Section 9.6 is about making sure the client does not send sensitive data to
>> > an unauthenticated server, which is not limited to the data in the
>> > certificate; my comment here is more about the mechanics of the client
>> > authenticating itself to a server for the server to make authorization
>> > decisions (admittedly, I did not mention "authorization" prior to now, so
>> > my apologies for being unclear).  Client authentication is mentioned
>> > directly or in passing in at least sections 5.1 (which does mention Section
>> > 2.5 of RFC 8040 already) and 5.3 (ditto), as well as 9.6.
>> 
>> As you say, authentication is mentioned in several places already 
>> and, if I understand you correctly, this text is sufficient.
>> 
>> While the word "authorization" does not appear in this document, 
>> Section 9.13 discusses "access", which relates to statements in 
>> RFC 8040, such as:
>> 
>>    The RESTCONF server MUST authenticate client access to any protected
>>    resource.
>> 
>>    The server MUST NOT allow any RESTCONF operation for any resources
>>    that the client is not authorized to access.
>> 
>> To provide a more complete picture, the bootstrap server exposes just
>> two RPCs.  Each RPC *requires* an authenticated client-credential to
>> function.  That is, "get-bootstrapping-data" can only return the 
>> bootstrapping data for the authenticated client credential; there is
>> no other parameter passed for the server to determine which data to 
>> return. Likewise, "report-progress" can only report progress for the
>> authenticated client credential; there is no other parameter passed
>> for the server to determine for which client is reporting the data.
>> 
>> This COMMENT began by asking if we might want references for TLS 
>> and/or HTTP client authentication, and now maybe authorization.
>> Given the above discussion, what is your recommendation?
>
> I think that the document will be good with no additional change for this
> matter; the contents of RFC 8040 and the way we use RESTCONF makes things
> clear enough.

Excellent.  This item is closed.



>> >> > Section 3.4
>> >> >
>> >> > Thank you for including the motivating text about sign-then-encrypt.
>> >> > I do wonder if it's worth saying anything about why the well-publicized
>> >> > security risks of mac-then-encrypt do not apply.  (The authors of
>> >> > draft-campbell-sip-messaging-smime probably already have some text
>>> >> > that could be used, but it doesn't seem to be in the public view yet.)
>> >> 
>> >> Are you referring to the padding oracle attack?  As mentioned above, the
>> >
>> > Right.
>> >
>> >> solution presented in this document doesn't lend the device to being a
>> >> very good decryption oracle.  I suppose the fix would be to add to this
>> >> section (or the Security Considerations section?) something like:
>> >> 
>> >>   This document specifies the encryption of signed objects, as opposed
>> >>   to the signing of encrypted objects, as might be expected given well-
>> >>   publicized oracle attacks (e.g., the padding oracle attack).  This
>> >>   document does not view such attacks as being feasible in the context
>> >>   of the solution because i) the decrypted text never leaves the device
>> >>   and ii) the solution does not differentiate between a "bootstrap-error"
>> >>   cause by a decryption failure versus a failure occurring when parsing
>> >>   the decrypted text.
>> >
>> > That works for me, thanks.  (But feel free to leave it out if you don't
>> > think it's adding value, too.)
>> 
>> I added a slightly reduced version of the above text (taking out clause "ii"):
>> https://github.com/netconf-wg/zero-touch/commit/388d0355b3c7c6ce4aa48028a4ef89dc64147304.
>> 
>> Still good?
>
> Yes.

Zipping along (item closed)


  

>> >> > Section 4.2
>> >> >
>> >> > I agree with Adam about registering "zerotouch" (and the name is
>> >> > perhaps overly generic?).
>> >> >
>> >> > I'm also not sure I properly understand the "zt-info"/zt-* TXT
>> >> > records' usage; would they need to be registered akin to
>> >> > draft-moonesamy-dnsop-special-use-label-registry?
>> >> 
>> >> First, regarding the term "zerotouch" being perhaps overly generic,
>> >> I have somewhat felt this way for a while.  One thing that could be
>> >> done fairly easily is to more the bulk of the "zerotouch" references
>> >> to "sztp", the acronym given throughout.  Admittedly, what SZTP
>> >> stands for isn't tremendously better, but I think that it is
>> >> generally better than just "zerotouch".  Thoughts?
>> >
>> > SZTP does seem better than just "zerotouch" to me, all things considered.
>> 
>> 
>> Okay, I did the following:
>> 
>>   When referring to the draft/solution:
>>     Zero Touch --> SZTP
>> 
>>   When referring to the bootstrapping artifact:
>>     zero touch information --> conveyed information
>>     zerotouch-information  --> conveyed-information
>> 
>>   For the CMS content types:
>>     id-ct-zerotouchInformationXML  --> id-ct-sztpConveyedInfoXML
>>     id-ct-zerotouchInformationJSON --> id-ct-sztpConveyedInfoJSON
>> 
>>   For the YANG modules:
>>     ietf-zerotouch-information.yang      --> ietf-sztp-conveyed-info.yang
>>     ietf-zerotouch-bootstrap-server.yang --> ietf-sztp-bootstrap-server.yang
>> 
>>   For the DNS/service name:
>>     _zerotouch --> _sztp
>> 
>> A big change, though I scripted most of it. Here's the diff:
>> https://github.com/netconf-wg/zero-touch/commit/394b863d1850019fd451554a9f86c3c10d280d08
>
> Thank you for your willingness to make these disruptive changes "for the
> good of the team"; I know it's pretty thankless work.

Your welcome, and thanks for the acknowledgement.  (item closed)




>> >> Second, I am not a DNS expert, do you know who we can discuss
>> >> such things with?  That said, I guess our idea was to use TXT
>> >> records like RFC 1464, where the TXT value itself has the form
>> >> "<attribute name>=<attribute value>", in which case it doesn't
>> >> seem to need IANA registration?
>> >
>> > Please correct me if I'm wrong, but I think this issue was
>> > already covered in a different AD's ballot thread.
>> 
>> Correct, Section 4.2 was updated (posted in -26) per Alexey's DISCUSS.
>> Per your original comment (and his, and Adam's), Section 10.6 now
>> requests IANA to register the service name "sztp" (was "zerotouch"). 
>> 
>> > That said, the addition of <serial number>._zerotouch.fqdn in the
>> > -26 seems to indicate that mention of draft-ietf-dnsop-attrleaf
>> > is appropriate, if I remember correctly how that works.
>> 
>> I've just now read draft-ietf-dnsop-attrleaf.  I see the applicability,
>> but I don't understand your proposal.  Looking at DataTracker, I see
>> that it is already in RFC Ed Queue, so I think you're suggesting me
>> treat it as a fait accompli, and add an IANA Consideration section
>> to register "_sztp", yes?  Assuming that is the case, then what should
>
> From memory, yes.
>
>> be done with the service name registration in Section 10.6, added per
>> comments from Alexey and Adam?
>
> I think we'll need to get some further input from Alexey and/or Adam, but
> my understanding is that we would need both registrations -- the service
> name registration covers our _sztp._tcp.fqdn SRV records, but we are also
> using <serial number>._sztp._tcp.fqdn TXT records, and so (IIUC) we'd need
> to add a reference to this document for the TXT _tcp entry that RFC 6763
> (DNS-SD) is currently the reference for.

This item remains open.  Hopefully Dave can provide guidance.




>> >> >   The device MUST parse the provided onboarding information document,
>> >> >   to extract values used in subsequent steps.  Whether using a stream-
>> >> >   based parser or not, if there is an error when parsing the onboarding
>> >> >
>> >> > This line makes me consider the scenario where a stream-based parser is
>> >> > used with a trusted bootstrap server and no CMS-layer signature.  At the
>> >> > TLS layer, a truncation attack by the network is possible, and if
>> >> > truncation is not detectable at the application layer, the device could end
>> >> > up misconfigured with neither party aware (unless there's an additional
>> >> > response or something that I'm forgetting about).  I think that for the XML
>> >> > and JSON formats we know and love, truncation would make for a malformed
>> >> > stream due to the outermost scope container, but please correct me if I'm
>> >> > wrong.  There are probably some security considerations to mention w.r.t.
>> >> > any future new encodings of this data model, though.
>> >> 
>> >> The steps are roughly: 
>> >>   a) HTTPS GET an XML/JSON document (the get-bootstrapping-data" response).
>> >>   b) extract the CMS-based artifacts from the XML/JSON document.
>> >>   c) if encrypted, decrypt.
>> >>   d) if signed, authenticate.
>> >>   e) extract the onboarding-information (another XML/JSON doc) from the CMS artifact.
>> >>   f) process the onboarding-information XML/JSON doc
>> >> 
>> >> So here we're at step (f), where the text mentions the possible use of a
>> >> stream parser.  This is rather long after step (a), where TLS truncation
>> >> may occur and, presumably caught in step (b).  This is by way of saying
>> >> that I don't think this is an issue, but interested to hear your response.
>> >> 
>> >> FWIW, the point of this "stream-based parser" comment is to highlight
>> >> that, unlike most all the other progress-types, which seem to reflect
>> >> a serial processing of the steps, the parsing may either be a distinct
>> >> step (e.g., a DOM-based parser) or something that is splayed across all
>> >> the other steps (a stream-based parsed).  In the first case, the all
>> >> the "parsing-*" progress reports (including any parsing-error report)
>> >> are expected to be transmitted before any, e.g., boot-image-* reports
>> >> are sent; whereas, in the second case, the parsing-* reports can be
>> >> intermixed.
>> >> 
>> >> I don't think there is a TLS concern, but perhaps the paragraph needs
>> >> to be reworded?
>> >
>> > I think your understanding basically matches mine; I tried to include in my
>> > remark that it would only possibly apply to the case where the predicates
>> > for (c) and (d) are false.  I just plain don't know whether (a)/(b) will
>> > choke if the GET response is an incomplete XML/JSON document.  If it
>> > properly errors out, then there's no concern here, and we should just move
>> > on.  In any case, even if there was an issue, this paragraph would not
>> > really be the place to talk about it -- my comment is only located here
>> > because this is where we start talking about stream-based parsers.  The
>> > errors in question are not necessarily those generated by the stream-based
>> > parser, but can also include those generated at earlier steps.
>> 
>> Okay, if we step back from the stream-parsing angle, and instead just focus
>> on the TLS truncation concern, my first thought is that said error will be
>> detected in (a) and (b) will not be entered.  In case (b) is entered, then
>> it seems that (b) would detect a malformed response from the server, as it
>> would normally need to do.
>
> Okay, defense in depth is a good thing.  It sounds like we don't need to
> say anything about this in the document, IIUC.

Thanks for letting this slide.  (item closed)


  
>> >> > Section 6.2
>> >> >
>> >> > "base64encodedvalue==" is pretty cute, though maybe we could add some
>> >> > trailing numbers to provide different values for the different fields?
>> >> 
>> >> The issue here is that the example documents must be valid (fwiw, they
>> >> are tested each time `xml2rfc` is run).  Previous versions of this 
>> >> document included compete base64 encoding of the real objects, but 
>> >> people complained that it greatly distracted from readability.  To
>> >> address this, the WG agreed to use "base64encodedvalue==" in examples
>> >> to represent YANG "binary" data.
>> >> 
>> >> Is it okay to leave this as is?
>> >
>> > This is a non-blocking comment, so by definition my answer is "yes" :)
>> > I mostly just wanted to point out that the examples use the same literal
>> > string to fill in for many different data types -- I agree with not using
>> > "real" examples since they're bulky and not readable in encoded form, but
>> > was just wondering if we could use different short strings to represent
>> > semantically different objects.
>> 
>> Okay, let's close this with no update.  That said, you may be pleased (or
>> irked) to see that the nonce min-length change forced one example to have
>> to change to "<nonce>extralongbase64encodedvalue=</nonce>" in order to pass
>> build-time validation tests ;)
>
> Cool, I wish my CI was that good :)

Really, it's the only way to go.  The time spent setting it up is easily
recovered in the course of the project.  I wish all draft authors extra
time in their lives to do more rewarding stuff than chase down issues
that otherwise would've been easily caught.



 
>> >> > Section 7.2
>> >> >
>> >> > If we're going to say "and receives signed data in the response", maybe we
>> >> > could actually give an example that shows the (base64'd) CMS structure that
>> >> > corresponds to the signature?  Not necessarily the whole payload, but
>> >> > enough to see the outer structure at least...
>> >> 
>> >> See previous response regarding "base64encodedvalue==".  It's tricky
>> >> business.  That said, in a separate "expert review" response from Russ
>> >> Housley, we were thinking to add an appendix section containing all
>> >> the possible ASN.1 structures.  For instance:
>> >> 
>> >>   X. ASN.1 for Various Artifacts
>> >>   X.1. Zero Touch Information
>> >>   X.2. Signed Zero Touch Information
>> >>   X.3. Encrypted and Signed Zero Touch Information
>> >>   X.4. Owner Certificate
>> >>   X.5. Encrypted Owner Certificate
>> >>   X.6. Ownership Voucher
>> >>   X.7. Encrypted Ownership Voucher
>> >> 
>> >> Would this bridge the gap for you?
>> >
>> > That would help a lot, thanks!
>> 
>> Is it okay for me to back out of this one?  I had thought previously
>> that Russ would provide the ASN.1, but he said he didn't have time and,
>> well, I'd rather not venture into this if it can be avoided...
>
> It will be okay if nothing happens on this front.  (You've already put
> in a huge amount of effort anyway!)

Okay (item closed).




> Huge thanks for all your work on this -- hopefully the end is in sight!
>
> -Benjamin

You bet, it was my pleasure.  I hope to thank you in person sometime.


Cheers,
Kent