Re: [Ace] WGLC for draft-ietf-ace-coap-est

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Tue, 05 March 2019 16:34 UTC

Return-Path: <pkampana@cisco.com>
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 B95F31312BC for <ace@ietfa.amsl.com>; Tue, 5 Mar 2019 08:34:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 G2c_ec3HiXu7 for <ace@ietfa.amsl.com>; Tue, 5 Mar 2019 08:34:10 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435441312AC for <ace@ietf.org>; Tue, 5 Mar 2019 08:34:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7956; q=dns/txt; s=iport; t=1551803650; x=1553013250; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uxl+kohtkYUnGQP2QTPsRp3R2ysiKfzNCBVpaz3KTuA=; b=G47yvJkv/72cxWRqRoimcjhArn+SUT76lGLgwQ3tmTcybZeHYRPj6ncL X1PZQMIwcJw3HIbpaSi/9DIGeuYDF766JTDR5d42dKpS6wEIzW/2zJZo8 KHcd/6e3FQuIZx1bGNklgvHD8u+dbjoMNOVHy/aKa3+UczfIn4OFV7Anu E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADao35c/49dJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgg9ogQMnCoN+iBqNV5ghFIFnCwEBJYR?= =?us-ascii?q?HAheEFSI0CQ0BAQMBAQMBAwJtHAyFSgEBAQMBIxFFBQcEAgEIEQQBAQECAiY?= =?us-ascii?q?CAgIwFQgIAgQOBQiDG4FtCA+qToEviioFgQskAYsnF4FAP4ERgxKDHgEBAgG?= =?us-ascii?q?BRgKDIIJXAoxDhCOTIQkCh0GLKSGTJ5BBjEoCERSBKB84gVZwFTuCbIIWF4N?= =?us-ascii?q?LhRSFP0ExAQGPdIEfAQE?=
X-IronPort-AV: E=Sophos;i="5.58,444,1544486400"; d="scan'208";a="519085021"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 16:34:08 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x25GY8Jt014887 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Mar 2019 16:34:08 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Mar 2019 10:34:07 -0600
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1473.003; Tue, 5 Mar 2019 10:34:07 -0600
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Klaus Hartke <hartke@projectcool.de>
CC: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] WGLC for draft-ietf-ace-coap-est
Thread-Index: AdSrvXSIvNnigqRdTGScym0guMdeAQXbpEIAACaWOEACybnHgAAqNAEAAP1zdoAAC9jPkA==
Date: Tue, 5 Mar 2019 16:34:07 +0000
Message-ID: <b16aac8eafe4452aa20a7aa4ef6895ea@XCH-ALN-010.cisco.com>
References: <003701d4abbe$0cfab580$26f02080$@augustcellars.com> <CAAzbHvYwEY8TGgNbVPpwo03gQ-j6M4xkVLTZJaSYiLYhZhKMaQ@mail.gmail.com> <9c257f8ffa27435fbe8a24a8c7c25c31@XCH-ALN-010.cisco.com> <CAAzbHvZHfgRTpNWNjg98HXokXCeLECLA13O-RG49woZ1u8QPiQ@mail.gmail.com> <bffe2da1b435462d9acc2b03b969714e@XCH-ALN-010.cisco.com> <CAAzbHvaKS9XDmqmQ789CCS2WikNfAcPC=9sm+-_b0byebdVUHg@mail.gmail.com>
In-Reply-To: <CAAzbHvaKS9XDmqmQ789CCS2WikNfAcPC=9sm+-_b0byebdVUHg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.35.123]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/K7urUOKSdaK6W-QFV4tz-HOU32A>
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est
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: Tue, 05 Mar 2019 16:34:19 -0000

Thanks Klaus. 

OK about waiting for confirmation on ports returned in discovery and RFC6690.

> wouldn't it also be possible to configure the client with the whole URI containing the three parts directly?

Yes, that is perfectly possible. I don't think the draft is forbidding the whole URL being configured instead of a host:port:ArbitraryLabel tuple. 

> I really don't see why the EST-coaps specification needs to provide examples for basic CoAP features that don't play a crucial role in the application.

