Subject: [Secdispatch] DTLS - EDHOC <= 32

From: Richard Barnes <[email-masked]>
Date: Fri, 1 Mar 2019 12:08:42 -0500

Hey folks,

To try to understand the size arguments w.r.t. EDHOC / DTLS, I sat down and
tried to lower-bound the size of the messages in each protocol.  The theory
I'm using here is: The only things that really need to be in these
protocols are the crypto variables.  Everything else is just a matter of
encoding or pre-negotiation.  Under that theory, consider the following
cartoon sketches of the two protocols in the full handshake, mutually
authenticated with asymmetric keys, including minimum sizes in octets
assuming a 128-bit security level:

DTLS 1.3 (mutually authenticated):
1. C->S: DH (32)
2. S->C: DH, PUBKEY, SIG, MAC, TAG (176 = 32 + 32 + 64 + 32 + 16)
3. C->S: PUBKEY, SIG, MAC, TAG (144 = 32 + 64 + 32 + 16)

EDHOC:
1. C->S: DH (32)
2. S->C: DH, PUBKEY, SIG, TAG (144 = 32 + 32 + 64 + 16)
3. C->S: PUBKEY, SIG, TAG (112 = 32 + 64 + 16)

The conclusions I draw from this (assuming the above summary is correct):

1. The size estimates in the EDHOC draft cannot be correct.  On the one
hand, the EDHOC estimates for messages 2 and 3 are all below the above
minimums.  On the other hand, the DTLS size estimates indicate a not very
aggressive optimization, since they are all well above these minimums.

2. The difference between EDHOC and DTLS is at most 32 octets.  Whatever
encoding you adopt for EDHOC, it can be translated to DTLS at a cost of 32
octets.

3. The primary driver of the size difference between EDHOC and DTLS is the
DTLS Finished MAC.

Basically, EDHOC claims they can get away without the Finished MAC because
the correct stuff is covered under the AEAD tag.  However, if this approach
is correct, then you could also "virtualize" the DTLS Finished MAC by
having the peers include it in the AEAD calculation, but strip it from
what's sent on the wire.  In either case, fresh analysis is needed.  But an
analysis of DTLS with a virtualized MAC seems much simpler and more focused
than starting from scratch.

Hope folks find this helpful.

--Richard

---

From: Jim Schaad <[email-masked]>
Date: Fri, 1 Mar 2019 15:23:13 -0800

Richard,

You incorrectly translated the EDHOC protocol below.

Jim

From: Secdispatch <[email-masked]> On Behalf Of Richard Barnes
Sent: Friday, March 1, 2019 9:09 AM
To: [email-masked]
Subject: [Secdispatch] DTLS - EDHOC <= 32

Hey folks,

To try to understand the size arguments w.r.t. EDHOC / DTLS, I sat down and tried to lower-bound the size of the messages in each protocol.  The theory I'm using here is: The only things that really need to be in these protocols are the crypto variables.  Everything else is just a matter of encoding or pre-negotiation.  Under that theory, consider the following cartoon sketches of the two protocols in the full handshake, mutually authenticated with asymmetric keys, including minimum sizes in octets assuming a 128-bit security level:

1. C->S: DH (32)

EDHOC:

1. C->S: DH (32)

   2.  S->C: DH, SIG, TAG (112 = 32 + 64 + 16)

    2. C->S: SIG, Tag (80 = 64+16)

EDHOC is defined to send a key identifier rather than a key.

1. The size estimates in the EDHOC draft cannot be correct.  On the one hand, the EDHOC estimates for messages 2 and 3 are all below the above minimums..  On the other hand, the DTLS size estimates indicate a not very aggressive optimization, since they are all well above these minimums.

2. The difference between EDHOC and DTLS is at most 32 octets.  Whatever encoding you adopt for EDHOC, it can be translated to DTLS at a cost of 32 octets.  Difference is therefore 64 at most 64 octets based on just that data.

3. The primary driver of the size difference between EDHOC and DTLS is the DTLS Finished MAC.

Basically, EDHOC claims they can get away without the Finished MAC because the correct stuff is covered under the AEAD tag.  However, if this approach is correct, then you could also "virtualize" the DTLS Finished MAC by having the peers include it in the AEAD calculation, but strip it from what's sent on the wire.  In either case, fresh analysis is needed.  But an analysis of DTLS with a virtualized MAC seems much simpler and more focused than starting from scratch.

