Subject: Re: [Lwip] WGLC for draft-ietf-lwig-crypto-sensors-03

From: Mohit Sethi <[email-masked]>
Date: Sun, 6 Aug 2017 13:18:00 +0300

Hi all

The authors of the document believe that it is ready to move forward. 
During the previous last call we had already received support from 
several working group members.

Based on the feedback during the previous last call, we removed the 
performance measurements of RSA key sizes smaller than 2048 bits. We 
also added performance measurements of ECDSA sign operation on ARM 
32-bit platforms. Additionally, we improved the text on the need for a 
random number generator, more guidance on choosing the right platform, 
and why larger flash memory size is needed for firmware updates. We also 
removed some extraneous text from the background section. Any further 
comments are welcome.

--Mohit

On 07/31/2017 04:23 AM, Zhen Cao wrote:
> Hello Everyone,
>
> This email starts the WGLC for draft-ietf-lwig-crypto-sensors-03
> https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-03
>
> This is a second WGLC with the new draft resolving the comments
> received from last round.
>
> We still appreciate very much if could you help review the document
> and send your comments to the mailing list. Thank you in advance.
>
> The WGLC will end in ONE week till August 7th, 2017.
>
> Thank the authors for their hard work again.
>
> Best regards,
> Zhen
>
> On Wed, Feb 22, 2017 at 11:15 AM, Zhen Cao <[email-masked]> wrote:
>> Hello everyone,
>>
>> This email starts the WGLC for draft-ietf-lwig-crypto-sensors-02
>> (https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02)
>>
>> Could you help review the document and send your comments to the
>> mailing list. Thank you in advance.
>>
>> The WGLC will end in two weeks from now.
>>
>> BR,
>> Zhen
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 6 Aug 2017 13:39:58 +0200

Hi Mohit,

One point that came up in the discussion in Prague was Diffie-Hellman performance.
For a deployment that relies on symmetric keys for mutual authentication, it may be useful to do an (ECC) D-H key agreement to achieve forward security.
I believe some numbers for that are available?  
It would be useful to include them in order to motivate the use of forward secure key agreement.

Grüße, Carsten

> On Aug 6, 2017, at 12:18, Mohit Sethi <[email-masked]> wrote:
> 
> Hi all
> 
> The authors of the document believe that it is ready to move forward. During the previous last call we had already received support from several working group members.
> 
> Based on the feedback during the previous last call, we removed the performance measurements of RSA key sizes smaller than 2048 bits. We also added performance measurements of ECDSA sign operation on ARM 32-bit platforms. Additionally, we improved the text on the need for a random number generator, more guidance on choosing the right platform, and why larger flash memory size is needed for firmware updates. We also removed some extraneous text from the background section. Any further comments are welcome.
> 
> --Mohit
> 
>

---

From: Mohit Sethi <[email-masked]>
Date: Sun, 6 Aug 2017 22:10:04 +0300

Hi Carsten

This document looks at a very specific deployment scenario where 
resource-constrained devices sign message objects. Therefore, it only 
documents the performance of ECDSA sign operation.

I do think the numbers of Elliptic curve diffie-hellman key agreement 
are useful for the community and the group should work on documenting 
them. I did discuss this with Tobias (off-the-mailing list) and perhaps 
those numbers can go in a separate document on minimal G-IKEv2. I 
currently have a working implementation of x25519 Diffie-hellman key 
agreement on a R Pi but I don't consider it constrained enough. Once I 
have more numbers, I will definitely contribute. But for now I strongly 
believe that they don't fit into the current document.

--Mohit

---

From: "Tobias Guggemos" <[email-masked]>
Date: Mon, 7 Aug 2017 15:36:24 +0200

Hey Mohit,
I see your point and that it is out of scope for the document. However, I feel the title and the abstract is then a bit misleading and should say that this document discusses security architectures and cryptographic functions for authentication/signing only?
Just a thought to avoid missunderstandings.
Regards
Tobias

-----Ursprüngliche Nachricht-----
Von: Lwip [mailto:[email-masked]] Im Auftrag von Mohit Sethi
Gesendet: Sonntag, 6. August 2017 21:10
An: Carsten Bormann <[email-masked]>
Cc: [email-masked]
Betreff: Re: [Lwip] WGLC for draft-ietf-lwig-crypto-sensors-03

Hi Carsten

This document looks at a very specific deployment scenario where resource-constrained devices sign message objects. Therefore, it only documents the performance of ECDSA sign operation.

I do think the numbers of Elliptic curve diffie-hellman key agreement are useful for the community and the group should work on documenting them. I did discuss this with Tobias (off-the-mailing list) and perhaps those numbers can go in a separate document on minimal G-IKEv2. I currently have a working implementation of x25519 Diffie-hellman key agreement on a R Pi but I don't consider it constrained enough. Once I have more numbers, I will definitely contribute. But for now I strongly believe that they don't fit into the current document.

--Mohit

---

From: Mohit Sethi <[email-masked]>
Date: Mon, 7 Aug 2017 19:20:11 +0300

Hi Tobias

