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

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

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: Ace <[e-mail]> On Behalf Of Jim Schaad
Sent: Monday, January 14, 2019 2:17 PM
To: [e-mail]
Subject: [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 <[e-mail]> 
Sent: Sunday, January 13, 2019 9:51 PM
To: '[e-mail]' <[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/ace