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

Kent Watsen <kwatsen@juniper.net> Wed, 16 January 2019 01:10 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 CECD112D4EA; Tue, 15 Jan 2019 17:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.253
X-Spam-Level:
X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZJvC2EysVTLe; Tue, 15 Jan 2019 17:10:29 -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 D80CD130F80; Tue, 15 Jan 2019 17:10:29 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0G16oSf020179; Tue, 15 Jan 2019 17:10:29 -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=wE6Fboc0dF620CnUTxvkG/m92lquXOpI7CAttntyqTA=; b=1Cxjb3vLFRCLX9qZFEEggPrGk6esraT1rHjyqqPNXXpLVcssE125K6UPSv8GgLx4ZjmX D/15o0AqBQPbpXBpvbFruwPvek21HKOmGjQ6dwiqNlmoZ2twq+zU+xBr4lMzKoWzE03A fxF0JJEWasOU+BAOqhBLMiJcRtqfNTmg3hdLWScAhVnKoKL1KGwruqsYptySf/pivlYu 1mT4vMfsCZLorS13B7vA63+6yUqyP5W00pThBEsw1LJDGcxG0qHE3qT0aHyhnhw9r6Q6 eNhl+PPQu+usv4mNI+xqOV4n6VGVbM/QIb8Z/PYUkyiVVmdL4qiL4iTm+CdL2yn7gk+2 9w==
Received: from nam05-by2-obe.outbound.protection.outlook.com (mail-by2nam05lp2059.outbound.protection.outlook.com [104.47.50.59]) by mx0a-00273201.pphosted.com with ESMTP id 2q1m0k8k03-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Jan 2019 17:10:29 -0800
Received: from BYAPR05MB5416.namprd05.prod.outlook.com (20.177.184.221) by BYAPR05MB4504.namprd05.prod.outlook.com (52.135.203.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.16; Wed, 16 Jan 2019 01:10:20 +0000
Received: from BYAPR05MB5416.namprd05.prod.outlook.com ([fe80::ccee:5d54:3370:e50b]) by BYAPR05MB5416.namprd05.prod.outlook.com ([fe80::ccee:5d54:3370:e50b%5]) with mapi id 15.20.1537.018; Wed, 16 Jan 2019 01:10:20 +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>
Thread-Topic: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
Thread-Index: AQHUi5qky69pAtgeuk6GIUpsNSYi7qVz1VIAgCLBFICAB70FgIADj4qAgAJJm4CAAxXrAIAAYVAA//+xH4CAAacWAIAAD4+AgAADiwD//8aMAIAActaAgAFSQoCAAHCvAIAEHSWAgABsiwCAAUd1gIAAYRYA///Hz4A=
Date: Wed, 16 Jan 2019 01:10:20 +0000
Message-ID: <0D451A2F-0F05-4474-94B0-ED3FAA1135BE@juniper.net>
References: <42cddba1-9f59-f19f-176f-197f0c0c0c96@bbiw.net> <32cfe06c-8204-a63a-263d-cb5b30a7a2fc@nostrum.com> <20190110183444.GN28515@kduck.mit.edu> <0CDD631D-47A4-4478-A250-85603C653D23@juniper.net> <f9e64452-a2e1-fb18-80b1-b2c5fa9c54ac@nostrum.com> <3ABB2B04-DB2C-4E2C-86C7-40D83D440DFB@juniper.net> <20190112005406.GU28515@kduck.mit.edu> <A1F059FB-5229-45B9-9EBB-CF60B78FF454@juniper.net> <20190114221155.GL28515@kduck.mit.edu> <F68D5933-715C-4475-92B2-22DD06B5CA20@juniper.net> <20190115233125.GB91727@kduck.mit.edu>
In-Reply-To: <20190115233125.GB91727@kduck.mit.edu>
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; BYAPR05MB4504; 6:fHDXuJgPwpUUe5+T4daiXpFI+6p/7PxE3eXPawAzqKdOBB4VXP9EkCCHACT1n9eI3/ddhZM7X2+DYK1H0vMiWEUfRN2fjhE2XeoMEme+iTNUdlo1J8gToVNtLLjycBCn4PjZv4JzicsoLz8zu354wiyOGA6J13c+K1NXJGcIIQKc8XkJX7uqo2ceWwk2lSQ9jKrN1CpBn7bgQXZCo6ApSdlVKk/vDQ7EarSV6vGkcyzlwUQ+cFSeBwbi2y+XNj8Ukd3o3zlMY1HwMcLE8mShZ4oJJi0XM+9avM4fA24RKyfJ5lmzRtPsN12SvYWpkxWtrf6iu+SqwpIW3DL/YBsTrPVlCvwb7fusaWQIfwjFaRPz6JvQmSq7lOXYkfQfmqL575H7LuQtYnKCdofkDPPq1tKxaMur8NStv4OeSwIg3bNRGxEnCWksykse107N1Sl6/R7/cmVrNvYifjg/xfgHIg==; 5:eyQEmIlOiJXXGUNnfS+IU8PpeEmzWQdJAo1SbewRB+BUiQb52tjWTpg7kkYYT9RMJ8qqt7Ea8hAPgh8t8CJOiTRNS55P1pVciI6ygYPlxzjp4IIUVbcoCPUfRJ9jAWY9WB8fAR1esFbV06/jAI5Rw+qC6/FhMsQamo8IrPxIA9EmeggK096i0am9O4BNvs+Tq1vEm1WMlRZCsV0HSE5YcQ==; 7:o4rSs0y8dcqaJ0f+teBXsMx7P6QCMck9hsg8yvA6akVQNx/qwM4IODAufbxM+uSXS68Gu1lPPp3Y3t8gEqs6ugB3cmsDL0XlqRUEiHOOziYJLW5O+eYHIpYB6QWFnJZYl+yqj8+wRkgHSA2yP0itnQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: dc31ca7f-f309-4225-88ad-08d67b4f62a8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4504;
x-ms-traffictypediagnostic: BYAPR05MB4504:
x-microsoft-antispam-prvs: <BYAPR05MB45046668D8F2C2179ABDB047A5820@BYAPR05MB4504.namprd05.prod.outlook.com>
x-forefront-prvs: 091949432C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(136003)(376002)(396003)(366004)(13464003)(189003)(199004)(40224003)(476003)(486006)(86362001)(11346002)(446003)(105586002)(6436002)(97736004)(99286004)(53936002)(83716004)(71190400001)(71200400001)(6916009)(36756003)(6512007)(2171002)(66066001)(6116002)(3846002)(7736002)(6246003)(305945005)(2906002)(33656002)(8936002)(256004)(14444005)(54906003)(478600001)(14454004)(5660300001)(58126008)(25786009)(2616005)(81166006)(81156014)(229853002)(6486002)(106356001)(316002)(8676002)(76176011)(6506007)(53546011)(4326008)(102836004)(68736007)(82746002)(93886005)(6346003)(26005)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4504; H:BYAPR05MB5416.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: hBwHjhTZGO4zuKVTQueta5CZXZxs+N/9FnSz1Rqp2Lzt8Jnh4Y6+v2ESUq/YghzdQ5YHviY8wkinrkpxOsHk4v1QH6OzXiqUm5w/TfJVL0+HhVQSEFtOFgoWfxfYaHUP+K7SiWUPXwVk8AfWptk0ysNU1ehhoaD4xmcpitVlumrapwNFld/CrPPFSXfcVYIkGe106tbLonviC9970ha86C1kJWWg55kjTdjbhPIO+0vl2uMfQz3MfZ3T9/mvbZUbzLlhLiVCRMq+8W5z/oZAJVNaH0t3uDg80NdwcNRucuM66FQiPJbLwS0B8JTaEQkqqxGwOqbW7us3CJ8ZatihQL9+xI4o2HhwKn8nRALdJRE8fUB0Qbuocu/yKn4RcPbaoStrr5065u+VlTDtMw7v9ykIsUwTJ+3YhwVup2semCk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <3B07351255ADA349A7936357FBDD6EBE@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: dc31ca7f-f309-4225-88ad-08d67b4f62a8
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2019 01:10:20.6007 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4504
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-15_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=1015 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-1901160006
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/6ukgbRKNbjTZRKwbygoEFgSoNjQ>
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: Wed, 16 Jan 2019 01:10:32 -0000

Okay, I just posted the update with the 802.1AR URL fixed.

And, as they say in BB&Fs, that's all folks!   :)

Kent


-----Original Message-----
From: Benjamin Kaduk <kaduk@mit.edu>;
Date: Tuesday, January 15, 2019 at 6:31 PM
To: Kent Watsen <kwatsen@juniper.net>;
Cc: Adam Roach <adam@nostrum.com>;, Dave Crocker <dcrocker@bbiw.net>;, Alexey Melnikov <aamelnikov@fastmail.fm>;, 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 Working Group <netconf@ietf.org>;
Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

On Tue, Jan 15, 2019 at 10:43:59PM +0000, Kent Watsen wrote:
> Hi Benjamin,
> 
> 
> >> Yes, that is the correct URL.  I've fixed it in my local copy.  
> >> The 802.1AR spec is behind a paywall, but it says this about the serial number:
> >> 
> >>   An IDevID certificate subject field be non-null and should
> >>   include a   unique device serial number encoded as the 
> >>   serialNumber attribute(RFC 5280 X520SerialNumber).
> >> 
> >> From RFC 5280:
> >> 
> >>    X520SerialNumber ::=    PrintableString (SIZE (1..ub-serial-number))
> >> 
> >>    ub-serial-number INTEGER ::= 64
> >> 
> >>    The character string type PrintableString supports a very basic Latin
> >>    character set: the lowercase letters 'a' through 'z', uppercase
> >>    letters 'A' through 'Z', the digits '0' through '9', eleven special
> >>    characters ' = ( ) + , - . / : ? and space.
> >> 
> >> Any comments/concerns about this?
> >
> > Sigh.  There could be some excitement here (but might not be), but I think
> > I'm going to have to defer to some people with more DNS (and X.500)
> > expertise.  There's several potential (but not certain) issues here,
> > including at least:
> >
> > (1) ub-serial-number is 64, and the maximum length of a DNS label is 64
> > octets, so we have no room for escaping or encoding at the margins.
> >
> > (2) RFC 1034 suggests that DNS domain name comparisons should be performed
> > in a case-insensitive manner (for alphabetic ASCII a-z/A-Z), but that
> > labels themselves can contain arbitrary octets.  There is some placation
> > here in that X.520 appears to define the Serial Number attribute should use
> > a caseIgnoreMatch equality matching rule, so maybe this is a non-issue.
> >
> > (3) Those extra characters (other than '-') are not allowed in DNS host
> > names.  AIUI, that technically shouldn't be a problem for this usage, but
> > I'm not 100% confident, and maybe some implementations are wrong.
> >
> > (4) Using '.' in a label is pretty rare and require escaping for textual
> > presentation (but this is not inherently a fatal flaw and would not hit the
> > 64-character limit on label length).
> >
> > But on the whole, the question I want to ask myself here is along the lines
> > of "how likely is there to be implementation incompatibility in this
> > space?".  If serial numbers in practice are not using the full flexibility,
> > this could still be a non-issue.
> 
> Be aware that the draft must, in general, say something about the serial
> number for each source of bootstrapping information (and note that the
> draft leaves open the possibility that more "sources" may be defined in
> the future):
> 
>   Removable Storage:
>     - okay, well, the draft punts on providing an actual file-naming
>       convention but, in theory, there could be a directory per 
>       serial-number.  E.g., /<serial-number>/<artifact-file>.
> 
>   DNS:
>     - TXT in <serial-number>._sztp.local.   (multicast)
>     - TXT in <serial-number>._sztp.<domain>.  (unicast)
> 
>   DHCP:
>     - the draft punts here as well. DHCP is the only source of
>       bootstrapping information defined by the document that
>       doesn't support device-specific response (bootp payloads
>       are *way* too small!)
> 
>   SZTP Bootstrap Server:
>     - device MUST identify/authenticate itself using its serial-number.
>     - device SHOULD use a client-certificate (DevID RECOMMENDED)
>     - device MAY use an HTTP authentication scheme but, if it does so,
>       it MUST identify itself using its serial-number.
> 
> Lastly, for any source, if "signed data" is returned, the ownership
> voucher [RFC 8366] defines a "serial-number" leaf that MUST be
> populated with the serial number value.
> 
> In general, it is felt that, if a device vendor's serial-numbers
> contain characters that are not supported by some protocol or format,
> then that is their problem to solve.  That said, most protocol/formats
> will define some escaping mechanism and, if not, the vendor can create
> some mapping.
> 
> As for serial-number lengths exceeding some limit, then it may mean
> that the device vendor either can't use that bootstrapping strategy,
> or, again, they come up with a mapping of some sort (e.g., a hash).
> But I doubt serial numbers ever get so long, as they are many times
> typed or spoken, and users would revolt if they were too long ;)
> 
> My hope is that we can ignore this concern altogether, or maybe just
> have a Security Considerations section that essentially captures the
> above.  Thoughts?

I'm inclined to believe that we can just ignore this concern for now, based
on the above discussion and having thought about the issues a bit more.

(I also see that Ignas has already pushed the "approve" button, so the
publication process is underway.)

Thanks again for all your work getting this one over the finish line.

-Benjamin