Subject: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07

From: Jim Schaad <[email-masked]>
Date: Mon, 14 Jan 2019 11:16:32 -0800

I forgot to include the working group on the to list.

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Sunday, January 13, 2019 9:51 PM
To: [email-masked]' <[email-masked]>
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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 18 Jan 2019 20:58:59 +0000

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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Let us know if there are more comments. 

Rgs,
Panos

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Sunday, January 13, 2019 9:51 PM
To: [email-masked]' <[email-masked]>
Subject: WGLC comments draft-ietf-ace-coap-est-07

Nits:

s/looke/look/

Examples:

Jim

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Jan 2019 10:59:09 -0500

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.
  </est>; 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Thu, 24 Jan 2019 10:40:30 -0800

> From: Michael Richardson <[email-masked]>
> Sent: Thursday, January 24, 2019 7:59 AM
> To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
> Cc: Jim Schaad <[email-masked]>; [email-masked]
> Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> 
> 
during
> the WGLC. Thank you

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.

> 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

---

From: Esko Dijk <[email-masked]>
Date: Fri, 25 Jan 2019 12:34:12 +0000

> 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 <[email-masked]> On Behalf Of Michael Richardson
Sent: Thursday, January 24, 2019 16:59
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Cc: Jim Schaad <[email-masked]>; [email-masked]
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

> 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"

section 6:

>                        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 <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Mon, 28 Jan 2019 13:36:58 -0800

Clipping out things which are not issues:

> From: Ace <[email-masked]> On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Friday, January 18, 2019 12:59 PM
> To: Jim Schaad <[email-masked]>; [email-masked]
> 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
> 
> - 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:

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.

---

From: Jim Schaad <[email-masked]>
Date: Mon, 28 Jan 2019 21:07:03 -0800

> Sent: Monday, January 28, 2019 1:37 PM
> To: 'Panos Kampanakis (pkampana)' <[email-masked]>; [email-masked]
> > 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-
> > For a more easily consumable content, your latest feedback was tracked
> > and addressed here https://github.com/SanKumar2015/EST-
> > 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
> > - 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
> > 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.
> >
for
> the current connection, or restrict it in some manner, you may no longer
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.
> 
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.
> 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.
> 
> 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.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 29 Jan 2019 05:41:59 +0000

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 <[email-masked]> 
Sent: Monday, January 28, 2019 4:37 PM
To: Panos Kampanakis (pkampana) <[email-masked]>; [email-masked]
Subject: RE: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07

of
is up to
may be
state in
do
last
11.1 is
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.

---

From: Jim Schaad <[email-masked]>
Date: Mon, 28 Jan 2019 21:57:39 -0800

Yes that is the essence of what I am looking for in terms of dealing with a
new trust point.

Jim

> From: Panos Kampanakis (pkampana) <[email-masked]>
> Sent: Monday, January 28, 2019 9:42 PM
after
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
> 
> 
> 
for
completely
after
are
the logic
SHOULD