Understood what you meant. I removed the normative "MUST" and replaced the language to more explicitly state the "RECOMMENDED" for implementers. 

> Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value of an option is intended to be this default value, the option SHOULD NOT be included in the message." [1] So your example actually violates this 'SHOULD NOT'...

For consistency we now use FQDNs in all our /crt examples, so I think the A.1 is more justified. 

If you want to check the updated draft use https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt 

Rgs,
Panos


-----Original Message-----
From: Klaus Hartke <hartke@projectcool.de> 
Sent: Tuesday, March 05, 2019 8:45 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>
Cc: ace@ietf.org; Jim Schaad <ietf@augustcellars.com>
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

Panos Kampanakis wrote:
> > But can't the client just be configured out-of-band with the URIs directly?
>
> That is right. We could mandate only .well-known URIs. But I think we 
> ought to let a deployment use non-default URIs. [...]

I was aiming at something different, but, re-reading my question, my question wasn't very clear. Let me try again.

In draft-ietf-ace-coap-est-09, a client can do discovery. For that, it needs to know the host name (or IP address) and port number of a CoAP server. It then constructs the URI <coaps://{host}:{port}/.well-known/core> and then gets a list of links to the EST resources. The host name and port number must come from somewhere -- e.g., from configuration or from some other discovery process. I'm quite happy with this.

Then you were saying that, in some cases, this discovery step is unnecessary/wasteful. A client would instead need to know the host name (or IP address) and port number of a CoAP server as well as an ArbitraryLabel. It would then construct the URI <coaps://{host}:{port}/.well-known/est/{ArbitraryLabel}/sen> and could immediately start interacting with that resource. Again, the host name, port number and ArbitraryLabel must come from somewhere. You were saying that they come from configuration.

My question is: If host name, port number and ArbitraryLabel can come from configuration, from which the client constructs <coaps://{host}:{port}/.well-known/est/{ArbitraryLabel}/sen>, wouldn't it also be possible to configure the client with the whole URI containing the three parts directly?

> > 5.1 "Discoverable port numbers can be returned in the response payload." -- Now I'm wondering if that's actually permitted by RFC 6690...
>
> [...] but I think the example is OK to include the port.

I'm not sure. RFC 6690 is really weird. Let me get back to you on this.

> > 5.4 "All EST-coaps request messages expect an acknowledgement (with a response payload); EST-coaps requests are confirmable CON CoAP messages." -- This seems to be a matter of implementation quality and should not be a requirement for interoperability. I suggest to remove this.
>
> We want to make use of Delayed responses. There are cases where the CA takes time to generate the cert/keypair, and in that case it needs to signal the delay with a Max-Age or Empty ACK. That is why we use CON. The text justification does not explain explicitly, but we didn't want to clutter the wording, so we kept it simple.

You're mixing up protocol specification and implementation guidance.
On the protocol specification side, both clients and servers are free to choose if they want to use confirmable or non-confirmable messages.
And an application should not make any restrictions on that. On the implementation guidance side, I think it makes a lot of sense to choose delayed responses here. But implementation guidance should be clearly marked as such, as not to create the impression that implementations can only use certain messages types or can rely on only certain messages types being used.

> > A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they aren't in this example. Since it's not important for the example, maybe just remove Uri-Host and Uri-Port from the example and also this paragraph?
>
> I wanted to keep it in there. We explain that it can be assumed from DTLS if omitted, but I think it is worth to show how the option would be included. I had trouble finding a COAP Uri-Host and port example online when I was searching and thus this is useful as a reference as well.

Yes, having more examples for reference is really nice. And I really like that you, the authors, spent quite obviously a lot of time making sure that EST-coaps is actually implementable and figuring out the best ways to implement it. But, as I said above, you're mixing up protocol specification and implementation guidance too much for my taste. I really don't see why the EST-coaps specification needs to provide examples for basic CoAP features that don't play a crucial role in the application.

Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the value of an option is intended to be this default value, the option SHOULD NOT be included in the message." [1] So your example actually violates this 'SHOULD NOT'...

Klaus

[1] https://tools.ietf.org/html/rfc7252#section-5.4.4