The abstract does say that "The memo describes a possible deployment 
model suitable", the keyword being "a". I agree that the title is a bit 
broad but that is because in section 13 and 14, we discuss some broader 
trade offs of doing security at the different layers of the protocol 
stack. Perhaps the abstract could use text "The memo describes a 
possible deployment model where resource-constrained devices sign 
message objects, discusses the availability of cryptographic libraries 
for small devices". If you think this change is needed, I could update 
the draft and hopefully we don't have to do another last call for this 
minor fix.

--Mohit

---

From: "Tobias Guggemos" <[email-masked]>
Date: Tue, 8 Aug 2017 11:11:35 +0200

Hey,

I don't think this needs another last call, if we don't want to broaden the scope of the document.
I just feel that the proposed change would help to understand the actual scope of the document for a first-time-reader.
Your proposed text helps, but you can certainly keep the "experiences" part, I'd just state that the document presents experiences with signing:
The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for small device and presents some preliminary experiences with those libraries for signing operation on small devices.

Regards
Tobias

-----Ursprüngliche Nachricht-----
Von: Mohit Sethi [mailto:[email-masked]] 
Gesendet: Montag, 7. August 2017 18:20
An: Tobias Guggemos <[email-masked]>; Carsten Bormann <[email-masked]>
Cc: [email-masked]
Betreff: Re: AW: [Lwip] WGLC for draft-ietf-lwig-crypto-sensors-03

Hi Tobias

The abstract does say that "The memo describes a possible deployment model suitable", the keyword being "a". I agree that the title is a bit broad but that is because in section 13 and 14, we discuss some broader trade offs of doing security at the different layers of the protocol stack. Perhaps the abstract could use text "The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for small devices". If you think this change is needed, I could update the draft and hopefully we don't have to do another last call for this minor fix.

--Mohit

---

From: Mohit Sethi <[email-masked]>
Date: Tue, 8 Aug 2017 12:48:06 +0300

Hi Tobias

Your proposed text sounds good to me and I will update the document to 
reflect the changes suggested.

@Chairs: A procedural question; should I go ahead and submit another 
update as the deadline for last call is now over?

--Mohit

---

From: Zhen Cao <[email-masked]>
Date: Wed, 9 Aug 2017 08:42:10 +0800

Hi Mohit,

>From the discussion, the potential update is not substantial to the
key technique part of this document, it will be fine that we move the
new version to the next step.

BR,
Zhen

On Tue, Aug 8, 2017 at 5:48 PM, Mohit Sethi <[email-masked]> wrote:
> @Chairs: A procedural question; should I go ahead and submit another update
> as the deadline for last call is now over?
>
> --Mohit
>
>
>
>> I just feel that the proposed change would help to understand the actual
>> scope of the document for a first-time-reader.
>> Your proposed text helps, but you can certainly keep the "experiences"
>> part, I'd just state that the document presents experiences with signing:
>> The memo describes a possible deployment model where resource-constrained
>> devices sign message objects, discusses the availability of cryptographic
>> libraries for small device and presents some preliminary experiences with
>> those libraries for signing operation on small devices.
>>
>> Regards
>> Tobias
>>
>>
>> The abstract does say that "The memo describes a possible deployment model
>> suitable", the keyword being "a". I agree that the title is a bit broad but
>> that is because in section 13 and 14, we discuss some broader trade offs of
>> doing security at the different layers of the protocol stack. Perhaps the
>> abstract could use text "The memo describes a possible deployment model
>> where resource-constrained devices sign message objects, discusses the
>> availability of cryptographic libraries for small devices". If you think
>> this change is needed, I could update the draft and hopefully we don't have
>> to do another last call for this minor fix.
>>
>> --Mohit
>>
>>
>>> I see your point and that it is out of scope for the document. However, I
>>> feel the title and the abstract is then a bit misleading and should say that
>>> this document discusses security architectures and cryptographic functions
>>> for authentication/signing only?
>>> I do think the numbers of Elliptic curve diffie-hellman key agreement are
>>> useful for the community and the group should work on documenting them. I
>>> did discuss this with Tobias (off-the-mailing list) and perhaps those
>>> numbers can go in a separate document on minimal G-IKEv2. I currently have a
>>> working implementation of x25519 Diffie-hellman key agreement on a R Pi but
>>> I don't consider it constrained enough. Once I have more numbers, I will
>>> definitely contribute. But for now I strongly believe that they don't fit
>>> into the current document.
>>>
>>> --Mohit
>>>
>>>
>>>> For a deployment that relies on symmetric keys for mutual
>>>> authentication, it may be useful to do an (ECC) D-H key agreement to achieve
>>>> forward security.
>>>>> During the previous last call we had already received support from several
>>>>> working group members.
>>>>>
>>>>> performance measurements of RSA key sizes smaller than 2048 bits. We also
>>>>> added performance measurements of ECDSA sign operation on ARM 32-bit
>>>>> platforms. Additionally, we improved the text on the need for a random
>>>>> number generator, more guidance on choosing the right platform, and why
>>>>> larger flash memory size is needed for firmware updates. We also removed
>>>>> some extraneous text from the background section. Any further comments are
>>>>> welcome.
>>>>>
>>>>> --Mohit
>>>>>
>>>>>