--Richard

---

From: Jim Schaad <[email-masked]>
Date: Fri, 1 Mar 2019 15:49:10 -0800

I just realized I forgot to include the original 32 bytes – thus we are at 96 bytes smaller.

From: Secdispatch <[email-masked]> On Behalf Of Jim Schaad
Sent: Friday, March 1, 2019 3:23 PM
To: 'Richard Barnes' <[email-masked]>; [email-masked]
Subject: Re: [Secdispatch] DTLS - EDHOC <= 32

Richard,

Jim

From: Secdispatch <[email-masked] <mailto:[email-masked]> > On Behalf Of Richard Barnes
Sent: Friday, March 1, 2019 9:09 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Secdispatch] DTLS - EDHOC <= 32

Hey folks,

1. C->S: DH (32)

EDHOC:

1. C->S: DH (32)

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Fri, 1 Mar 2019 23:13:08 -0500

Fair point, Jim, but I don't think it actually matters -- you could just as
well add key IDs to TLS, e.g., as a new certificate type (cf. RFC 7250).
So subtract the 32 bytes of PUBKEY from all accounts, and we're still at 32
bytes/message of difference.

--Richard

On Fri, Mar 1, 2019 at 6:23 PM Jim Schaad <[email-masked]> wrote:

> *From:* Secdispatch <[email-masked]> *On Behalf Of *Richard
> Barnes
> *Sent:* Friday, March 1, 2019 9:09 AM
> *To:* [email-masked]
> *Subject:* [Secdispatch] DTLS - EDHOC <= 32
>
>
>
> Hey folks,
>
>
>
> To try to understand the size arguments w.r.t. EDHOC / DTLS, I sat down
> and tried to lower-bound the size of the messages in each protocol.  The
> theory I'm using here is: The only things that really need to be in these
> minimums..  On the other hand, the DTLS size estimates indicate a not very
> octets.  Difference is therefore 64 at most 64 octets based on just that
> data.
>
>
>

---

From: Jim Schaad <[email-masked]>
Date: Fri, 1 Mar 2019 21:19:50 -0800

I have never done an implementation of TLS, about how many lines of code do you think it would be.  If you do all of the changes that would be necessary to scale things down you basically have a brand new code base in any event.  I have done an implementation of EDHOC once upon a time so I have an idea of how big of a code base that is.

Assume that crypto does not count as that would be the same for both implementations and is likely to be at least partly in hardware.

Jim

From: Richard Barnes <[email-masked]> 
Sent: Friday, March 1, 2019 8:13 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [Secdispatch] DTLS - EDHOC <= 32

Fair point, Jim, but I don't think it actually matters -- you could just as well add key IDs to TLS, e.g., as a new certificate type (cf. RFC 7250).  So subtract the 32 bytes of PUBKEY from all accounts, and we're still at 32 bytes/message of difference.

--Richard

On Fri, Mar 1, 2019 at 6:23 PM Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Richard,

Jim

Hey folks,

1. C->S: DH (32)

EDHOC:

1. C->S: DH (32)

--Richard

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 03 Mar 2019 18:29:26 -0500

We recently had someone do a completely new implementation of TLS.  I think that it's a pretty good example of a stack, though optimized for clarity and maintenance rather than size.  It's PSK mode, so it's a little more complex than ECDH.  It weighs in at just over 2k lines of JavaScript.  A fairly large proportion of that is dealing with the encoding in an ergonomic fashion.  Using a rigid encoding would eliminate almost all of that code.

If you want something closer to reality for small things, try https://bearssl.org/sizes.html  That isn't TLS 1.3, so it's probably a little off, but it's a fine basis for at least making an assessment.  It includes all the crypto, but you can get an idea of the costs.

