Subject: [Lake] checking we're not missing any draft inputs...

From: Stephen Farrell <[email-masked]>
Date: Thu, 4 Jul 2019 11:04:36 +0100

Hiya,

Yoav and I should have a draft agenda for the
lake BoF to post here shortly and we already
have a set of I-Ds as inputs for that and folks
who are willing to present.

However, I just wanted to check that there
aren't any other possible solutions or drafts
lurking out there of which we're not aware.

So, if there's a relevant draft that's not
mentioned at [1] or the obvious links from [1],
please post to the list before next Tuesday
(the I-D cutoff is Monday) saying why you
think we ought include that draft in the BoF
discussions.

I'm not expecting new inputs btw, so this is
really just to check.

Thanks,
S.

[1] https://trac.tools.ietf.org/bof/trac/wiki#LAKE

---

From: Dan Brown <[email-masked]>
Date: Thu, 4 Jul 2019 13:54:31 +0000

Hi,

Perhaps ECMQV might be part of solution meeting of the LAKE goals (less bits 
sent, less time spent).

I would guess that ECMQV could also meet the other LAKE goals (specific 
formatting, code re-use, etc.), for the reasons below.

For code re-use, ECMQV, compared to ECDH, just needs a few extra bit ops, and 
to access the EC point addition operation, which is often quite do-able (e.g. 
EC signature verify often needs EC point add).

For formatting, ECMQV sends the same type of data as ephemeral ECDH, and also 
has static EC certs (much like signing keys), so it seems that formatting with 
ECQMV should not have any extra cost.

Recall that ECMQV aims to have the same effect signed ephemeral ECDH, but 
without the cost of signature (and without the undeniability of signatures). 
So, in theory, ECMQV has potentially smaller code size than ECDH + signature, 
since the signature code can be dropped (though sig verify might be needed for 
the PKI part of the system).

* * *

Perhaps out of LAKE scope (more towards lightweight PKI): There's also a tech 
called ECQV implicit certificate, which saves the cost of signature in a cert 
(not in an AKE).  I raise this because an AKE often has to interface with some 
kind of PKI.  Also in the ECQV, the public key is reconstructed from the cet, 
and the calculation to do this can be merged with the key agreement 
calculation for potential extra time savings.

Best regards,

Dan Brown
BlackBerry, Security in Motion
+1 (289) 261-4157

> -----Original Message-----
> From: Lake <[email-masked]> On Behalf Of Stephen Farrell
> Sent: Thursday, July 4, 2019 6:05 AM
> To: [email-masked]
> Subject: [Lake] checking we're not missing any draft inputs...
>
>
> Hiya,
>
> Yoav and I should have a draft agenda for the lake BoF to post here shortly
> and we already have a set of I-Ds as inputs for that and folks who are 
> willing
> to present.
>
> However, I just wanted to check that there aren't any other possible
> solutions or drafts lurking out there of which we're not aware.
>
> So, if there's a relevant draft that's not mentioned at [1] or the obvious 
> links
> from [1], please post to the list before next Tuesday (the I-D cutoff is
> Monday) saying why you think we ought include that draft in the BoF
> discussions.
>
> I'm not expecting new inputs btw, so this is really just to check.
>
> Thanks,
> S.
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 4 Jul 2019 15:25:36 +0100

Hi Dan,

> Perhaps ECMQV might be part of solution meeting of the LAKE goals (less bits 

I guess that'd be a solution-detail rather
than an alternative input draft or is there
a draft that people can look at? If the
former, then it's maybe more of a thing to
consider later rather than at the BoF?

In case it helps others, the first relevant
thing I found was RFC5753 which defines ways
to use ECMQV in CMS, but I'd be surprised if
CMS were proposed as being most of the answer
for LAKE.

Cheers,
S.

BTW, while I was looking I noticed 5753's
IPR declaration [1], refers to an earlier IPR
declaration [2] that in turn refers to [3]
which now re-directs me to a generic web
page [4]. Could be something to fix if one
wanted to propose ECMQV I guess.

[1] https://datatracker.ietf.org/ipr/1485/
[2] https://datatracker.ietf.org/ipr/1154/
[3]
http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf
[4] https://blackberry.certicom.com/