Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
Yes that is the essence of what I am looking for in terms of dealing with a new trust point. Jim > -Original Message- > From: Panos Kampanakis (pkampana) > Sent: Monday, January 28, 2019 9:42 PM > To: Jim Schaad ; ace@ietf.org > Subject: 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&q=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 > s
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&q=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 secti
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&q=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&q=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
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&q=is%3Aissue+draft-ietf-ace-coap-est-07 I also lay out the changes below: - We fixed all the nits. - About the Arbitrary Label, we added "Arbitrary Labels are usually defined and used by EST CAs in order to route client requests to the appropriate certificate profile." - About guidance when discovery is necessary, we added "Discovery SHOULD NOT be chosen when the client is preconfigured to use the default /.well known/est server root resource and port 5684. 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." - About CBOR in section 5.7 we added "The sever-side key generation response is returned with content format application/multipart-core [I-D.ietf-core-multipart-ct] containing a CBOR array with four items (Section 5.2.1). " - About tlsl-unique and TLS exporters, this was discussed before for TLS 1.3 (https://mailarchive.ietf.org/arch/msg/tls/-8rDHLR6hiR7wsLsf6nVLtqCCmU ) but we can't really mandate using a TLS exporter for tls-unique as this is not standardized anywhere. If there was an 5929-bis to update the tls-unique in order to address the risk and use an exporter then this draft would automatically inherit it. Note that the implications of 3SHAKE were significant to TLS because the clients were not checking the server cert after the renegotiation (Step 3 of the paper). The implication to POP linking that EST-coaps uses though is minimal because it does not expose anything private, it just deems channel binding useless. To address the concern I added text in the Security Considerations " What's more, POP linking uses tls-unique as it is defined in [RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing a man-in-the-middle to leverage session resumption and renegotiation to inject himself between a client and server even when channel binding is in use. The attack was possible because of certain (D)TLS implementation imperfections. In the context of this specification, an attacker could invalidate the purpose of the POP linking ChallengePassword in the client request by resuming an EST-coaps connection. Even though the practical risk of such an attack to EST-coaps is not devastating, we would rather use a more secure channel binding mechanism. Such a mechanism could include an updated tls-unique value generation like the tls-unique-prf defined in [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]). Such mechanism has not been standardized yet. Adopting in this document a channel binding value generated from an exporter would break backwards compatibility. Thus, in this specification we still depend in the tls-unique mechansim defined in [RFC5929], especially since the practicallity of such an attack would not expose any messages exchanged with EST-coaps." - 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. ~~~
