Re: [Ace] draft-ietf-ace-coap-est-00
Michael Richardson schreef op 2018-03-15 09:00: peter van der Stokwrote: >> >> DTLS connection is going to be required to act as an RA. RAs >> are required >> >> to have the entire request for adding authentication as necessary. >> >> > This is visible in the figure of section 6, but needs elaboration in >> the >> > text. >> >> I don't understand why we have that paragraph. >> An end point that terminates the Pledge (D)TLS connection and acts as >> an RA *IS* a Join Registrar, not a Proxy. >> > Thus is outside the BRSKI context, and thus a proxy with RA (separate or not) Let me delete "Join" from above sentence. A device that terminates the DTLS security (CoAPS) and then talks to the CA is a Registration Authority according to EST and RFC5280. It's not a proxy. (And it doesn't matter if it speaks HTTPS or CMS or CMP or super-pigeon-telepathy to the CA) A http/coap proxy is specified in RFC8075. It explains "how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response". In the est-coap draft DTLS and TLS connections are terminated in the http/coap proxy, and the proxy is therefore connected to an RA (possibly running on the same host as the proxy). Where is my terminology going astray? Peter ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
Benjamin Kadukwrote: >> Jim Schaad wrote: >> > In section 2 - There will be a problem in that the port format extension is >> > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 1.3 >> > section for clarity. >> >> I don't understand what you are referring to. >> >> What is the "port format extension" you are referring to, and where in >> section 2 do you think we are depending upon it? > [...] DTLS > implementations MUST use the Supported Elliptic Curves and Supported > Point Formats Extensions [RFC4492]; the uncompressed point format > MUST be supported; [RFC6090] can be used as an implementation method. Ah, so s/port/point/ > The uncompressed point format only exists in (D)TLS 1.2 and lower. > (TLS 1.3 does not separately negotiate point format, rather, the > point format is determined by the group/curve to be used.) I think we were just being overly specific, I'm not sure why. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
peter van der Stokwrote: >> >> DTLS connection is going to be required to act as an RA. RAs >> are required >> >> to have the entire request for adding authentication as necessary. >> >> > This is visible in the figure of section 6, but needs elaboration in >> the >> > text. >> >> I don't understand why we have that paragraph. >> An end point that terminates the Pledge (D)TLS connection and acts as >> an RA *IS* a Join Registrar, not a Proxy. >> > Thus is outside the BRSKI context, and thus a proxy with RA (separate or not) Let me delete "Join" from above sentence. A device that terminates the DTLS security (CoAPS) and then talks to the CA is a Registration Authority according to EST and RFC5280. It's not a proxy. (And it doesn't matter if it speaks HTTPS or CMS or CMP or super-pigeon-telepathy to the CA) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
>> * Should probably add a note in section 6 that any proxy that terminates >> the >> DTLS connection is going to be required to act as an RA. RAs are required >> to have the entire request for adding authentication as necessary. > This is visible in the figure of section 6, but needs elaboration in the > text. I don't understand why we have that paragraph. An end point that terminates the Pledge (D)TLS connection and acts as an RA *IS* a Join Registrar, not a Proxy. Thus is outside the BRSKI context, and thus a proxy with RA (separate or not) ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
On Tue, Mar 13, 2018 at 09:44:37PM -0400, Michael Richardson wrote: > > Jim Schaadwrote: > > In section 2 - There will be a problem in that the port format > extension is > > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and > 1.3 > > section for clarity. > > I don't understand what you are referring to. > > What is the "port format extension" you are referring to, and where in > section 2 do you think we are depending upon it? [...] DTLS implementations MUST use the Supported Elliptic Curves and Supported Point Formats Extensions [RFC4492]; the uncompressed point format MUST be supported; [RFC6090] can be used as an implementation method. The uncompressed point format only exists in (D)TLS 1.2 and lower. (TLS 1.3 does not separately negotiate point format, rather, the point format is determined by the group/curve to be used.) I think the fix would just be something like "the uncompressed point format MUST be supported for DTLS versions prior to 1.3". -Ben signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
Jim Schaadwrote: > In section 2 - There will be a problem in that the port format extension is > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 1.3 > section for clarity. I don't understand what you are referring to. What is the "port format extension" you are referring to, and where in section 2 do you think we are depending upon it? I'm thinking that you are jumping to a conclusion based upon some poorly written text on our part :-) But, since I think all the authors are ignorant of that extension, we must be misleading you unintentionally. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
peter van der Stokwrote: >> * In section 6- All proxies are required by CoAP blocking to re-assemble >> the entire message at the proxy. It can re-block things going to the next >> proxy. While there is no requirement that the proxy get the entire message >> before sending on pieces, this should be common practice and would be >> required for a CoAP/HTTP proxy. > Agree fully, we need to clarify that. If we are talking about CoAP->HTTP proxy, then clearly that's absolutely true. How could it be any other way? We can't do CoAP block mode over HTTP that I know of :-) There are other proxy types that we need to describe. >> * Should probably add a note in section 6 that any proxy that terminates >> the >> DTLS connection is going to be required to act as an RA. RAs are required >> to have the entire request for adding authentication as necessary. > This is visible in the figure of section 6, but needs elaboration in the > text. I don't understand why we have that paragraph. An end point that terminates the Pledge (D)TLS connection and acts as an RA *IS* a Join Registrar, not a Proxy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
On Mon, Mar 12, 2018 at 09:08:05AM +0100, peter van der Stok wrote: > Hi Jim, > > thanks for the comments. See my reactions below. > Jim Schaad schreef op 2018-03-10 22:15: > > I agree with Hannes, this version of the document is much cleaner and > > much > > clearer. I think that it has solved most of the problems that I > > initially > > had with the draft. It is not ready to progress as there are still > > sections > > that are marked as TODO. But it is much closer to finishing that it > > was. > > That sounds hopeful. Agree about the TODOs > > > > I still have a couple of comments from a quick read through of the > > document. > > > > In section 2 - There will be a problem in that the port format > > extension is > > being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and > > 1.3 > > section for clarity. > > You mean for backward compatibility? For forwards compatibility, mostly, so we don't claim to require something that does not exist in TLS 1.3. -Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-coap-est-00
Hi Jim, thanks for the comments. See my reactions below. Jim Schaad schreef op 2018-03-10 22:15: I agree with Hannes, this version of the document is much cleaner and much clearer. I think that it has solved most of the problems that I initially had with the draft. It is not ready to progress as there are still sections that are marked as TODO. But it is much closer to finishing that it was. That sounds hopeful. Agree about the TODOs I still have a couple of comments from a quick read through of the document. In section 2 - There will be a problem in that the port format extension is being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 1.3 section for clarity. You mean for backward compatibility? In section 3- Should we be looking at the use of COSE rather than CMS for encryption of key services? That is a question that needs some discussion by others. In the recent draft-richardson-anima-ace-constrained-voucher-03, we encrypt the CBOR serialized voucher with either CMS or COSE, as signaled in the content format. Also there is a new draft draft-selander-ace-coap-est-oscore-00 that discusses the use of OSCORE for est over coap Introduction of COSE in est-coaps draft may need alignment with the other drafts. You suggest to use COSE for server key generation only to better protect the keys, and all other services to be encrypted with CMS? * Do you have the option to additionally support the long name for the service as well as the short name? MUST have short name MAY have long name? Agree, should work that out in more detail. * In section 6- All proxies are required by CoAP blocking to re-assemble the entire message at the proxy. It can re-block things going to the next proxy. While there is no requirement that the proxy get the entire message before sending on pieces, this should be common practice and would be required for a CoAP/HTTP proxy. Agree fully, we need to clarify that. * Should probably add a note in section 6 that any proxy that terminates the DTLS connection is going to be required to act as an RA. RAs are required to have the entire request for adding authentication as necessary. This is visible in the figure of section 6, but needs elaboration in the text. Jim Many thanks, this helps to get our text more concrete and complete. Peter ___ 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