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

["Panos Kampanakis (pkampana)" <[e-mail]>]

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

Clipping out things which are not issues:


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