On Sat, Mar 2, 2019, at 16:20, Jim Schaad wrote:
> I have never done an implementation of TLS, about how many lines of 
> code do you think it would be. If you do all of the changes that would 
> be necessary to scale things down you basically have a brand new code 
> base in any event. I have done an implementation of EDHOC once upon a 
> time so I have an idea of how big of a code base that is.
> 
> 
> Assume that crypto does not count as that would be the same for both 
> implementations and is likely to be at least partly in hardware.
> 
> 
> Jim
> 
> 
> 
> *From:* Richard Barnes <[email-masked]> 
> *Sent:* Friday, March 1, 2019 8:13 PM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Secdispatch] DTLS - EDHOC <= 32
> 
> 
> Fair point, Jim, but I don't think it actually matters -- you could 
> just as well add key IDs to TLS, e.g., as a new certificate type (cf. 
> RFC 7250). So subtract the 32 bytes of PUBKEY from all accounts, and 
> we're still at 32 bytes/message of difference.
> 
> 
> --Richard
> 
> 
> > *From:* Secdispatch <[email-masked]> *On Behalf Of *Richard Barnes
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 4 Mar 2019 07:11:52 -0500

Since you asked, I just went ahead and implemented a "femtoTLS" variant
over the weekend.  It's about 420 lines of Go, leveraging some crypto
routines and message formats from Mint.

https://github.com/bifurcation/mint/compare/ftls

The protocol outlined there is TLS 1.3, but with the ClientHello, Server
Hello, and Certificate message replaced with smaller variants.  The message
sizes are as follows:

m1 (ClientHello):  56
m2 (ServerHello, Certificate, CertificateVerify, Finished) : 178
m3 (Certificate, CertificateVerify, Finished): 125

Just to highlight the framing / negotiation overhead:

m1 = Random(16) + DH(32) + Overhead(8)
m2 = Random(16) + DH(32) + SIG(64) + MAC(32) + TAG(16) + Overhead(18)
m3 = SIG(64) + MAC(32) + TAG(16) + Overhead(13)

The optimization here is pretty light; you could save a few more overhead
octets if you were willing to special-case the syntax more.  Encoding in
CBOR seems like it would probably produce results in the same ballpark.

This also nicely highlights the crypto shortcuts that EDHOC is benefitting
from:

- Omitting Random values in the first two messages
- Relying on an AEAD tag instead of the Finished MAC

On Sat, Mar 2, 2019 at 12:20 AM Jim Schaad <[email-masked]> wrote:

> I have never done an implementation of TLS, about how many lines of code
> do you think it would be.  If you do all of the changes that would be
> necessary to scale things down you basically have a brand new code base in
> any event.  I have done an implementation of EDHOC once upon a time so I
> have an idea of how big of a code base that is.
>
>
>
> Fair point, Jim, but I don't think it actually matters -- you could just
> as well add key IDs to TLS, e.g., as a new certificate type (cf. RFC
> 7250).  So subtract the 32 bytes of PUBKEY from all accounts, and we're
> still at 32 bytes/message of difference.
>
>
>
> --Richard
>
>
>

---

From: Göran Selander <[email-masked]>
Date: Mon, 4 Mar 2019 19:27:35 +0000

Hi Richard,

I’m delighted to see that EDHOC has triggered people to start thinking about reducing the overhead of the TLS 1.3 handshake, just like the message size comparison between OSCORE and DTLS record layer resulted in the reduced overhead for the DTLS record layer.

I understand this was an exercise in code size, but I’m confused about what is being implemented. This thread started out with an abstracted TLS 1.3, but if I understand right, what you are sketching here is a third protocol sharing some features of TLS 1.3 and some of EDHOC, but not compatible with any of them. If that is the case, then I think this has left the category “current solutions” and should be measured with the same yardstick as EDHOC. Since the cryptographic protocol is not TLS 1.3, the security properties would need to be re-assessed. The message sizes are smaller than TLS 1.3 but larger than EDHOC. As for code size, the relevant comparison is not standalone, but on top of an existing CoAP/OSCORE implementation.

Continuing on this route you can come arbitrarily close to EDHOC, but can you do something that performs better?

Göran

From: Secdispatch <[email-masked]> on behalf of Richard Barnes <[email-masked]>
Date: Monday, 4 March 2019 at 13:12
To: Jim Schaad <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Secdispatch] DTLS - EDHOC <= 32

Since you asked, I just went ahead and implemented a "femtoTLS" variant over the weekend.  It's about 420 lines of Go, leveraging some crypto routines and message formats from Mint.

The protocol outlined there is TLS 1.3, but with the ClientHello, Server Hello, and Certificate message replaced with smaller variants.  The message sizes are as follows:

m1 (ClientHello):  56

The optimization here is pretty light; you could save a few more overhead octets if you were willing to special-case the syntax more.  Encoding in CBOR seems like it would probably produce results in the same ballpark.

