Re: [Ace] Review draft-ietf-ace-coap-est / Removal of CBOR-wrapped ASN.1 ?

Esko Dijk <esko.dijk@iotconsultancy.nl> Wed, 19 December 2018 12:32 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366E4130E05 for <ace@ietfa.amsl.com>; Wed, 19 Dec 2018 04:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com
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 6cbScsn5yDsd for <ace@ietfa.amsl.com>; Wed, 19 Dec 2018 04:32:49 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCF1130934 for <ace@ietf.org>; Wed, 19 Dec 2018 04:32:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector1-iotconsultancy-nl; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NNNINAV2tm5ymzowT+epYSK25W0IUwSlTBWj6p9PeY0=; b=GVqQqmhcyTqtlpHFRbmHeu68niTUt+R1HZBWvAGZChMyRKXQ4lxydY4c+axGbaCqWA0UF6oU5N3ZUPrKpDlUTl1l5GtsUnYZhfnxH2rnolp5V5ujDNPqzRNfUdQ82YOAodHcOX9i3wC0TqzVEd0g2hK4gj0x9vLxWt2W9vcpVT4=
Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0040.EURP190.PROD.OUTLOOK.COM (10.172.229.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.22; Wed, 19 Dec 2018 12:32:46 +0000
Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::f038:57aa:1670:ce58]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::f038:57aa:1670:ce58%4]) with mapi id 15.20.1446.018; Wed, 19 Dec 2018 12:32:45 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: "Panos Kampanakis (pkampana)" <pkampana=40cisco.com@dmarc.ietf.org>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>, 'ace' <ace@ietf.org>
CC: Jim Schaad <ietf@augustcellars.com>
Thread-Topic: [Ace] Review draft-ietf-ace-coap-est / Removal of CBOR-wrapped ASN.1 ?
Thread-Index: AdSXldpWfG6IR1JpTXSGzgfVoQarBw==
Date: Wed, 19 Dec 2018 12:32:45 +0000
Message-ID: <DB6P190MB005446725090C2572330C0DBFDBE0@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl;
x-originating-ip: [2001:1c02:3101:4800:7c25:50ad:1ce8:55a8]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6P190MB0040; 6:AWrRxsMBEktSSRcC6lkyxIfc1ZarWjJcuym3ehFMwQFU7wWXeJ4v9xgxZk/TVOCEFppw6WsVCLduw7gC3sZeEC231X3yBWvnvrGL/+2aoNSE9fEWeRIURSeFqK4EgT29PruyT8YSl2vBALcVoaM3/RN2YSvavoE3zsPVNU/rOroTL3DrD9IlfunHp4MEqw40BQB5y9p3dE5ECe27FNBZHCHfsSakmPqUvCPVhN2BKoGSIVBK+WCjRqP6c9fCAi6YA4vXbwEcPqDucVHBdSWAsCX+1nLPEnMGgcFjNkVXkTcDQ0Z006gSHBqOrOWhCqmVuFE3gkrTXqPodzy8t4DzpodGeenind+mUDiJnBsOlwCoMI4SZhfeCLnNFPo+ypauanq7x6pEj1NAlVLm1KuX/Gx0u0sDiJtiAk2ox67TwucGkt4/GjpYH/0QtzT75QydfCQ0ByohuqzofcB5SQfWBQ==; 5:LterDomB1bGMZ78Q4imKLdslWXNB3GXhlzkzReKLM1Os9C3Z/DZdgzoGqn1RvNIT+0ldj2jxG4sp/UrtGumIbEBzi7H/DWVCc7u07cPxPcU3H/HLF6wnF2p66c0qsaYwrHkF84PgRTO+UwfLEqFd2L4LmSPte/zVLc6rNKILm9o=; 7:u9SybrWB9c0z6fGXM6fKAWfv374gtKiuPKNZLMsXbhpfKbONd2CNI+eu2oaGz0wHmZP0YAc6I3NZAQzEeZco0yRJn0OBVwkDs9ynsp+trg3EUZQyPIlKIJMMAXFddu8P+uBN4eWGBPE7DO2cErdyEA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: aff325ec-f7d9-411b-037a-08d665ae145b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:DB6P190MB0040;
x-ms-traffictypediagnostic: DB6P190MB0040:
x-microsoft-antispam-prvs: <DB6P190MB00403A255D85CA5C12118C71FDBE0@DB6P190MB0040.EURP190.PROD.OUTLOOK.COM>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(999002)(5005020)(6040522)(2401047)(8121501046)(93006095)(93001095)(3231475)(944501520)(52105112)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123564045)(2016111802025)(20161123562045)(6043046)(201708071742011)(7699051)(76991095); SRVR:DB6P190MB0040; BCL:0; PCL:0; RULEID:; SRVR:DB6P190MB0040;
x-forefront-prvs: 0891BC3F3D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39830400003)(376002)(366004)(396003)(136003)(199004)(189003)(13464003)(51444003)(14454004)(33656002)(256004)(4326008)(74316002)(14444005)(2906002)(99286004)(44832011)(305945005)(966005)(110136005)(316002)(86362001)(7736002)(5660300001)(508600001)(486006)(7696005)(81166006)(71200400001)(6436002)(81156014)(476003)(68736007)(6116002)(8936002)(53546011)(6506007)(25786009)(53936002)(229853002)(186003)(6246003)(105586002)(2501003)(106356001)(102836004)(46003)(345774005)(8676002)(71190400001)(74482002)(55016002)(9686003)(97736004)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0040; H:DB6P190MB0054.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 3LUb61h+jd61WaOFwmgl1irL/D9RQrrGmde/PSOqfYrivLm+HXuUL1rMXnumFtwAhnj72LCcCsFqasg6SPL8hjaNsQ1vcmkgC2pLey7ciUDsk/KhuN0pGYBSKVteWEYpnYvG2NyrJjUPnyOST9Tg9AjB3b1MbJvATFpp6OSCsoMT0/Lw3Pkgi6kT244E7T6KaISpbhDeGU8p831uF+VUSmpPYmVMjHoc20wCxbeBOKSipgyuUNjL3Ke/HSD8rsvvKLBasvZhzPd4e6DJ3FnQhzRd3sbYyRviYyaG9fTYtmYbc7H3E4bEiZp4EQTGmBsN
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-Network-Message-Id: aff325ec-f7d9-411b-037a-08d665ae145b
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2018 12:32:45.8426 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0040
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/2W6ZrunAA5PZm0hGO2CRQluz1ck>
Subject: Re: [Ace] Review draft-ietf-ace-coap-est / Removal of CBOR-wrapped ASN.1 ?
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 12:32:52 -0000

