Hi Richard, From: Richard Barnes <r...@ipv.sx> Date: Friday, 15 February 2019 at 17:19 To: Göran Selander <goran.selan...@ericsson.com> Cc: "secdispa...@ietf.org" <secdispa...@ietf.org>, "ace@ietf.org" <ace@ietf.org> Subject: Re: [Secdispatch] FW: [secdir] EDHOC and Transports
On Fri, Feb 15, 2019 at 7:13 AM Göran Selander <goran.selan...@ericsson.com<mailto:goran.selan...@ericsson.com>> wrote: Hi Richard, Thanks, that is a fair question to ask on behalf of those who are new to the subject. The short answer is: Yes, we have counted every byte of the TLS handshake and, no, we don’t think it is possible to support the same radio technologies as EDHOC do, unless you change some assumption which impacts the security analysis of TLS. This is the part that worries me. It would be helpful to be very crisp about what assumptions are being changed here, and why it's OK for them to be changed. Especially given that the Bruni et al. paper seems to have found flaws. Your point about CBOR isn't relevant here. Re-encoding is fine; it's changing the AKE that necessitates a whole bunch of new analysis. Perhaps I was unclear: We are not proposing any changes to (D)TLS 1.3. We believe that making (D)TLS 1.3 AKE fit into small frames requires changing some assumption of the protocol which, as you say, would necessitate a new analysis of TLS. The point about reencoding is about inefficiency or incompatibility, which are both relevant for the overall discussion, but not about security. The paper you mention analyzed version -08 of EDHOC and, essentially, the expected security properties hold. All comments from this analysis are addressed in the updated version of the protocol. Section 4 of the paper describes the security properties. Their main concern was related to the application data sent by party V in message #2 (APP_2 in -08) being encrypted, which may mislead application developers that it is protected for the intended party U, but party U is not authenticated at the time of sending message #2. Later versions of the draft emphasize how to handle data which is not protected (see Section 8.4 in -11) and the APP_2 message field is renamed UAD_2 (Unprotected Application Data). Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A little more prose to explain what's going on would go a long way toward helping this discussion be productive. What part of the draft did you find difficult to understand? Göran
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
