Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
Thanks Jim > You say that the client should use the new explicit trust anchors right after > the cacerts request, but if you do not tear down the DTLS connection you are > not doing that. You are still using the old implicit trust anchors. The MAY > in section 11.1 for me is overridden by the previous SHOULD unless this case > is specifically called out in section 7. I cannot understand the logic that > says when you get a certificate a year from now the explicit TAs SHOULD be > used, but it does not matter when you get the first certificate. In the draft we want to say that when you get the cacerts response start using those as your explicit trust anchor. But we also want to say that if you pipeline EST-coaps messages in the same connection then you MAY keep the DTLS connection open. That has implications on the trust anchor if one of the EST-coaps requests included a cacerts request. I am thinking that in order to make it clearer we can add text to say that "After a cacerts you are expected to use the new trust anchor. If pipelining is used you MAY keep the connection open, but the client SHOULD still authenticate the server identity received during the DTLS handshake against the new trust anchor receive in response to a cacerts in the same connection. " What do you think? I open to other text suggestion to convey the point as well. About the Examples we will address the Max-Age and Content Format in the examples. I created new github issues for those. Panos -Original Message- From: Jim Schaad Sent: Monday, January 28, 2019 4:37 PM To: Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 Clipping out things which are not issues: > -Original Message- > From: Ace On Behalf Of Panos Kampanakis > (pkampana) > Sent: Friday, January 18, 2019 12:59 PM > To: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > Hi Jim, > > Again, thank you for your thorough reviews. We addressed all of them. > The new version of the draft is at > https://github.com/SanKumar2015/EST- > coaps/blob/master/draft-ietf-ace-coap-est.txt > > For a more easily consumable content, your latest feedback was tracked > and addressed here https://github.com/SanKumar2015/EST- > coaps/issues?utf8=%E2%9C%93=is%3Aissue+draft-ietf-ace-coap-est-07 > > I also lay out the changes below: > > > - About the persistent DTLS connections (Sect 7), the last two > paragraphs of > section 7 explain why in some cases DTLS connections need to stay open > for a limited amount of time. They also point to the Section 11.1 > about the caveats of a persistent connection and the implicit DB. I do > not think it is up to > this draft to tell the client that he should use the new cert after an > enrollment. The old cert might still be perfectly valid or the new > cert may be > generated for a non DTLS client auth use. So, I don't think we need to state in > this draft that the new cert needs to be used in new DTLS connections. > > - About the DTLS connections (Sec 11.1), We have usecases where a > client does not want to spend the resources, time, performance > implications to do > 3-5 DTLS connections back to back in order to update its trustanchor > and do > its enrollments for multiple certs. In this cases, explained in > section 7 last > paragraphs will keep a persistent DTLS connection. That is what > section 11.1 is > trying to explain. Please keep in mind that in there we state that it > is RECOMMENDED for the client to start using the new explicit DB right > after the cacerts request. We just add the MAY keep the authenticated > with implicit DB DTLS connection open in some cases, but then he MUST > use the new DB starting for the next DTLS connection. > > So, I think our language in Sections 7 and 11.1 suffices when talking about > persistent TLS connections. Any time that the set of trust anchors is changed, you have also changed the set of things that you are going to trust. If you remove the trust anchor for the current connection, or restrict it in some manner, you may no longer have any trust in that connection. This is the worry that I have. I completely agree that doing multiple certificate requests (not sure why) or a query about the csr attributes followed by the certificate request is totally reasonable. You say that the client should use the new explicit trust anchors right after the cacerts request, but if you do not tear down the DTLS connection you are not doing that. You are still using the old implicit trust anchors. The MAY in section 11.1 for me is overridden by the previous SHOULD unless this case is specifically called out in section 7. I canno
Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> -Original Message- > From: Ace On Behalf Of Jim Schaad > Sent: Monday, January 28, 2019 1:37 PM > To: 'Panos Kampanakis (pkampana)' ; ace@ietf.org > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > Clipping out things which are not issues: > > > > -Original Message- > > From: Ace On Behalf Of Panos Kampanakis > > (pkampana) > > Sent: Friday, January 18, 2019 12:59 PM > > To: Jim Schaad ; ace@ietf.org > > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > > > Hi Jim, > > > > Again, thank you for your thorough reviews. We addressed all of them. > > The new version of the draft is at > > https://github.com/SanKumar2015/EST- > > coaps/blob/master/draft-ietf-ace-coap-est.txt > > > > For a more easily consumable content, your latest feedback was tracked > > and addressed here https://github.com/SanKumar2015/EST- > > coaps/issues?utf8=%E2%9C%93=is%3Aissue+draft-ietf-ace-coap-est-07 > > > > I also lay out the changes below: > > > > > > - About the persistent DTLS connections (Sect 7), the last two > > paragraphs > of > > section 7 explain why in some cases DTLS connections need to stay open > > for a limited amount of time. They also point to the Section 11.1 > > about the caveats of a persistent connection and the implicit DB. I do > > not think it > is up to > > this draft to tell the client that he should use the new cert after an > > enrollment. The old cert might still be perfectly valid or the new > > cert > may be > > generated for a non DTLS client auth use. So, I don't think we need to > state in > > this draft that the new cert needs to be used in new DTLS connections. > > > > - About the DTLS connections (Sec 11.1), We have usecases where a > > client does not want to spend the resources, time, performance > > implications to do > > 3-5 DTLS connections back to back in order to update its trustanchor > > and > do > > its enrollments for multiple certs. In this cases, explained in > > section 7 > last > > paragraphs will keep a persistent DTLS connection. That is what > > section > 11.1 is > > trying to explain. Please keep in mind that in there we state that it > > is RECOMMENDED for the client to start using the new explicit DB right > > after the cacerts request. We just add the MAY keep the authenticated > > with implicit DB DTLS connection open in some cases, but then he MUST > > use the new DB starting for the next DTLS connection. > > > > So, I think our language in Sections 7 and 11.1 suffices when talking > about > > persistent TLS connections. > > Any time that the set of trust anchors is changed, you have also changed the > set of things that you are going to trust. If you remove the trust anchor for > the current connection, or restrict it in some manner, you may no longer > have any trust in that connection. This is the worry that I have. I completely > agree that doing multiple certificate requests (not sure why) or a query > about the csr attributes followed by the certificate request is totally > reasonable. > > You say that the client should use the new explicit trust anchors right after > the cacerts request, but if you do not tear down the DTLS connection you are > not doing that. You are still using the old implicit trust anchors. > The MAY in section 11.1 for me is overridden by the previous SHOULD unless > this case is specifically called out in section 7. I cannot understand the logic > that says when you get a certificate a year from now the explicit TAs SHOULD > be used, but it does not matter when you get the first certificate. > > * It does not look from the version on github that you made any changes for > the examples: > > Examples: > > * Section A.1 I don't know what the meaning of Max-Age would be for a GET > request. You may want to remove this just to avoid confusion. > > * Section A.2 - I am unclear about the Content-Format note in this example. > If you are asking for a specific content then the correct option would be > Accept. If you are indicating the content type of the response then you > should probably put a header line in to that effect. > > In the virtual CoAP WG meeting last week we went through in some explicit > detail that both Content-Format and Max-Age have no meaning when > appearing on a request and therefore should not be there. I may be wrong about content-format, but if there is only one choice I am not sure that it is needed. > > ___ > 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
Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
Clipping out things which are not issues: > -Original Message- > From: Ace On Behalf Of Panos Kampanakis > (pkampana) > Sent: Friday, January 18, 2019 12:59 PM > To: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > Hi Jim, > > Again, thank you for your thorough reviews. We addressed all of them. The > new version of the draft is at https://github.com/SanKumar2015/EST- > coaps/blob/master/draft-ietf-ace-coap-est.txt > > For a more easily consumable content, your latest feedback was tracked and > addressed here https://github.com/SanKumar2015/EST- > coaps/issues?utf8=%E2%9C%93=is%3Aissue+draft-ietf-ace-coap-est-07 > > I also lay out the changes below: > > > - About the persistent DTLS connections (Sect 7), the last two paragraphs of > section 7 explain why in some cases DTLS connections need to stay open for > a limited amount of time. They also point to the Section 11.1 about the > caveats of a persistent connection and the implicit DB. I do not think it is up to > this draft to tell the client that he should use the new cert after an > enrollment. The old cert might still be perfectly valid or the new cert may be > generated for a non DTLS client auth use. So, I don't think we need to state in > this draft that the new cert needs to be used in new DTLS connections. > > - About the DTLS connections (Sec 11.1), We have usecases where a client > does not want to spend the resources, time, performance implications to do > 3-5 DTLS connections back to back in order to update its trustanchor and do > its enrollments for multiple certs. In this cases, explained in section 7 last > paragraphs will keep a persistent DTLS connection. That is what section 11.1 is > trying to explain. Please keep in mind that in there we state that it is > RECOMMENDED for the client to start using the new explicit DB right after > the cacerts request. We just add the MAY keep the authenticated with > implicit DB DTLS connection open in some cases, but then he MUST use the > new DB starting for the next DTLS connection. > > So, I think our language in Sections 7 and 11.1 suffices when talking about > persistent TLS connections. Any time that the set of trust anchors is changed, you have also changed the set of things that you are going to trust. If you remove the trust anchor for the current connection, or restrict it in some manner, you may no longer have any trust in that connection. This is the worry that I have. I completely agree that doing multiple certificate requests (not sure why) or a query about the csr attributes followed by the certificate request is totally reasonable. You say that the client should use the new explicit trust anchors right after the cacerts request, but if you do not tear down the DTLS connection you are not doing that. You are still using the old implicit trust anchors. The MAY in section 11.1 for me is overridden by the previous SHOULD unless this case is specifically called out in section 7. I cannot understand the logic that says when you get a certificate a year from now the explicit TAs SHOULD be used, but it does not matter when you get the first certificate. * It does not look from the version on github that you made any changes for the examples: Examples: * Section A.1 I don't know what the meaning of Max-Age would be for a GET request. You may want to remove this just to avoid confusion. * Section A.2 - I am unclear about the Content-Format note in this example. If you are asking for a specific content then the correct option would be Accept. If you are indicating the content type of the response then you should probably put a header line in to that effect. In the virtual CoAP WG meeting last week we went through in some explicit detail that both Content-Format and Max-Age have no meaning when appearing on a request and therefore should not be there. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> This implies that a server is not required to support /.well-known/est We are > not clear about this. I would prefer that the server ALWAYS supports the > well-known names, such that the client can skip doing resource discovery if > it thinks that the extra bytes in the URL matter less than additional round > trip to do discovery. Agree that the server MUST always support the /.well-known/est resource, since that's the resource that by definition is used for use cases where discovery is not viable. So if a failure on that resource ought to trigger a discovery action, that would contradict its purpose. Best regards Esko Dijk -Original Message- From: Ace On Behalf Of Michael Richardson Sent: Thursday, January 24, 2019 16:59 To: Panos Kampanakis (pkampana) ; ace@ietf.org Cc: Jim Schaad ; consulta...@vanderstok.org Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 https://goo.gl/LT4HYh is a diff from -06 to current. Panos has done a great job updating this according to the issues raised during the WGLC. Thank you I have re-read diffs to catch up, and have these minor author tweaks/questions. > Client authentication via DTLS Client Certificate is mandatory. I wonder if this should go into it's own section so that one can more easily say, "Please see section x.y.z" s/enrolment/enrollment/ <- use American spelling, I guess. We had both. section 6: REQ: GET /.well-known/core?rt=ace.est* I didn't know the trailing "*" was a thing. ; rt="ace.est", I guess I have to re-read the Core Link resource discovery document. Can a server respond with ; ?? it's shorter, and I think would be valid? > If >the default root resource requests fail, the client > SHOULD fall back >to doing a resource discovery. Resource discovery > SHOULD be employed >when non-default URIs (like /est or > /est/ArbitraryLabel) or ports are > supported by the server or when the > client is unaware of what EST- >coaps resources are available by the server. This implies that a server is not required to support /.well-known/est We are not clear about this. I would prefer that the server ALWAYS supports the well-known names, such that the client can skip doing resource discovery if it thinks that the extra bytes in the URL matter less than additional round trip to do discovery. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> -Original Message- > From: Michael Richardson > Sent: Thursday, January 24, 2019 7:59 AM > To: Panos Kampanakis (pkampana) ; ace@ietf.org > Cc: Jim Schaad ; consulta...@vanderstok.org > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 > > > https://goo.gl/LT4HYh is a diff from -06 to current. > Panos has done a great job updating this according to the issues raised during > the WGLC. Thank you > > I have re-read diffs to catch up, and have these minor author > tweaks/questions. > > > Client authentication via DTLS Client Certificate is mandatory. > > I wonder if this should go into it's own section so that one can more easily > say, "Please see section x.y.z" > > s/enrolment/enrollment/ <- use American spelling, I guess. We had both. > > section 6: > REQ: GET /.well-known/core?rt=ace.est* > > I didn't know the trailing "*" was a thing. > ; rt="ace.est", > > I guess I have to re-read the Core Link resource discovery document. > Can a server respond with ; ?? it's shorter, and I think would be valid? The wild card on the end is defined behavior in RD and elsewhere. It means just what it looks like - return anything that starts with this string, including the string. Yes a server can respond with "" if the resource is at the root. Especially for the wild card not sending back the rt would not be good behavior as you don't know that it is not something else such as ace.est.foo. > > > If > >the default root resource requests fail, the client > > SHOULD fall back > >to doing a resource discovery. Resource discovery > > SHOULD be employed > >when non-default URIs (like /est or > > /est/ArbitraryLabel) or ports are > > supported by the server or when the > > client is unaware of what EST- > >coaps resources are available by the server. > > This implies that a server is not required to support /.well-known/est We are > not clear about this. I would prefer that the server ALWAYS supports the > well-known names, such that the client can skip doing resource discovery if it > thinks that the extra bytes in the URL matter less than additional round trip > to do discovery. If one is doing compressed headers, this may not be a big issue to have the extra links in there. My main issue with the section is it is not clear what an application should do and how it should make the decision. Jim > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
https://goo.gl/LT4HYh is a diff from -06 to current. Panos has done a great job updating this according to the issues raised during the WGLC. Thank you I have re-read diffs to catch up, and have these minor author tweaks/questions. > Client authentication via DTLS Client Certificate is mandatory. I wonder if this should go into it's own section so that one can more easily say, "Please see section x.y.z" s/enrolment/enrollment/ <- use American spelling, I guess. We had both. section 6: REQ: GET /.well-known/core?rt=ace.est* I didn't know the trailing "*" was a thing. ; rt="ace.est", I guess I have to re-read the Core Link resource discovery document. Can a server respond with ; ?? it's shorter, and I think would be valid? > If >the default root resource requests fail, the client > SHOULD fall back >to doing a resource discovery. Resource discovery > SHOULD be employed >when non-default URIs (like /est or > /est/ArbitraryLabel) or ports are > supported by the server or when the > client is unaware of what EST- >coaps resources are available by the server. This implies that a server is not required to support /.well-known/est We are not clear about this. I would prefer that the server ALWAYS supports the well-known names, such that the client can skip doing resource discovery if it thinks that the extra bytes in the URL matter less than additional round trip to do discovery. -- 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
[Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
I forgot to include the working group on the to list. -Original Message- From: Jim Schaad Sent: Sunday, January 13, 2019 9:51 PM To: 'draft-ietf-ace-coap-...@ietf.org' Subject: WGLC comments draft-ietf-ace-coap-est-07 Section 5.7 - Validate that CBOR array is the correct response type not multipart/cbor Section 6 - Based on earlier mails on the list I expected to see a short description of the purpose of "ArbitraryLabel". Section 6 - The fact that there are multiple ways to get the things and they might not be in the same location. Some guidance for an application on how to decide which method should be used and the choice of an ArbitraryLabel to use would be very helpful. At present I would guess that I would send a request to the well known address, if that does not work then do a discovery but it might be easier to just do the discovery to begin with and not worry about the well-known address. That is one would only do discovery if one was hitting up a resource directory and not the actual machine. On the other hand if things are rooted at /est rather than in well-known it would lead to shorter requests which once one starts doing block wise would be good. Section 7 - I would like to see some discussion of using a tls-exporter rather than tls-unique for this protocol. I am not sure what the required changes would be. I have seen notes that tls-unique is broken for TLS 1.2. Section 7 - I think it makes sense to say that after a successful enrollment the (D)TLS link MUST be torn down and the new certificate used to do authentication in the future. Section 11.1 - When changing from the implicit trust anchor to explicit trust anchors, do you expect that the est server that you are going to be talking to is generally going to change? I think that it should probably be recommended that the DTLS connection NOT be persistent across a change in the trust anchors if they are different. Nits: Section 2 para 1: I would suggest that the last sentence should read along the lines of "EST is defined to transport messages over HTTPS." Section 3 para 2: The phrase 'taken over from' is a bit odd sounding English. They could be 'taken from' or 'imported from'. 'taken over' tends to indicate that you are changing them in some way. (example use - he took over the country). Section 5.5 - SAN needs to be expanded on first use. Section 6 - Please verify that quotes on the content type when multiple values are presented are not needed. Section 8 - This sentence "The EST server can exist outside the constrained network that supports TLS/HTTP." Does not say what I think you meant to say. It is unclear if the constrained network is what supports TLS/HTTP. Section 10.1 - s/registered temporarily/registered provisionally/ s/looke/look/ Examples: * Section A.1 I don't know what the meaning of Max-Age would be for a GET request. You may want to remove this just to avoid confusion. * Section A.2 - I am unclear about the Content-Format note in this example. If you are asking for a specific content then the correct option would be Accept. If you are indicating the content type of the response then you should probably put a header line in to that effect. Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