This also nicely highlights the crypto shortcuts that EDHOC is benefitting from:

On Sat, Mar 2, 2019 at 12:20 AM Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
I have never done an implementation of TLS, about how many lines of code do you think it would be.  If you do all of the changes that would be necessary to scale things down you basically have a brand new code base in any event..  I have done an implementation of EDHOC once upon a time so I have an idea of how big of a code base that is.

Jim

From: Richard Barnes <[email-masked]>
Sent: Friday, March 1, 2019 8:13 PM
To: Jim Schaad <[email-masked]<mailto:ietf@augustcellars..com>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Secdispatch] DTLS - EDHOC <= 32

--Richard

On Fri, Mar 1, 2019 at 6:23 PM Jim Schaad <[email-masked]<mailto:ietf@augustcellars..com>> wrote:
Richard,

Jim

From: Secdispatch <[email-masked]<mailto:[email-masked]>> On Behalf Of Richard Barnes
Sent: Friday, March 1, 2019 9:09 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Secdispatch] DTLS - EDHOC <= 32

Hey folks,

To try to understand the size arguments w.r..t. EDHOC / DTLS, I sat down and tried to lower-bound the size of the messages in each protocol.  The theory I'm using here is: The only things that really need to be in these protocols are the crypto variables.  Everything else is just a matter of encoding or pre-negotiation.  Under that theory, consider the following cartoon sketches of the two protocols in the full handshake, mutually authenticated with asymmetric keys, including minimum sizes in octets assuming a 128-bit security level:

EDHOC:
1. C->S: DH (32)

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 4 Mar 2019 23:00:31 -0500

Hi Göran,

The idea of this "fTLS" construction is that it preserves the underlying
AKE that TLS uses.  The only difference is that:

1. The client/server random values are slightly smaller
2. The messages fed into the transcript are formatted slightly differently

The idea being that this protocol should preserve all of the security
properties that TLS has, with little or no modification to the prior proofs
of these properties.  I think this is what folks have had in mind when
calling for an alternative based on TLS.

--Richard

On Mon, Mar 4, 2019 at 2:27 PM Göran Selander <[email-masked]>
wrote:

> Hi Richard,
>
>
>
> I’m delighted to see that EDHOC has triggered people to start thinking
> about reducing the overhead of the TLS 1.3 handshake, just like the message
> size comparison between OSCORE and DTLS record layer resulted in the
> reduced overhead for the DTLS record layer.
>
>
>
> I understand this was an exercise in code size, but I’m confused about
> what is being implemented. This thread started out with an abstracted TLS
> 1.3, but if I understand right, what you are sketching here is a third
> protocol sharing some features of TLS 1.3 and some of EDHOC, but not
> compatible with any of them. If that is the case, then I think this has
> left the category “current solutions” and should be measured with the same
> yardstick as EDHOC. Since the cryptographic protocol is not TLS 1.3, the
> security properties would need to be re-assessed. The message sizes are
> smaller than TLS 1.3 but larger than EDHOC. As for code size, the relevant
> comparison is not standalone, but on top of an existing CoAP/OSCORE
> implementation.
>
>
>
> *From: *Secdispatch <[email-masked]> on behalf of Richard
> Barnes <[email-masked]>
> *Date: *Monday, 4 March 2019 at 13:12
> *To: *Jim Schaad <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Secdispatch] DTLS - EDHOC <= 32
>
>
>
> any event..  I have done an implementation of EDHOC once upon a time so I
> *To:* Jim Schaad <[email-masked] <ietf@augustcellars..com>>
> On Fri, Mar 1, 2019 at 6:23 PM Jim Schaad <[email-masked]
> <ietf@augustcellars..com>> wrote:
>
> Richard,
>
>
>
> To try to understand the size arguments w.r..t. EDHOC / DTLS, I sat down

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Mar 2019 06:10:02 -0800

Hi folks,

While I think Richard's characterization of fTLS is strictly correct,
I agree you have to squint a bit to see that it's isomorphic to
TLS 1.3. In the spirit of clarity, I've put together the following
very rough draft:

   https://github.com/ekr/draft-rescorla-tls-ctls

This is a pretty straight compactification of TLS 1.3, which
gets you down to the following message sizes for each flight:

Flight 1:  59
Flight 2: 189
Flight 3: 127