Dear Panos & Peter,

On Jim's first point for section 4.1 below (content encoding) - will the CBOR-wrapped ASN.1 payload be changed to "pure" ASN.1 payload for the media types that are non-multipart?
I agree with Jim that the CBOR wrapping in this case is not needed (since the CoAP Content-Format / media type id will tell the receiver how it is encoded anyhow).  Also it seems harmful in this case, since an existing CoAP media type-plus-encoding is "overloaded" with a second encoding if we allow the CBOR-wrapping. Doing this would require registering a new value in the CoAP Content-Formats registry, e.g. like "application/csrattrs+cbor" and then it would be ok.

I'm asking this because in implementations we now use the CBOR-wrapping and if we don't make the change now it will stay that way most likely. And the present "EDnote" in the text is not so clear on what will happen.

Best regards
Esko Dijk

-----Original Message-----
From: Ace <ace-bounces@ietf.org> On Behalf Of Panos Kampanakis (pkampana)
Sent: Monday, September 17, 2018 18:56
To: Jim Schaad <ietf@augustcellars.com>om>; draft-ietf-ace-coap-est@ietf.org
Cc: 'ace' <ace@ietf.org>
Subject: Re: [Ace] Review draft-ietf-ace-coap-est

Hi Jim,
We have now addressed all the issues you brought up in July. The fixes will be in the last iteration. 
We will still make some cosmetic updates and post a new version.
Thank you for the thorough review. 
Rgs,
Panos

-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Sunday, July 01, 2018 9:34 AM
To: draft-ietf-ace-coap-est@ietf.org
Cc: 'ace' <ace@ietf.org>
Subject: [Ace] Review draft-ietf-ace-coap-est

* In section 4.1 I have a question about what you are using for payload content encoding.  Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future.  I think that it would necessitate doing new media-types in that event.  You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload.  I don't believe that there is any reason for doing this.  I would expect that the payload would be the ASN.1 w/o any ASN.1.  It is highly possible that I am just mis-reading what the text says and this is what you say.

* In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return.
It should only return those resources which have the rt field set on them.
I do not understand why you believe that the following lines MAY be returned.  Clarification of why you think this is true would be appreciated.

* Section 6 - Is there a need to have all of this description around TLS-unique?  Do you have a reason to believe that people are going get this implemented wrong?

* Section 7 - I think the figure has an error associated w/ it.  The CA should be tied to the EST Server and not to the Registrar

* Section 7 - Your language is a bit sloppy around the terms of POP and POP linking.  Unless it is really badly behaved, POP should never be broken by an RA.  The POP is the signature on the request and not tied to the TLS channel.  The POP linking is tied to the TLS channel and is broken by the changing of the TLS sessions (client <-> RA,  RA <-> CA) 

* Section 7 - It is not clear to me that the SHOULD on reassembly of fragmentation is not a MUST.  I doubt that any EST server is going to be able to deal with getting fragments of requests from a registrar in separate messages.  This would be compounded if the proxy is handling multiple sessions at the same time. 

* Section 7 - It should be possible that when doing key generation for the protection of the private key to be end-to-end and it should not be necessary for the Proxy to decrypt and then re-encrypt the private key.  It should not matter for this if one does either symmetric or asymmetric encryption of the private key.

* Section 7 - It is very possible that the private key generation function would be hosted on the proxy and not at the CA.  I think that you might want to describe this as a normal configuration.  (Just spotted this in the Security considerations.  I think it should be here as well.)

* Section 9.1 - application/multipart-core should not be in the table of items for IANA to register.  This is being done in a different document.  If you want this table as a whole then it needs to be moved out of IANA considerations.

* Section 9.2 - please expand this text some.  You might want to look at
https://tools.ietf.org/html/rfc7390#section-6.1 for a template.


Jim


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace