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
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
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
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
>>
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
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
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
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
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
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
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
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
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:
13 matches
Mail list logo