I've verified the complicated pieces (CH and SH) with Mint, but I just
started on this last night, so I haven't quite gotten the other pieces
coded up, so there may be some small arithmetic errors. Apologies for
that in advance.

The basic approach here is to have more compact encodings of
everything and then to have some sensible defaults so you don't have
to transmit them. The vast majority of the data is in the "mandatory"
cryptographic material. I've chosen the following values:

- 16 byte randoms (matching fTLS)
- 32 byte Finished messages (matching TLS 1.3)
- 8 byte authentication tags (matching what EDHOC chose)
  If you want 16 bytes, add 8 to flights 2 and 3.

There are some obvious avenues to shave a few bytes here and there,
mostly because I did a sort of straight translation of TLS 1.3, so for
instance, there are empty EE and CR messages, and you could omit
length fields for some fixed-length or deterministic HS messages. I
didn't bother with this because it's more in the way of a POC and, as
Richard noted, most of the size difference between this and EDHOC is
the Randoms and the Finished.

-Ekr

On Mon, Mar 4, 2019 at 8:01 PM Richard Barnes <[email-masked]> wrote:

> 1.. The client/server random values are slightly smaller
>> <https://github..com/bifurcation/mint/compare/ftls>
>>
>>
>>
>> Basically, EDHOC claims they can get away without the Finished MAC
>> because the correct stuff is covered under the AEAD tag.  However, if this
>> approach is correct, then you could also "virtualize" the DTLS Finished MAC
>> by having the peers include it in the AEAD calculation, but strip it from

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 5 Mar 2019 09:09:32 -0600

>    https://github.com/ekr/draft-rescorla-tls-ctls

Thanks for thinking about this more.  I think that Richard's analysis (with
Jim's corrections) did get to the crux of the issue, which is that the
clever encoding games are easy to adjust, and the cryptographic content of
the messages is most important.

>[...]

> the Randoms and the Finished.

In particular, while we may have to defer to the cryptographers about
proving whether using the AEAD tag to perform the role that TLS's distinct
Finished message does, there are some clear engineering tradeoffs in
whether or not to omit the Randoms, and I hope we can set ourselves up for
a productive discussion of that question.  (That is, I wouldn't worry too
much about tidying up cTLS right away.)

I'd also be interested in hearing more about what the EDHOC team's internal
success criteria were (i.e., how they decided it was "done" enough to bring
to the IETF).  Here in SECDISPATCH we'll in effect be coming up with a
new/rehashed problem statement and success criteria for the IETF
application, but having a solid starting point from the preexisting work
could help our efficiency a lot.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Mar 2019 10:29:01 -0500

A reminder, if you find that webex says that your computer is not
"compatible", then visit ietf.webex.com, and "logout".

You can then visit:
    https://ietf.webex.com/ietf/j.php?MTID=m36d7ee1d1c5d7e73010537a4cc710383

and get the webrtc version of webex.  Very stupid.

I wish the IESG would do something about this "free" donation, for which we
have no SLA.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Mar 2019 07:40:53 -0800

I've been thinking a bit about the use of a key_id as an optimization
to avoid carrying the key, and I think it might be a source of
identity misbinding attacks. Note that this is not an issue specifically
to EDHOC or cTLS or whatever, it can happen whenever you use
this optimization.

Consider the case where Alice has accounts with both Bob and the
Attacker. Alice uses a certificate for authentication both Bob and the
Attacker have registered key_ids with Alice. Specifically, they have
both registered Key_ID=0 and Key=K_Bob. Obviously, the Attacker
doesn't have the private key for Bob, but this can still happen if
Alice doesn't check for PoP.

In this case, there's a trivial identity misbinding attack if the
attacker can get Alice to connect to it, namely:

Alice                     Attacker                       Bob

g^x ->
                          g^x ->
                              <- g^y, ID=0, Sign(K_b, .) ...
 <- g^y, ID=0, Sign(K_b, .) ...

CERT, Sign(K_a, .) ... ->
                                   CERT, Sign(K_a, .) ... ->

This is really just another flavor of the usual misbinding attack
based on someone claiming to have another person's public key
without PoP verification.

The classic defense in SIGMA is that the identities are folded into
the handshake transcript, but the problem is that if the identities
are self-asserted or public keys, you can get identity misbinding as
above (see also
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-uks/ for
another example of how this can happen).

