Re: [Ace] WGLC for draft-ietf-ace-coap-est
Klaus Hartke <hartke@projectcool.de> Tue, 05 March 2019 13:45 UTC
Return-Path: <hartke@projectcool.de>
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 1AE8F1312D0 for <ace@ietfa.amsl.com>; Tue, 5 Mar 2019 05:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 kDEjL3slsXZb for <ace@ietfa.amsl.com>; Tue, 5 Mar 2019 05:45:26 -0800 (PST)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29ACF131294 for <ace@ietf.org>; Tue, 5 Mar 2019 05:45:26 -0800 (PST)
Received: from mail-qt1-f169.google.com ([209.85.160.169]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1h1ANo-0007lG-7T; Tue, 05 Mar 2019 14:45:24 +0100
Received: by mail-qt1-f169.google.com with SMTP id z39so8959675qtz.0 for <ace@ietf.org>; Tue, 05 Mar 2019 05:45:24 -0800 (PST)
X-Gm-Message-State: APjAAAXBbRUFZS5mdjBH7LLVsIVoZn0anTYHWTlEPui7VzEp8mAS63As /bD/gFz/gy/X9m4D0gJSbXU+IREq/Ny3zGTsIH8=
X-Google-Smtp-Source: APXvYqy0fR+m+huWSQfNJUkqJnZK3JD+WVy8wn7+Wj4VPXwrVvIPuBYXl6yBvkPoeRSKYF0a4mO8negW2F0nuB1x8sc=
X-Received: by 2002:a0c:91e1:: with SMTP id r30mr2102307qvr.136.1551793523170; Tue, 05 Mar 2019 05:45:23 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <bffe2da1b435462d9acc2b03b969714e@XCH-ALN-010.cisco.com>
From: Klaus Hartke <hartke@projectcool.de>
Date: Tue, 05 Mar 2019 14:44:47 +0100
X-Gmail-Original-Message-ID: <CAAzbHvaKS9XDmqmQ789CCS2WikNfAcPC=9sm+-_b0byebdVUHg@mail.gmail.com>
Message-ID: <CAAzbHvaKS9XDmqmQ789CCS2WikNfAcPC=9sm+-_b0byebdVUHg@mail.gmail.com>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
Cc: "ace@ietf.org" <ace@ietf.org>, Jim Schaad <ietf@augustcellars.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1551793526; 19dad51e;
X-HE-SMSGID: 1h1ANo-0007lG-7T
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/3bfQupABeRPXFOOvGeU8XfJRiV0>
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 13:45:37 -0000
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
- [Ace] WGLC for draft-ietf-ace-coap-est Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Panos Kampanakis (pkampana)
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Klaus Hartke
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Panos Kampanakis (pkampana)
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Benjamin Kaduk
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Panos Kampanakis (pkampana)
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Klaus Hartke
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Panos Kampanakis (pkampana)
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Michael Richardson
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Klaus Hartke
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Panos Kampanakis (pkampana)
- Re: [Ace] WGLC for draft-ietf-ace-coap-est Jim Schaad