Re: [Secdispatch] DTLS

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 <secdispatch-bounces@ietf.org><mailto:secdispatch-bounces@ietf.org> On Behalf Of Eric Rescorla
Sent: Tuesday, March 5, 2019 7:41 AM
To: Benjamin Kaduk <kaduk@mit.edu><mailto:kaduk@mit.edu>
Cc: Richard Barnes <rlb@ipv.sx><mailto:rlb@ipv.sx>; Göran Selander <goran.selander@ericsson.com><mailto:goran.selander@ericsson.com>; secdispatch@ietf.org<mailto:secdispatch@ietf.org>
Subject: Re: [Secdispatch] DTLS - EDHOC <= 32

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

On Tue, Mar 5, 2019 at 7:09 AM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
On Tue, Mar 05, 2019 at 06:10:02AM -0800, Eric Rescorla wrote:
> 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

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.

>[...]

> 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.

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

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org<mailto:Secdispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/secdispatch