-Ekr

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Mar 2019 12:49:55 -0500

Just to close the loop on this particular question, the response from John here was that if the transcript includes the inferred identity not the key_id, then you avoid misbinding because a disagreement about identity leads to a different transcript.

This is very different than the cached-info design, where the hash stands in for the identity.

On Wed, Mar 6, 2019, at 02:41, Eric Rescorla wrote:
> Attacker have registered key_ids with Alice.. Specifically, they have
>  <- g^y, ID=0, Sign(K_b, ..) ...
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Mar 2019 09:56:15 -0800

On Tue, Mar 5, 2019 at 9:50 AM Martin Thomson <[email-masked]> wrote:

> Just to close the loop on this particular question, the response from John
> here was that if the transcript includes the inferred identity not the
> key_id, then you avoid misbinding because a disagreement about identity
> leads to a different transcript.
>

Hmm... Maybe? If the identities are just RPKs with no other identifier,
then I think this still can happen.

> This is very different than the cached-info design, where the hash stands

Well, the cached info design is tied to the cert (if there is a cert) so it
transitively includes the identity.

-Ekr

---

From: Jim Schaad <[email-masked]>
Date: Tue, 5 Mar 2019 09:59:52 -0800

I don’t understand the attack below.  Are you missing some pieces or did things get misaligned?  What do you think the attacker is ending up with at the end?  g^xy?

Jim

From: Secdispatch <[email-masked]> On Behalf Of Eric Rescorla
Sent: Tuesday, March 5, 2019 7:41 AM
To: Benjamin Kaduk <[email-masked]>
Cc: Richard Barnes <[email-masked]>; Göran Selander <[email-masked]>; [email-masked]
Subject: Re: [Secdispatch] DTLS - EDHOC <= 32

this optimization.

Alice                     Attacker                       Bob

g^x ->
                          g^x ->

-Ekr

On Tue, Mar 5, 2019 at 7:09 AM Benjamin Kaduk <[email-masked] <mailto:[email-masked]> > wrote:

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Mar 2019 10:12:19 -0800

No. Alice thinks she is talking to the attacker but she's actually talking
to Bob.

The attacker doesn't get to see the traffic, but that's not necessarily
required for an attack. Say that the attacker is able to control the
messages that Alice sends to itself (this is very natural in the Web
context), then it can divert those messages to Bob but authenticated by
Alice.

-Ekr

On Tue, Mar 5, 2019 at 10:00 AM Jim Schaad <[email-masked]> wrote:

> I don’t understand the attack below.  Are you missing some pieces or did
> things get misaligned?  What do you think the attacker is ending up with at
> the end?  g^xy?
>
>
>
> Jim
>
>
>
>
>
> *From:* Secdispatch <[email-masked]> *On Behalf Of *Eric
> Rescorla
> *Sent:* Tuesday, March 5, 2019 7:41 AM
> *To:* Benjamin Kaduk <[email-masked]>
> *Cc:* Richard Barnes <[email-masked]>; Göran Selander <
> [email-masked]>; [email-masked]

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 11 Mar 2019 18:34:45 +0000

Hi Jim,

We have just written a report on misbinding attacks in a slightly different context. It might be useful reading if you want to learn more about misbinding in general:

https://arxiv.org/abs/1902.07550

We will be discussing this during the SAAG session Prague.

--Mohit

On 3/5/19 7:59 PM, Jim Schaad wrote:
I don’t understand the attack below.  Are you missing some pieces or did things get misaligned?  What do you think the attacker is ending up with at the end?  g^xy?

Jim

From: Secdispatch <[email-masked]><mailto:[email-masked]> On Behalf Of Eric Rescorla
Sent: Tuesday, March 5, 2019 7:41 AM
To: Benjamin Kaduk <[email-masked]><mailto:[email-masked]>
Cc: Richard Barnes <[email-masked]><mailto:[email-masked]>; Göran Selander <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Secdispatch] DTLS - EDHOC <= 32

Alice                     Attacker                       Bob

g^x ->
                          g^x ->
                              <- g^y, ID=0, Sign(K_b, .) ....
 <- g^y, ID=0, Sign(K_b, ..) ...

CERT, Sign(K_a, ..) ... ->
                                   CERT, Sign(K_a, .) ... ->

-Ekr

On Tue, Mar 5, 2019 at 7:09 AM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:

-Ben

_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch