Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-03-03 Thread John Mattsson
Richard Barnes ; wrote: >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. As explained in Stanislav's CFRG cryp

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-20 Thread Göran Selander
Hi Valery, On 2019-02-19, 19:02, "Valery Smyslov" wrote: > When done over CoAP, the message would be sent with CONfirmable, so it > would be ACK'ed. I would make the first message CONfirmable too. > > That makes it much like IKEv2 is, where all messages are ACKed and the >

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-19 Thread Valery Smyslov
Hi Michael, > When done over CoAP, the message would be sent with CONfirmable, so it > would be ACK'ed. I would make the first message CONfirmable too. > > That makes it much like IKEv2 is, where all messages are ACKed and the > initiator is responsible for all retransmits. Sure, there must be

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-19 Thread Michael Richardson
Valery Smyslov wrote: >> Current version of EDHOC is 3-pass to allow traffic data after one round trip, >> which reduces latency in many applications. >> A 4-pass version has also been discussed: >> https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ >>

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-19 Thread Valery Smyslov
Hi Göran, > Current version of EDHOC is 3-pass to allow traffic data after one round trip, > which reduces latency in many applications. > A 4-pass version has also been discussed: > https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ > > When EDHOC is used as key exchange for O

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-18 Thread Göran Selander
Hi Valery, On 2019-02-18, 08:07, "Valery Smyslov" wrote: Hi, > Richard Barnes wrote: > > 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 thi

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-18 Thread Göran Selander
Hi Michael, On 2019-02-18, 02:35, "Ace on behalf of Michael Richardson" wrote: Richard Barnes wrote: > 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 t

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-18 Thread Göran Selander
Hi Richard, From: Richard Barnes Date: Friday, 15 February 2019 at 17:19 To: Göran Selander Cc: "secdispa...@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 mailto:goran.selan...@ericsson.com>> wrote: Hi

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-17 Thread Valery Smyslov
Hi, > Richard Barnes wrote: > > 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. > > Sure. > Find a WG to adopt it, and we can make the

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-17 Thread Michael Richardson
Richard Barnes wrote: > 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. Sure. Find a WG to adopt it, and we can make the text beautiful. The p

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-15 Thread Richard Barnes
On Fri, Feb 15, 2019 at 7:13 AM Göran Selander 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

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-15 Thread Göran Selander
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 assumpti

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-15 Thread Göran Selander
Hi Hannes, On 2019-02-14, 11:50, "Hannes Tschofenig" wrote: Hi Göran, I will obviously not be able to convince you to change your research strategy. So, I will not even try. This is not just a research topic, but if this means that you respect that different companies may have d

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-14 Thread Richard Barnes
Göran: When these metrics talk about DTLS 1.3, do they mean that protocol directly, unmodified? One alternative approach people have had in mind is the idea of re-encoding / profiling down DTLS so that although it is syntactically different and maybe has fewer options, it encodes the same underlyi

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-14 Thread Hannes Tschofenig
Hi Göran, I will obviously not be able to convince you to change your research strategy. So, I will not even try. Anyway, thanks for the performance measurements your co-workers created in the Excel sheets. I will take a closer look at them. One item worthwhile to respond is the choice of the M

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

2019-02-04 Thread Göran Selander
Hi Hannes, secdispatch, and ace, (It seems Hannes original mail only went to secdispatch.) Apologies for a long mail, and late response. I had to ask some people for help with calculations, see end of this mail. On 2019-01-25, 15:15, "Secdispatch on behalf of Hannes Tschofenig" wrote: F