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

Dan Brown <danibrown@blackberry.com> Thu, 04 July 2019 13:54 UTC

From: Dan Brown <danibrown@blackberry.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "lake@ietf.org" <lake@ietf.org>
Thread-Topic: [Lake] checking we're not missing any draft inputs...
Thread-Index: AQHVMk/tpDKBAp0x+02EBnRogpN4SKa6dhEg
Date: Thu, 04 Jul 2019 13:54:31 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501E02736@XMB116CNC.rim.net>
References: <ca3f2c84-5de7-dc58-dc3d-5d79327054e8@cs.tcd.ie>
In-Reply-To: <ca3f2c84-5de7-dc58-dc3d-5d79327054e8@cs.tcd.ie>
Accept-Language: en-US, en-CA
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_0008_01D5324E.79360940"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/HjCXjNbrGx1uHUxjVRUt8CUIxJA>
Subject: Re: [Lake] checking we're not missing any draft inputs...
Precedence: list

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 <lake-bounces@ietf.org> On Behalf Of Stephen Farrell
> Sent: Thursday, July 4, 2019 6:05 AM
> To: lake@ietf.org
> 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.
>
> [1] https://trac.tools.ietf.org/bof/trac/wiki#LAKE
>

Attachment: smime.p7s

[Lake] checking we're not missing any draft input… Stephen Farrell
Re: [Lake] checking we're not missing any draft i… Dan Brown
Re: [Lake] checking we're not missing any draft i… Stephen Farrell

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

Attachment: smime.p7s