[Lwip] Call for adoption of draft-bormann-lwig-7228bis

[Mohit Sethi]

Dear all:

This is a call for adoption of draft-bormann-lwig-7228bis 
(https://datatracker.ietf.org/doc/html/draft-bormann-lwig-7228bis) as a 
LWIG working group item. Please respond to this call and answer the 
following questions by 13th June, 2022:


1. Do you think this draft should be an LWIG working group Item?

2. Would you contribute by reviewing this document?

3. Would you contribute text to this document?

Please also let us know if you have objections/concerns regarding the 
adoption of this draft as a working group item.


Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Call for adoption of draft-bormann-lwig-7228bis

[Mohit Sethi]

Dear all:

No objections were raised during the call for adoption of 
draft-bormann-lwig-7228bis. Several members have volunteered to review 
and contribute.


Authors, please submit the draft as a working group document.

Zhen and Mohit

On 5/29/22 07:46, Mohit Sethi wrote:

Dear all:

This is a call for adoption of draft-bormann-lwig-7228bis 
(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-bormann-lwig-7228bis&data=05%7C01%7Csethim1%40aaltofi.mail.onmicrosoft.com%7C4708f5b5c3be4058dab708da412e3bcd%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C637893964387342567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=CAdDTRTa1h8rBHIg8pyET2anX7E3QJgpFmRvFO20z3A%3D&reserved=0) 
as a LWIG working group item. Please respond to this call and answer 
the following questions by 13th June, 2022:


1. Do you think this draft should be an LWIG working group Item?

2. Would you contribute by reviewing this document?

3. Would you contribute text to this document?

Please also let us know if you have objections/concerns regarding the 
adoption of this draft as a working group item.


Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flwip&data=05%7C01%7Csethim1%40aaltofi.mail.onmicrosoft.com%7C4708f5b5c3be4058dab708da412e3bcd%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C637893964387342567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=4V5ARdTla4mg3e6SNEfGKdIuk58BNgx%2FW6vNROMnhvA%3D&reserved=0 



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Fwd: New Version Notification for draft-sethi-gba-constrained-01.txt

[Mohit Sethi]

Hi

We have submitted a new draft on implementation experiences and 
guidelines for using Generic Bootstrapping Architecture (GBA) as a 
bootstrapping mechanism for Constrained devices. We have the necessary 
3GPP interfaces (NAF/BSF) for experimentation running on our public 
server (p133.piuha.net). Feel free to try it out with your own 
implementation.


Comments on the draft are welcome!

--Mohit


 Original Message 
Subject:New Version Notification for draft-sethi-gba-constrained-01.txt
Date:   Thu, 13 Feb 2014 00:42:19 -0800
From:   
To: 	Vesa Lehtovirta , Patrik Salmela 
, Vesa Lehtovirta 
, Mohit Sethi 
, Mohit Sethi , 
Patrik Salmela 




A new version of I-D, draft-sethi-gba-constrained-01.txt
has been successfully submitted by Mohit Sethi and posted to the
IETF repository.

Name:   draft-sethi-gba-constrained
Revision:   01
Title:  Using Generic Bootstrapping Architecture with Constrained 
Devices
Document date:  2014-02-13
Group:  Individual Submission
Pages:  18
URL:
http://www.ietf.org/internet-drafts/draft-sethi-gba-constrained-01.txt
Status: https://datatracker.ietf.org/doc/draft-sethi-gba-constrained/
Htmlized:   http://tools.ietf.org/html/draft-sethi-gba-constrained-01
Diff:   http://www.ietf.org/rfcdiff?url2=draft-sethi-gba-constrained-01

Abstract:
   This document discusses the use of the 3GPP Generic Bootstrapping
   Architecture (GBA) for authenticating and securing constrained
   devices.  While GBA re-uses the 3GPP credentials, it does not require
   mobile network access, such as LTE, but requires only IP
   connectivity.  Though building devices that employ GBA is obviously
   well known, this document specifically focuses on techniques
   necessary to minimize memory and energy consumption which is
   essential for constrained device networks.

  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat






smime.p7s
Description: S/MIME Cryptographic Signature
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Fwd: New Version Notification for draft-aks-lwig-crypto-sensors-00.txt

[Mohit Sethi]

Folks.

Here is a submission documenting our implementation experiences of 
public-key cryptography on 8-bit micro-controllers. The informational 
document also provides design patterns and guidelines for ensuring 
integrity protection and freshness of messages that might be helpful 
when deploying such devices in practice.


We look forward to your feedback. Lets try to keep the group active./

/--Mohit


 Forwarded Message 
Subject:New Version Notification for 
draft-aks-lwig-crypto-sensors-00.txt
Date:   Wed, 7 Oct 2015 03:28:46 -0700
From:   internet-dra...@ietf.org
To: 	Jari Arkko , Heidi-Maria Back 
, Heidi-Maria Back 
, Ari Keranen , 
Mohit Sethi , Jari Arkko 
, Mohit Sethi , Ari 
Keranen 




A new version of I-D, draft-aks-lwig-crypto-sensors-00.txt
has been successfully submitted by Ari Keranen and posted to the
IETF repository.

Name:   draft-aks-lwig-crypto-sensors
Revision:   00
Title:  Practical Considerations and Implementation Experiences in 
Securing Smart Object Networks
Document date:  2015-10-07
Group:  Individual Submission
Pages:  30
URL:
https://www.ietf.org/internet-drafts/draft-aks-lwig-crypto-sensors-00.txt
Status: https://datatracker.ietf.org/doc/draft-aks-lwig-crypto-sensors/
Htmlized:   https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-00


Abstract:
   This memo describes challenges associated with securing smart object
   devices in constrained implementations and environments.  The memo
   describes a possible deployment model suitable for these
   environments, discusses the availability of cryptographic libraries
   for small devices, presents some preliminary experiences in
   implementing small devices using those libraries, and discusses
   trade-offs involving different types of approaches.

  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Fwd: New Version Notification for draft-aks-lwig-crypto-sensors-00.txt

[Mohit Sethi]

Hi Carsten

Thanks for the quick comment. If you notice, this draft has a lot of 
text that was written even before ACE was formed. The idea is not to 
suggest a new authorization architecture to ACE but rather show what 
implementers can already do today with existing libraries. It also talks 
about provisioning and message freshness that are not really in scope of 
ACE.


You are right about the curves though. The point was to show that the 
asymmetric crypto is possible on resource-constrained devices. The 
numbers of-course vary with the curve and platform chosen. I would like 
to include more numbers for some modern curves on similar platforms, 
such as those from Dull et al. (https://eprint.iacr.org/2015/343.pdf) in 
the next version.
But I was hoping that this would serve as a placeholder for others in 
LWIP to contribute with their numbers so that we and others in the 
community can learn from our experiences.


I hope this answers your concerns to some extent and look forward to a 
more detailed feedback.


/--Mohit




On 10/12/2015 01:28 PM, Carsten Bormann wrote:

Hi Mohit,

the draft contains a lot of information, thank you for that.

I'm just not so sure what to do with it in LWIG.

There is some information about a potential security architecture.
I would expect to discuss this in ACE, as it's not particularly about
implementation.

There is some information about crypto libraries for constrained
devices.  Some of it is about RSA, some of it for older ECC curves.
I didn't find anything about P-256 (CoAP's current MTI curve) or the
25519 curves, which are the more likely ones to be used going forward.

So I'm wondering a bit what an implementer of IETF IoT protocols can
take home specifically here.

Grüße, Carsten


Mohit Sethi wrote:

Folks.

Here is a submission documenting our implementation experiences of
public-key cryptography on 8-bit micro-controllers. The informational
document also provides design patterns and guidelines for ensuring
integrity protection and freshness of messages that might be helpful
when deploying such devices in practice.

We look forward to your feedback. Lets try to keep the group active./

/--Mohit


 Forwarded Message 
Subject: New Version Notification for
draft-aks-lwig-crypto-sensors-00.txt
Date: Wed, 7 Oct 2015 03:28:46 -0700
From: internet-dra...@ietf.org
To: Jari Arkko , Heidi-Maria Back
, Heidi-Maria Back
, Ari Keranen ,
Mohit Sethi , Jari Arkko
, Mohit Sethi , Ari
Keranen 



A new version of I-D, draft-aks-lwig-crypto-sensors-00.txt
has been successfully submitted by Ari Keranen and posted to the
IETF repository.

Name:draft-aks-lwig-crypto-sensors
Revision:00
Title:Practical Considerations and Implementation Experiences in
Securing Smart Object Networks
Document date:2015-10-07
Group:Individual Submission
Pages:30
URL:
https://www.ietf.org/internet-drafts/draft-aks-lwig-crypto-sensors-00.txt
Status:
https://datatracker.ietf.org/doc/draft-aks-lwig-crypto-sensors/
Htmlized:
https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-00


Abstract:
This memo describes challenges associated with securing smart object
devices in constrained implementations and environments.  The memo
describes a possible deployment model suitable for these
environments, discusses the availability of cryptographic libraries
for small devices, presents some preliminary experiences in
implementing small devices using those libraries, and discusses
trade-offs involving different types of approaches.

  



Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Fwd: New Version Notification for draft-aks-lwig-crypto-sensors-01.txt

[Mohit Sethi]

Dear all,

We have uploaded the next version of our draft documenting the 
implementation experiences of public-key cryptography on 8-bit 
micro-controllers. The draft is available here:

https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-01

In this updated version, we have included the implementation results 
from the performance analysis of Ed25519 (the crypto forum research 
group is currently specifying the recommended parameters) signature 
generation on the same 8-bit micro-controller.


The informational document also provides design patterns and guidelines 
for ensuring integrity protection and freshness of messages that might 
be helpful when deploying such devices in practice.


We look forward to your feedback. We also request the chairs to allocate 
a short slot (10/12 mins) for presenting this updated version.


Thanks
/--Mohit


 Forwarded Message 
Subject:New Version Notification for 
draft-aks-lwig-crypto-sensors-01.txt
Date:   Thu, 30 Jun 2016 02:48:04 -0700
From:   internet-dra...@ietf.org
To: 	Mohit Sethi , Heidi-Maria Back 
, Jari Arkko , Ari 
Keranen 




A new version of I-D, draft-aks-lwig-crypto-sensors-01.txt
has been successfully submitted by Mohit Sethi and posted to the
IETF repository.

Name:   draft-aks-lwig-crypto-sensors
Revision:   01
Title:  Practical Considerations and Implementation Experiences in 
Securing Smart Object Networks
Document date:  2016-06-30
Group:  Individual Submission
Pages:  31
URL:https://www.ietf.org/internet-drafts/draft-aks-lwig-crypto-sensors-01.txt
Status:https://datatracker.ietf.org/doc/draft-aks-lwig-crypto-sensors/
Htmlized:https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-01
Diff:https://www.ietf.org/rfcdiff?url2=draft-aks-lwig-crypto-sensors-01

Abstract:
   This memo describes challenges associated with securing smart object
   devices in constrained implementations and environments.  The memo
   describes a possible deployment model suitable for these
   environments, discusses the availability of cryptographic libraries
   for small devices, presents some preliminary experiences in
   implementing small devices using those libraries, and discusses
   trade-offs involving different types of approaches.

  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Fwd: New Version Notification for draft-aks-lwig-crypto-sensors-01.txt

[Mohit Sethi]

Hi Zhen

Thanks for the feedback.

We have previously ported Brian Gladman's byte-oriented AES code 
http://www.gladman.me.uk/AES <https://github.com/abhay/gladman-aes> to 
the same 8-bit platform.


We were able to perform AES encryption and decryption with very little 
amount of RAM consumption (< ~2kB) and minimal execution time.


Hope this info is useful. We look forward to further feedback.

Thanks
/--Mohit


On 07/01/2016 05:47 AM, Zhen Cao wrote:

Hi Mohit ,

Nice draft with a lot of reference data

one quick question: do you have any data around AES/tinyAES, and DTLS
memory footprint?

Many thanks,
Zhen

On Thu, Jun 30, 2016 at 6:11 PM, Mohit Sethi  wrote:

Dear all,

We have uploaded the next version of our draft documenting the
implementation experiences of public-key cryptography on 8-bit
micro-controllers. The draft is available here:
https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-01

In this updated version, we have included the implementation results from
the performance analysis of Ed25519 (the crypto forum research group is
currently specifying the recommended parameters) signature generation on the
same 8-bit micro-controller.

The informational document also provides design patterns and guidelines for
ensuring integrity protection and freshness of messages that might be
helpful when deploying such devices in practice.

We look forward to your feedback. We also request the chairs to allocate a
short slot (10/12 mins) for presenting this updated version.

Thanks
/--Mohit


 Forwarded Message 
Subject:New Version Notification for
draft-aks-lwig-crypto-sensors-01.txt
Date:   Thu, 30 Jun 2016 02:48:04 -0700
From:   internet-dra...@ietf.org
To:     Mohit Sethi , Heidi-Maria Back
, Jari Arkko , Ari
Keranen 



A new version of I-D, draft-aks-lwig-crypto-sensors-01.txt
has been successfully submitted by Mohit Sethi and posted to the
IETF repository.

Name:   draft-aks-lwig-crypto-sensors
Revision:   01
Title:  Practical Considerations and Implementation Experiences in
Securing Smart Object Networks
Document date:  2016-06-30
Group:  Individual Submission
Pages:  31
URL:https://www.ietf.org/internet-drafts/draft-aks-lwig-crypto-sensors-01.txt
Status:https://datatracker.ietf.org/doc/draft-aks-lwig-crypto-sensors/
Htmlized:https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-01
Diff:https://www.ietf.org/rfcdiff?url2=draft-aks-lwig-crypto-sensors-01

Abstract:
This memo describes challenges associated with securing smart object
devices in constrained implementations and environments.  The memo
describes a possible deployment model suitable for these
environments, discusses the availability of cryptographic libraries
for small devices, presents some preliminary experiences in
implementing small devices using those libraries, and discusses
trade-offs involving different types of approaches.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] draft-aks-lwig-crypto-sensors-00 & Crypto Performance

[Mohit Sethi]

Hi Hannes

Please see  the responses inline.

On 07/25/2016 07:23 AM, Hannes Tschofenig wrote:

I have a question regarding draft-aks-lwig-crypto-sensors-00.

Table 2 shows ECDSA signature performance with TinyECC. The execution
time in the first row says 1,858 msec. A different writing style for
numbers and use the comma (either '.', or ',') is used throughout the
world. Hence, I guess you mean almost 2 seconds here rather than almost
2 msecs. Right?
Agree. The numbers can be made more readable and less ambiguous. We will 
do so in the next submitted version.


When I read the performance figures then my impression is that the used
hardware isn't really fit to do any practical crypto for IoT devices.
What is the message you want to convey to the reader? I fear that such a
write-up could easily be misunderstood. You may want to provide a bit
more info about why you have chosen this hardware platform particularly
since it is not able to fit most of the stuff we have developed in other
working groups due to the low RAM and flash.
If you have a look at section 11 on feasibility, we have text describing 
why we picked this platform: "It could even be argued that our chosen 
prototype platform was unnecessarily restrictive in the amount of code 
space it allows: we chose this platform on purpose to demonstrate 
something that is as small and difficult as possible."
This platform (Arduino Mega) has also been chosen by many other 
researcher/cryptographers to show feasibility of public-key crypto on 
small devices for example:

http://link.springer.com/article/10.1007/s10623-015-0087-1/fulltext.html

http://link.springer.com/chapter/10.1007/978-3-642-38553-7_9

And if you read the document (section 9: Example Application), we not 
only implement CoAP on the same platform, but a complete application 
that reads temperature measurement, performs crypto, and sends messages 
over CoAP + UDP etc. All this in about 5000 bytes of RAM. So we disagree 
that it is not able to fit most of the stuff developed at the IETF.


The currently recommended key size for IoT devices is (based on various
other IETF documents) 112 bit symmetric keys ~ 233 bit ECC keys ~ 2048
DH/RSA keys.

Hence, publishing performance results for very low, impractical key
sizes is misleading since we do not recommend them to be used at all.
Hence, I would delete any data below 192r1 (for ECC) and maybe even
192r1 as well. You include, for example, the RSA algorithm with a key
size of 64 bits.
According to some, all the public key crypto will soon be broken (so we 
should remove all the numbers from the draft) and we should move to 
Quantum resistant crypto (note that this is not my opinion). I agree 
that some of the curves are not secure anymore and perhaps we can point 
it out even more explicitly. But the reason for providing performance 
numbers on all the curves and key sizes is to provide a perspective. The 
text currently does say that " At the time of performing these 
measurements and study, it was unclear which exact elliptic curve(s) 
would be selected by the IETF community for use with 
resource-constrained devices." We will make it even more explicit in the 
next version.


Do you have any other concerns which think we should address for working 
group adoption?


Thanks
/--Mohit


Ciao
Hannes




___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Review of draft-ietf-lwig-energy-efficient-05

[Mohit Sethi]

Dear all

The chair has asked me to do the shepherd write up for 
draft-ietf-lwig-energy-efficient-05.


I have gone through the document again and I have some comments that I 
think should be addressed first. Most of them are minor and editorial in 
nature. It would be great if the authors can fix them quickly (possibly 
by next week?). I will then submit my writeup. Here are the list of issues:


1. The abstract is little hard to read and understand. Here is an 
alternative suggestion:


This document describes the challenges for energy-efficient protocol 
operation on constrained devices and the current practices used to 
overcome those challenges.  It summarizes the main link-layer techniques 
used for energy-efficient networking, and it highlights the impact of 
such techniques on the upper layer protocols so that they can together 
achieve an energy efficient behavior.  The document also provides an 
overview of energy-efficient mechanisms available at each layer of the 
IETF protocol suite specified for constrained node networks.


2. Please check the spacing between the term and its citation. "The IETF 
has developed a suite of Internet protocols suitable for such 
constrained devices, including 6LoWPAN ([RFC6282 
],[RFC6775 
],[RFC4944 
]), RPL[RFC6550], and 
CoAP[I-D.ietf-core-coap]." For example, RPL[RFC6550] should by 
RPL_space_[RFC6550].


3. Typo in the following text. "This document tries to summarize the 
design considerations of making the IETF contrained protocol suite as 
energy-efficient as possible." First, "contrained" should be 
"constrained". Replace "of" with "for" so the text would be: "summarize 
the design consideration *for* making the IETF constrained".


4. Perhaps tone down the wording here, especially the word 
"comprehensive": "it provides a comprehensive overview of the techniques 
used by the lower layers to save energy and how these may impact on the 
upper layers"


5. It is generally a good practice to expand all acronyms once before 
you use them in the document. For example in Section 2 "Overview", 
currently RPL is used without ever expanding the term and there is no 
citation.


6. Please explain what are atom operations and common atom operations.

7. What are UWB links? Again an acronym is used with no expansion or 
citation.


8. Section 3.1 "Radio Duty Cycling techniques" typo: "Receiver Initated 
Transmission (RIT)" should be "Receiver Initiated Transmission (RIT)"


9. Section 3.5.2, please expand TDMA, 3.5.3 please expand PAN, CSMA, CA.

10. In section 3.5.3, it says "6TiSCH working group has been recently 
created". Perhaps this is text leftover from old versions. 6TiSCH is no 
longer recently created?


11. Section 6.2, "none of these proposal has been adopted by the CoRE 
working group". This is also old information now. The pub sub draft has 
been adopted. Perhaps you also want to cite the other LWIG document that 
talks about sleepy nodes: 
https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-01


12. Section 7: please replace "synergize" with another term more 
appropriate. "lower layer other than treating the lower layer as a black 
box" should be "lower layer rather than treating the lower layer as a 
black box".


13. Typos in Section 7: "compresss" should be "compress" and 
"non-sychronzed" should be "non-synchronized".


Overall, thanks for the useful draft. I hope that you can quickly 
address the comments so that it can move forward.


--Mohit


smime.p7s
Description: S/MIME Cryptographic Signature
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] I-D Action: draft-ietf-lwig-crypto-sensors-02.txt

[Mohit Sethi]

Dear all

We have submitted the next version of the working group document 
"draft-ietf-lwig-crypto-sensors". The next version can be found here: 
https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02


The draft has mostly undergone minor changes since the last IETF. We 
have addressed the comments received from Carsten and others, as well as 
updated the outdated references.


Feedback and further comments are welcome.

Thanks
Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

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

[Mohit Sethi]

Hi Hannes

I had refrained from responding earlier because there was an ongoing 
discussion about this draft within the IoT directorate. I wanted to wait 
for it to conclude before responding. But in any case, here is my response:


This is how you want to solve the IoT security problem:
Use ARM chips -> Run the mbed OS -> Use TLS/DTLS only for security -> 
add Trustzone based attestation for some extra features.


Since we already have these tools in place, IoT security is solved and 
we should all move on. Unfortunately, while you may choose to close your 
eyes and ignore reality, others can't. The fact is that other 
platforms/protocols/OS exist, are needed and are used by folks out there.


At no point do we suggest in the draft that using bad curves and small 
key sizes is good. In fact, I have said it earlier and I say it again, I 
am totally ok with removing the numbers for RSA key sizes less than 
2048-bits. Recently in the ACE working group (for which you are 
co-chair) there was a suggestion from M St. Johns that 1024-bit RSA 
might perform better than ECDSA at similar security levels: 
https://mailarchive.ietf.org/arch/msg/ace/znba10pRL5c3D1aa9_azz9uyeAM. 
The numbers in our draft came in handy to show that it is not the case 
on the platform tested. The numbers are in the draft only for reference 
(and can be removed).


At no point is it suggested that you shouldn't do software updates for 
your IoT devices. In fact this draft is talking about public-key crypto 
on IoT devices. You would typically use some signature verification for 
firmware and software updates. If I write a draft on performance of 
HTTP, would you ask me whether my machine had software updates or not? 
The draft does not try to build a product. At least not this draft.


The draft also clearly recommends you to choose a 32-bit platform. We 
simply show that if you can do public-key crypto on an 8-bit platform, 
you can do it much faster and more efficiently on a 32-bit platform:



A recent trend in microcontrollers
is the introduction of 32-bit CPUs that are becoming cheaper and more
easily available than 8-bit CPUs, in addition to being more easily
programmable.


I am fine with removing the numbers that you don't like. But in 
principle I like drafts that actually implement something than the other 
high-level so-called "guidance" documents.


Regarding the stack, the draft does say that we use an ATmega2560 board, 
on which we implement message signing with public-key cryptography, 
CoAP, DHCP, UDP, IP, Ethernet. Yes, all this in less than 8 kB of RAM. 
And no, we don't say that this is enough for a real product. You would 
need more memory in a real product because you will have other things 
such as software updates etc. and other favorite features.


If you have suggestions on how the text can be rephrased better, I am 
more than open to feedback.


Thanks
Mohit
On 03/09/2017 01:21 PM, Hannes Tschofenig wrote:

Hi Zhen,

thanks for the quick response.

Here is how I read the document: Many years ago we played around with
some hardware, which happened to be in the office. We ran some security
tests and the results for state-of-the-art crypto was extremely slow.
Hence, we added other performance measurements using key length that
nobody would be able to use. Then, it looked much better.

All security recommendations I have read suggest to use 112-bits+ keys
for modern implementations.

Regarding your question:


Is this 112 bits of symmetric encryption mandatory for even tiny
devices?

A clear "yes" also for tiny IoT devices.

What I am still missing is a response to my question about the actual
software stack being used on that device.

Ciao
Hannes

On 03/09/2017 11:02 AM, Zhen Cao wrote:

Hi Hannes,

Thanks for the frank points, which are helpful to make documents more
impactful.  Please see my discussion in-line.

On Mon, Mar 6, 2017 at 9:36 PM, Hannes Tschofenig
mailto:hannes.tschofe...@gmx.net>> wrote:

 Hi all,

 as I mentioned in the past I consider this document problematic.

 The selected hardware gives the impression that IoT devices need very
 low requirements. This gives inexperienced readers the wrong impression.


I do not think this leads to any incorrect impressions.  It clearly
states the platform that this work has been carried out, and by informed
selection of crypto libraries, security functions can be enabled on such
IoT devices.  It's much better than the other opposite impression that
security is costly and could be avoid as far as we can.


 At no point in the document it explains why a typical software stack
 required for an IoT device would fit on hardware that has 2 kB of SRAM,
 and 32 kB of flash memory. What did you put on that device? (CoAP, DTLS,
 Resource Directory, SENML -- protocol talk about in Section 9) I suspect
 that there is no firmware update mechanism in place, which is a
 typically demanded feature for IoT devices in order t

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

[Mohit Sethi]

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  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
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

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

[Mohit Sethi]

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


On 08/06/2017 02:39 PM, Carsten Bormann wrote:

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


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  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
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

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

[Mohit Sethi]

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


On 08/07/2017 04:36 PM, Tobias Guggemos wrote:

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:lwip-boun...@ietf.org] Im Auftrag von Mohit Sethi
Gesendet: Sonntag, 6. August 2017 21:10
An: Carsten Bormann 
Cc: lwip@ietf.org
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


On 08/06/2017 02:39 PM, Carsten Bormann wrote:

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


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  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
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

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

[Mohit Sethi]

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


On 08/08/2017 12:11 PM, Tobias Guggemos wrote:

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:mohit.m.se...@ericsson.com]
Gesendet: Montag, 7. August 2017 18:20
An: Tobias Guggemos ; Carsten Bormann 
Cc: lwip@ietf.org
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


On 08/07/2017 04:36 PM, Tobias Guggemos wrote:

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:lwip-boun...@ietf.org] Im Auftrag von Mohit Sethi
Gesendet: Sonntag, 6. August 2017 21:10
An: Carsten Bormann 
Cc: lwip@ietf.org
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


On 08/06/2017 02:39 PM, Carsten Bormann wrote:

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


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 

[Lwip] Fwd: I-D Action: draft-ietf-lwig-crypto-sensors-04.txt

[Mohit Sethi]

Hi all

This new version incorporates comments and text from Tobias. Thank you.

--Mohit



 Forwarded Message 
Subject:[Lwip] I-D Action: draft-ietf-lwig-crypto-sensors-04.txt
Date:   Wed, 09 Aug 2017 03:54:00 -0700
From:   internet-dra...@ietf.org
To: i-d-annou...@ietf.org
CC: lwip@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Light-Weight Implementation Guidance WG of the 
IETF.

Title   : Practical Considerations and Implementation 
Experiences in Securing Smart Object Networks
Authors : Mohit Sethi
  Jari Arkko
  Ari Keranen
  Heidi-Maria Back
Filename: draft-ietf-lwig-crypto-sensors-04.txt
Pages   : 31
Date: 2017-08-09

Abstract:
   This memo describes challenges associated with securing resource-
   constrained smart object devices.  The memo describes a possible
   deployment model where resource-constrained devices sign message
   objects, discusses the availability of cryptographic libraries for
   small devices and presents some preliminary experiences with those
   libraries for message signing on small devices.  Lastly, the memo
   discusses trade-offs involving different types of security
   approaches.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lwig-crypto-sensors/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-04
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-crypto-sensors-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-crypto-sensors-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] The LWIG WG has placed draft-gomez-lwig-tcp-constrained-node-networks in state "Call For Adoption By WG Issued"

[Mohit Sethi]

Hi

I have read this draft. I find this draft relevant for the working 
group. I was happy to see in the presentation during IETF 99 on how the 
different constrained OS implement the TCP stack.


+1 for adoption call.

--Mohit
On 08/11/2017 11:34 AM, IETF Secretariat wrote:

The LWIG WG has placed draft-gomez-lwig-tcp-constrained-node-networks in state
Call For Adoption By WG Issued (entered by Zhen Cao)

The document is available at
https://datatracker.ietf.org/doc/draft-gomez-lwig-tcp-constrained-node-networks/

Comment:
The document has received sufficient support of adoption at both IETF98 and
IETF99 meetings.  The document has got many reviews with comments and
questions, which is good because many people care.  The call would like to
confirm that this document is heading at the right direction, and can be
served as the basis for future work.

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] The LWIG WG has placed draft-jadhav-lwig-nbr-mgmt-policy in state "Call For Adoption By WG Issued"

[Mohit Sethi]

Hi all

I have read a previous version of this draft. The draft has already 
provided useful input to the neighbor discovery work ongoing in 6lo.


I believe this work is relevant for the working group. +1 for the 
adoption call.


--Mohit
On 08/11/2017 12:49 PM, IETF Secretariat wrote:

The LWIG WG has placed draft-jadhav-lwig-nbr-mgmt-policy in state
Call For Adoption By WG Issued (entered by Zhen Cao)

The document is available at
https://datatracker.ietf.org/doc/draft-jadhav-lwig-nbr-mgmt-policy/

Comment:
This document has been presented at IETF98 and IETF99.  The adoption poll was
conducted at IETF99, Prague, where the consensus was quite clear.   This call
would like to confirm the consensus at the meeting.   (Note: minutes of
IETF99 have indicated that the proactive neighbor management which
necessitates protocol changes will be not discussed in this document).

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Secdir early review of draft-ietf-lwig-crypto-sensors-04

[Mohit Sethi]

Dear Christian,

Thanks for the detailed review and positive comments. We have now 
submitted an updated version which can be found here: 
https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-05. The diff 
from the previous version can be found here: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-crypto-sensors-05.


You had raised an important point about identifiers and privacy. To 
address this, we have added new text in section 3 (Challenges), section 
4.1 (Provisioning) and section 8.1 (Feasibility). I provide snippets of 
the added text here for your convenience:



small resource-constrained devices
are often shipped with a single static identity.  In many cases, it
is a single raw public key.  These long-term static identities makes
it easy to track the devices (and their owners) when they move.  The
static identities may also allow an attacker to track these devices
across ownership changes.
long-term static identities
negatively affect the privacy of the devices and their owners.
Therefore, it is beneficial for devices to generate new identities at
appropriate times during their lifecycle.  For example, after a
factory reset or an ownership handover.  Thus, in our proposed
deployment model, the devices would generate a new asymmetric key
pair and use the new public-key P' to generate the new identity I'.
It is also desirable that these identities are only used during the
provisioning stage.  Temporary identities (such as IPv6 addresses)
can be used for network communication protocols once the device is
operational.
  we
did note that it is possible for such devices to generate a new key
pair.  Given that this operation would only occur in rare
circumstances (such as a factory reset or ownership change) and its
potential privacy benefits, developers should provide mechanisms for
generating new identities.  It is however extremely important to note
that the security of this operation relies on access to
cryptographic-quality randomness.


Let us know if the ideas or the text here is not sufficient.

--Mohit
On 10/15/2017 07:38 PM, Christian Huitema wrote:

Reviewer: Christian Huitema
Review result: Has Nits

This is an early review of draft-ietf-lwig-crypto-sensors-04 on behalf of the 
Security Directorate.

The document is almost ready, but would benefit from a bit more further work.

This draft examines a series of risks and challenges posed by securing small 
devices,
proposes solutions for provisioning, and an architecture for securing the 
devices.
The implementation experience section (section 8) provides measurements for the
memory and CPU costs of various cryptographic operations using the Arduino
platform. It will be good to see these results published and become a useful
reference in further debates. In fact, I like this document a lot. My only
concern is that it misses an opportunity to discuss identifiers and privacy.
  
I like the discussion of platform constraints in section 3, and the statement that "at

the end of the day, if strong cryptographic security is needed, the 
implementations
have to support that." I think it is an important message, and it it might be
good to reinfore it with examples. For example, we do ship medecine in 
child-proof
containers. It would be cheaper to use ordinary containers, but we pay the cost
because as a society we want to mitigate the risk of children mistaking pills 
for candy.
Similarly, it is cheaper to build devices with no security, but we may want 
society
to mandate that risks should be mitigated.

The challenge section, and the document in general, would be even better if it 
included
a discussion of identifiers and privacy. The general concern is that because 
small
devices have limited resource, they end up using just one identity, maybe just 
one
public key. This makes them easy to track when they move, and by extension 
track the
movements of their owners for wearable devices, or associated objects such as 
cars for
general devices. There are certainly mitigations, such as provisioning new 
identities
at appropriate times, or using temporary identities in communication protocols, 
but
these mitigations certainly require the kind of trade-offs discussed in the 
draft. It
would thus be very nice to introduce the privacy challenges in the "challenge"
section, and to discuss the privacy mitigations in the other sections, e.g., 
architecture
and provisioning.









smime.p7s
Description: S/MIME Cryptographic Signature
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Intdir early review of draft-ietf-lwig-crypto-sensors-04

[Mohit Sethi]

Dear Tim,

Thanks for the detailed review and positive comments. We have now 
submitted an updated version which can be found here: 
https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-05. The diff 
from the previous version can be found here: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-crypto-sensors-05.


Please find our responses to your specific comments inline. Let us know 
if the modifications are not sufficient.


--Mohit
On 10/30/2017 12:03 AM, Tim Chown wrote:

Reviewer: Tim Chown
Review result: Ready

Hi,

This Informational draft describes the challenges in securing
resource-constrained smart object / IoT devices, documenting the associated
tradeoffs, and discussing the availability of appropriate cryptographic
libraries for such devices.

I have reviewed this document, and overall find it generally ready for
publication, though I have some minor nits / comments for consideration below;
these are just suggested changes / improvements, and I would not object
strongly if all were ignored.

General comments:

The document is very easy and enjoyable to read, and the quality of the writing
is very good.  The authors have clear expertise in the field.

It may be worth considering teasing apart the evaluation and the architectural
aspects of the document; these are somewhat interwoven as currently written.

Related, there are some rather nice recommendations made throughout the
document; these could perhaps be summarised either at the start or perhaps
better the close of the document, e.g. on page 4 regarding selecting the
hardware after determining the security requirements for a device, and not
necessarily simply picking the most lightweight algorithm, or on page 7
regarding appropriate layers for tasks, or on page 9 regarding elliptic curve
vs RSA, or on page 11 on real deployments using 32-bit microcontrollers, or the
recommendation to the IETF community on page 14, or on planning for firmware
updates on page 16, etc.
We have now added a summary of important security recommendations from 
our implementation experience in section 9.


Comments by page:

On page 5, in the first paragraph on provisioning, there is no hint of any
bootstrap process for identities; this follows later on page 6, but a hint
here, or just adding "as discussed on page 6 or in section x.y" might be nice.

Also on page 5, I'd be interested in seeing some brief text added on the
"remaining vulnerabilities" that are mentioned near the foot of the page.
We have added new text here. "leap-of-faith or trust-on-first-use based 
pairing methods assume that the attacker is not present during the 
initial setup and are vulnerable to eavesdropping or man-in-the-middle 
(MitM) attacks."


On page 6, is it worth adding a little text on privacy somewhere?  We've been
doing some work through Christian Huitema and Daniel Kaiser on anonymous device
pairing in the DNSSD WG, and a similar requirement might be desirable in some
scenarios here?
Christian had provided detailed feedback on privacy and identifiers. To 
address this, we have added new text in section 3 (Challenges), section 
4.1 (Provisioning) and section 8.1 (Feasibility).


On page 7, having said earlier you should pick the hardware after determining
requirements, you then decide to pick an Arduino platform and see what you can
manage to run on it. I fully understand why (and I'd be equally curious), but
you should probably clarify the "conflict" further.
There was missing text here. We have now completed the sentence. "Our 
choice of a 8-bit platform may seem surprising since cheaper and more 
energy-efficient 32-bit platforms are available. However, our intention 
was to evaluate the performance of public-key cryptography on the 
smallest platforms available. It is reasonable to expect better 
performance results from 32-bit microcontrollers.


On page 12, would a little more detail on RNG requirements, esp. for devices of
this type, be worthwhile?
We have also added a pointer to RFC4086 that provides a detailed 
discussion on requirements and best practices for cryptographic-quality 
randomness.


On page 16, you're hardcoding the IP address?  Is it not possible to use RD?
We've been comparing that and looking at interoperability with classic DNSSD in
the DNSSD WG.
The IP address of the resource-directory was hardcoded. The location of 
the publish-subscriber broker was then discovered from the resource 
directory. I should also add that this was a prototype implementation on 
a small device. A real deployment would have used an actual domain name.


On page 16, section 10 seems to have no content?  Or should sections 11 onwards
be subsections of section 10?
Section 10, 11, 12, 13, 14 were related but somehow incorrectly placed. 
This was an xml formatting error on our part. We have now fixed 
section/subsection order.


On page 17, at the end of section 11, should there also be some 'spin up' costs
for the radio?
Added. "in general the power requirements necessar

Re: [Lwip] Iotdir early review of draft-ietf-lwig-crypto-sensors-04

[Mohit Sethi]

Dear Samita,

Thanks for the detailed review and positive comments. We have now 
submitted an updated version which can be found here: 
https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-05. The diff 
from the previous version can be found here: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-crypto-sensors-05.


Please find our responses to your specific comments inline. Let us know 
if the modifications are not sufficient.


--Mohit

On 11/06/2017 11:37 AM, Samita Chakrabarti wrote:

Reviewer: Samita Chakrabarti
Review result: Ready with Nits

I have reviewed draft-ietf-lwig-crypto-sensors-04 document for  IOT-Directorate
review. The following are my comments:

General : The document is easy reading and informative about current and
previous work. It is ready to publish with minor changes based on review
comments.

Other comments:
Introduction:
  It might be useful to discuss/clarify that multi-level security may be
  important for IOT devices  all the way from 'bootstrapping and management' to
  application security. That perhaps can include obtaining IP-addresses
  securely, mutual authentication between server and devices , etc. ( see
  https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-03) in those cases where each
  device has an IP address.
You rightly point out that security is important at all the different 
stages in the lifecycle of an IoT device. The Thing-to-thing Research 
Group (T2TRG) has a security considerations document 
(https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons-09) that 
discusses the different stages in the lifecycle and reviews the possible 
security threats. We reference this document in the related work 
section. We have modified the text to better highlight this.


Section 2:
Regarding problems of provisioning and management of networks for the IOT
devices there may be additional issues – 1) different types of IOT devices and
the lack of standards way to provision them as they might be talking different
RF technologies and running L2 protocols only. 2) The iot nodes may be moving
individually or collectively and change networks; identifying the movement of
the iot nodes or identifying a particular node at any point of time uniquely
requires an intrinsic identification which might be useful to set during
bootstrapping of the node

Regarding related work – does it consider IETF IOT security work only? There
have been some work and thought process going on regarding blockchain IOT
security in the industry. Perhaps that is out-of-scope of this document, but I
wanted to mention for authors’ considerations.


Section 5:
Authors of the document may also want to browse a SRAM PUF based technology
which provides unique ID based authentication mechanism.
https://www.intrinsic-id.com/intrinsic-id-joins-wi-sun-alliance/
Our focus in this document is mostly on IETF IoT security work. You 
correctly pointed out that there are many L2 protocols and they might 
use different provisioning methods.This can be challenge. Therefore we 
have added a new bullet in section 3. I provide the relevant text here 
for your convenience: "Smart object networks may rely on different radio 
technologies. Provisioning methods that rely on specific link-layer 
features may not work with other radio technologies in a heterogeneous 
network.".


Identifying nodes or networks as they move can be seen as a requirement 
or an invasion of privacy, depending on the application scenario. Based 
on security directorate feedback on privacy of identifiers from 
Christian Huitema, we added this text: "small resource-constrained 
devices are often shipped with a single static identity.  In many cases, 
it is a single raw public key.  These long-term static identities makes 
it easy to track the devices (and their owners) when they move. The 
static identities may also allow an attacker to track these devices 
across ownership changes.".

Section 9:
Does the example simulate any particular deployment model or research
experiments ? It might be good to clarify that. Section 10 and 11: Looks like
section 11 is closely related to section 10. Should they be combined together ?
Else some more text is needed in section 10 on design trade-offs.
Section 10, 11, 12, 13, 14 were related but somehow incorrectly placed. 
This was an xml formatting error on our part. We have now fixed 
section/subsection order.


We do rely on a particular deployment model in our experiments. This is 
documented in section 4 and 7. I provide the relevant text snippet here 
for your convenience: "The security of this system relies on an SSH-like 
approach. In Step 1, upon first boot, sensors generate keys and register 
themselves in the publish-subscribe broker. Their public key is 
submitted along with the registration as an attribute in the CORE Link 
Format data [RFC6690]."


Section 13:
Does this document recommend one layer of security to IOT devices ? There are
different types of IOT devices – some of them are very tiny and so

[Lwip] Presentation slot for IETF 101

[Mohit Sethi]

Dear all,

Please let Zhen and I know if you want a presentation slot during the 
LWIG session at IETF 101 in London.


Don't forget to include the title of your presentation, related drafts, 
and the approximate amount of time that you need.


Also, please let us know if you plan to present remotely.

The earlier, the better. :)

--Mohit




smime.p7s
Description: S/MIME Cryptographic Signature
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Fwd: I-D Action: draft-ietf-lwig-crypto-sensors-06.txt

[Mohit Sethi]

Dear all,

Thanks to all the feedback from the directorates as well as the IESG. We 
have now updated the draft based on the feedback received. There were no 
major changes and a list of all the issues fixed can be found below. 
This feedback has greatly helped us to improve the final version of the 
document. Hopefully, it has also made the job of the RFC editor easy.


--Mohit, Jari, Ari and Heidi

- Update acknowledgments section with all the reviewers.
- Added a bullet in section 9 (Summary) stating that developers should 
provide mechanisms for devices to generate new identities. (Christian 
Huitema)

- Expanded first use of ECDSA. (Dan Romascanu)
- Uniformly use "resource-constrained" instead of small devices. (Dan 
Romascanu)
- Add a sentence on how a real implementation would find the resource 
directory. (Dan Romascanu)
- "physically different" replaced with "physically distinct" in section 
7. (Spencer Dawkins)

- Fixed typo in Section 6 "results for for all the 128". (Emmanuel Baccelli)
- Rephrased the bullet on cryptographic-quality randomness on Arduino 
(Emmanuel Baccelli)

- Explicit mention of what is n and m in section 4.1. (Emmanuel Baccelli)
- Separate OS from cryptographic libraries and cite survey on OS for 
resource-constrained devices. (Emmanuel Baccelli)
- Fixed typo in Section 7 "enough power to be stay on". (Kathleen 
Moriarty and Emmanuel Baccelli)

- Fix missing article before "CoAP base specification". (Ben Campbell)
- Rephrased "Once both peers..." in section 4.1. (Ben Campbell)
- Added missing article before Igrp. (Ben Campbell)
- Fixed repeating either in section 4.2. (Ben Campbell)
- Added article "It is written in nesC programming language..." before 
"nesC". (Ben Campbell)
- Rephrased "The workshop recommended that additional work should be 
undertaken in" in section 2. (Warren Kumari)
- Rephrased ".. to be fed in (not both an identity and certificate or 
shared secrets that must be kept confidential)". (Warren Kumari)
- Split long sentence to remove ambiguity "For example, leap-of-faith or 
trust-on-first-use based pairing methods assume that the attacker". 
(Warren Kumari)
- Split long sentence to remove ambiguity "We decided to use the Arduino 
Mega which has the same 8-bit architecture like the Arduino Uno...". 
(Warren Kumari)
- Join sentences "For instance, a sensor that wakes up every now and 
then can likely spend a fraction ...". (Warren Kumari)

- Added reference to nesC. (Eric Rescorla)
- Removed reference to outdated symmetric crypto algorithms. (Eric Rescorla)
- Change "For example, leap-of-faith or trust-on-first-use based pairing 
methods assume that the" to "For example, *many* leap-of-faith or 
trust-on-first-use based pairing methods assume that the". (Eric Rescorla)

- Remove "intuitive" from "intuitive API for developer". (Eric Rescorla)
- Remove extra 0 in measurements for ed25519. (Eric Rescorla)
- Add that relic now also support x25519 and ed25519. (Eric Rescorla)
- Add citation to SEC 2 recommended domain parameters for comparable RSA 
key lengths. (Eric Rescorla)

- Remove hyphen in wrap-around. (Eric Rescorla)
- Use the secp and sect notation uniformly. (Eric Rescorla)
- Authors have decided against adding commas in the measurements 
reported. We had commas in the earlier versions but the working group 
decided that it can cause confusion even though it provides better 
readability.






 Forwarded Message 
Subject:[Lwip] I-D Action: draft-ietf-lwig-crypto-sensors-06.txt
Date:   Mon, 26 Feb 2018 11:38:07 -0800
From:   internet-dra...@ietf.org
To: i-d-annou...@ietf.org
CC: lwip@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Light-Weight Implementation Guidance WG of the 
IETF.

Title   : Practical Considerations and Implementation 
Experiences in Securing Smart Object Networks
Authors : Mohit Sethi
  Jari Arkko
  Ari Keranen
  Heidi-Maria Back
Filename: draft-ietf-lwig-crypto-sensors-06.txt
Pages   : 34
Date: 2018-02-26

Abstract:
   This memo describes challenges associated with securing resource-
   constrained smart object devices.  The memo describes a possible
   deployment model where resource-constrained devices sign message
   objects, discusses the availability of cryptographic libraries for
   resource-constrained devices and presents some preliminary
   experiences with those libraries for message signing on resource-
   constrained devices.  Lastly, the memo discusses trade-offs involving
   different types of security approaches.


The IETF datatracker status page for this draft is:

[Lwip] Call for adoption of draft-mattsson-lwig-security-protocol-comparison-01

[Mohit Sethi]

Dear all,

At the IETF 101 LWIG meeting in London, there was support for adopting 
draft-mattsson-lwig-security-protocol-comparison-01 as a working group 
item. This is a call for adoption of this draft as a working group item.


If you have comments/objections/concerns regarding the adoption of this 
draft, please respond to the list by April 20, 2018.


Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Call for adoption of draft-mattsson-lwig-security-protocol-comparison-01

[Mohit Sethi]

Dear all,

Seeing no objection, this draft is now adopted as a working group document.

Authors, please re-submit the draft as WG document.

--Mohit


On 04/05/2018 04:20 PM, Mohit Sethi wrote:

Dear all,

At the IETF 101 LWIG meeting in London, there was support for adopting 
draft-mattsson-lwig-security-protocol-comparison-01 as a working group 
item. This is a call for adoption of this draft as a working group item.


If you have comments/objections/concerns regarding the adoption of 
this draft, please respond to the list by April 20, 2018.


Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Agenda Items for IETF 102

[Mohit Sethi]

Dear all,

Please send Zhen and I requests for presentation slots during IETF 102. 
We have a 1.5 hour session on Friday, July 20, between 11:50-13:20.


Don't forget to include the title of your presentation, related drafts, 
and the approximate amount of time that you need.


Please also let us know if you plan to present remotely.

Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Early chair review of Neighbor Management Policy for 6LoWPAN

[Mohit Sethi]

Hi Rahul and co-authors,

Here is my early chair review of the Neighbor Management Policy draft. I 
believe that more work is needed to improve the document going forward.


- The document currently needs more text on what kind of networks is the 
suggested neighbor management policy suitable for. Does it work equally 
well in networks with static nodes and networks with mobile nodes? What 
kind of resource-constrained devices are considered in this document? 
For example, what kind of processor, memory and energy-resources are 
available on devices considered in this document.


- The document uses so many acronyms without expanding them even once. 
For example NDP/DAO/NS/NA are never expanded or explained. It would make 
sense to add these to the terminology section 1.1. While it is 
reasonable to assume that the reader has some background in 6lowpan 
networks, it would not hurt to explain what these messages are used for. 
Please also state in the Introduction section that the reader is assumed 
to be familiar with 6lo and RPL networks.


- The abstract could be re-phrased and expanded. Here is a suggestion: 
This document describes the problems associated with neighbor cache 
management in multihop networks involving resource-constrained devices. 
Thereafter, it also presents a sample neighbor management policy that 
allows efficient cache management in multihop networks of 
resource-constrained devices. (Possible add info on what kind of 
networks is this neighbor management policy suitable for)


- The document defines node density as maximum number of devices 
connected on a single hop? This needs to be more precise. Would it be 
right to say: node density is the "maximum number of nodes that are 
reachable with a single hop from any given node in the network".


- What is typical neighbor cache size in devices being considered. Is it 
4 nodes/8 nodes? For an average reader who hasn't deployed a 6lo 
network, it is hard to judge. I guess it would depend on the type of 
platform and available resources on the device.


- The document says that FCFS (First Come First Server) and LRU (Least 
Recently Used) don't always result in efficient cache entry management. 
However, they are also easy to implement in practice. Any smarter 
management policy would likely result in more lines of code? Since you 
have implementation, it would be good to document some experience from 
that here.


- It is currently hard to understand Figure 2 and 3. It refers to "New". 
Perhaps rename it to "New node"/"New joining node". Isn't the new node 
that is joining an existing network also the PaC (PANA Client). Perhaps 
it would help to say that in the text. What is the message PCI in figure 
2. It is not explained anywhere in text.


- The neighbor management policy presented in this document is 
independent from the credentials used for authentication over PANA. 
However, it would still help the reader if you mention the credentials 
used in your deployment and how many round-trips are necessary for the 
AUTHPROC shown in Figure 2 to complete. Currently, it looks like that 
the AUTHPROC is a single message?


- The current text says "The node selects one or more of its neighboring 
peer as its preferred parent based on the DIO received from these 
peers". What logic does it use when picking one peer over the others?


- The current text says "The child node may send a secure unicast NS 
with ARO option containing its global address to be registered on the 
parent node." Perhaps it would help to give more context here. What keys 
are used for the secured unicast NS message. Did they result from the 
initial authentication over PANA.


- The section on NCE Deletion is easy to understand and makes sense. 
Thanks for that.


- In Section 3, the text says "As shown in the figure, the neighbor 
cache is partitioned into different entry types.". Please use the figure 
label, As shown in figure 5, the neighbor cache.


- There is no explanation for the counters in Table 1: 
MAX_ROUTING_PARENT_NCE_NUM, MAX_ROUTING_CHILD_NCE_NUM, 
MAX_OTHER_NCE_NUM. Is it the maximum cache entries that a node can store 
or the cache entries currently available?


- The proactive approach wherein the parent node signals its 
resource-availability in DIO message. How does this signaling work? 
There is no information in the draft? Does it use the flags or DIO 
options such as "0x03 Routing Information" specified in RFC 6550. 
Remember, the document is informational, so we should not be 
standardizing new message formats here.


- The security considerations sections needs some organization. The text 
"Only a subset of entries are reserved for un-authenticated nodes" is 
repeated. Isn't there an inherent assumption that after authentication, 
all the nodes are expected to behave as honest. Otherwise misbehaving 
nodes could always advertise that they don't have any cache entries 
remaining. If so, it might be worth writing some text around this.

[Lwip] ACT: Agenda Items for LWIG at IETF 102

[Mohit Sethi]

Dear all,

A kind reminder. Please send in your requests for presentation slots to 
Zhen and me as soon as possible. The deadline for chairs to upload the 
draft working group agendas was 4th of July 2018: 
https://datatracker.ietf.org/meeting/important-dates/.


I have prepared and uploaded a preliminary agenda: 
https://datatracker.ietf.org/meeting/102/materials/agenda-102-lwig-00 
based on draft submissions.


So far we have only two authors who have asked for presentation time 
(with one even sending the slides). Please send the requests as soon as 
possible. You can send the slides later.


Zhen and Mohit


On 06/25/2018 11:54 AM, Mohit Sethi wrote:

Dear all,

Please send Zhen and I requests for presentation slots during IETF 
102. We have a 1.5 hour session on Friday, July 20, between 11:50-13:20.


Don't forget to include the title of your presentation, related 
drafts, and the approximate amount of time that you need.


Please also let us know if you plan to present remotely.

Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Minutes of LWIG @ IETF102

[Mohit Sethi]

Hi all,

Thank you for participating in the LWIG session at IETF 102. We had a 
productive meeting and covered all the agenda items in the 90 minutes 
allocated for us.


A special thank you to Francesca for taking the minutes and to Rahul for 
serving as the jabber scribe. The minutes from IETF 102 are uploaded here:


https://datatracker.ietf.org/meeting/102/materials/minutes-102-lwig-00

Feel free to report any issues within one week.

We would also use this opportunity to encourage others in the working 
group to serve as minute takers and jabber scribes. Taking notes does 
not mean writing down every word that is spoken. It is meant for 
summarizing important questions and decisions made in the working group. 
You can then re-use the minutes for any internal reporting that you may 
need to do. Marie-Jose summarizes some more benefits of taking notes: 
https://mailarchive.ietf.org/arch/msg/102attendees/LRTr4plHfaikWJubhbqHFt_BQuI


Zhen and Mohit


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Call for adoption of draft-struik-lwig-curve-representations-02

[Mohit Sethi]

Dear all,

At the IETF 102 LWIG meeting in London, there was support for adopting 
draft-struik-lwig-curve-representations-02 
(https://tools.ietf.org/html/draft-struik-lwig-curve-representations-02) 
as a working group item. This is a call for adoption of this draft as a 
working group item.


If you have comments/objections/concerns regarding the adoption of this 
draft, please respond to the list by August 20, 2018. If you had hummed 
in favor of adopting this draft, it would be great if you can express 
your support on the list again.


Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Call for adoption of draft-struik-lwig-curve-representations-02

[Mohit Sethi]

Dear all,

No objections were raised during the call for adoption of 
draft-struik-lwig-curve-representations-02. Based on the consensus in 
the room during IETF 102 as well as support on the list from Nikolas and 
Olaf, this document is now adopted as a working group item.


Rene, please submit the draft as a working group document 
(draft-ietf-lwig-curve-representations-0). It would also be nice if you 
can incorporate the feedback from Nikolas already now.


Zhen and Mohit


On 07/30/2018 09:28 PM, Mohit Sethi wrote:

Dear all,

At the IETF 102 LWIG meeting in London, there was support for adopting 
draft-struik-lwig-curve-representations-02 
(https://tools.ietf.org/html/draft-struik-lwig-curve-representations-02) 
as a working group item. This is a call for adoption of this draft as 
a working group item.


If you have comments/objections/concerns regarding the adoption of 
this draft, please respond to the list by August 20, 2018. If you had 
hummed in favor of adopting this draft, it would be great if you can 
express your support on the list again.


Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Call for adoption of draft-struik-lwig-curve-representations-02

[Mohit Sethi]

Hi Nikolas,

Thank you for your feedback on the draft. Is any of the two libraries 
open source?


I personally think that it would be nice to see some performance numbers 
in the draft.


For example, is an implementation supporting both the curves with the 
same underlying primitives slower than two separate implementations? And 
how much code space or memory can be saved by re-using some of the 
underlying primitives?


--Mohit


On 08/19/2018 08:08 PM, Nikolas Rösener wrote:

Hi,

my name is Nikolas Rösener - I am student at the Universität Bremen 
currently writing my masters thesis on the topic of the performance of 
curve model transformations.


In my opinion draft-struik-lwig-curve-representations-02 already 
presents a great summary of the possible transformations for the 
Curve25519-family of curves. I implemented the transformations in two 
different libraries, as part of my performance evaluation, and had no 
problems following the formulae in the draft.


In retrospect, I found that the following additional information would 
have been very useful if I had attempted to implement the 
transformations as part of a serious cryptographic primitive:


- Test Vectors
- Recommendations for (the relevance of) dealing with the special 
cases (point-at-infinity etc.)

- Usages with co-factor Diffie-Hellmann (NIST SP 800-56a)
- Usages with ECDSA (FIPS Pub 186-4)

I had some further discussions with Rene on topics related to 
retrofitting existing implementations with conversions (doing generic 
modular reduction, providing transformation formulae for different 
point formats, providing algorithms for recovering coordinates...). 
The relevance of these of course depends on the direction the draft is 
taking.


Oh, and - personal preference - but I also think it makes quite a 
difference to the ease and speed of implementing an ecc algorithm if 
it is provided as three-operand-code in addition to the mathematic 
formula (like e.g. https://hyperelliptic.org/EFD/). The former reduces 
cognitive load and risk of manual errors.


Best regards,
Nikolas Rösener


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued"

[Mohit Sethi]

Hi Tero,

You raise some very interesting points here.

I personally think that the draft can benefit from more information 
about existing implementations of ESP. For example, documenting the fact 
that many implementations do not send dummy packets or which 
implementations use TFC. Adding specific example of  802.15.4 TSCH 
networks and how synchronized time is available would also be helpful.


Of course, this could be done before or after its adoption.

--Mohit


On 08/31/2018 04:41 PM, Tero Kivinen wrote:

Heinrich Singh writes:

Text saying that you would loose some privacy by using fixed number
of SPI does not absolve your responsibility. It should not recommend
that.

There is no requirement for SPI to be random and originally it was
written that way so implementations can use whatever method to
allocate SPIs they like. For example they can use index to the SPI
table or whatever instead of allocating random SPI, or they could even
use pointer to the SPI structure in memory as SPI value (would of
course need some kind of checks that address is in area allocated for
SPIs and is aligned properly).

Adding requirement that SPI needs to be random would be modifying the
base ESP, and is not in the scope of draft trying to define minimal
ESP. Saying that in contrained devices which have very few SPIs the
SPIs can be allocated using some other method than random is in scope
of the this draft.

Also most of the constrained devices do not care about privacy as they
have fixed hardware address, stable IPv6 address and are not
associated with any person. Sensor sending wind speed, or temperature
to the cloud service does not have privacy requirements, sensors
sending temperature inside your house might have (as it might leak out
information whether you are home or not), but even in that case the
fact that it is your sensor sending information every 60 seconds does
not, only the data inside.

Privacy requirements are not something that are always there, they
always depend heavily about what you do with the protocol. I.e., in
some cases the IP addresses, hardware addresses, SPIs etc need to be
protected against tracking, but in many cases they do not need to be.

This document gives recommendation that in some cases it might be good
idea to use fixed SPI as it might make implementations smaller. I.e.,
if the option is either not to use IPsec at all, as it is too big, or
to use IPsec with fixed SPI and other limitations that make it small,
I think the option with IPsec is better.


I do not know 802.15. Others can also say what they feel but from my
experience simple monotonic sequence numbers are more easier than
having a clocks.

True. But for example 802.15.4 TSCH (i.e., the protocol over which
6TiSCH is working) does have globally shared clock which is kept in
sync with everybody. So in that kind of situations using clock as
monotonically incrementing counter and using that as sequence number
might save resources in constrained device.


This I think is a not a good idea. Sender and receiver can easily
get out of sync because your rate of sending packets is not
proportional to time. The receiver would need to allow very large
window. The sender would still need to store time to flash in-case
there is need for sync after device reset.

Sequence numbers are in one direction, i.e., I need to use
monotonically incrementing sequence number when I send, but that
sequence number does not have anything to do with other ends sequence
number. Also window size is need only if you have out of order
packets, and you care about replay protection. Both of them are
something that might not be something that constrained device cares.

For example it might have internal replay protection for the messages
it sends, so it does not need to care whether there is replays on the
IPsec level, thus it can drop the whole replay protection checks
completely. Or it might work on the environment where out of order
deliver is not possible, thus it can just keep window size to 1.

Also recipient cannot know which method other end is using when
generating sequence numbers, so it needs to do the replay protection
checking using whatever method it wants. It might need to store the
last received sequence number to the flash if it cares about replay
protections, or it can simply drop replay protection completely.

On the other hand sender is REQUIRED to send sequence numbers in such
way they are monotonically incrementing (not necessarely by one), and
if it has any kind of other monotonically incrementing counter like
clock, it can use that to generate the sequence numbers and get rid of
the requirement to store outgoing sequence number to the flash.


What you mean implementations must discard dummy packets? Even
non-constrained implementations must discard dummy packets so what
is new here?

Yes. And that quite often happens automatically as there is nobody in
the device that wants to get packets with that protocol number.

I have not actual

Re: [Lwip] Call for Papers - IEEE NetSoft 2019

[Mohit Sethi]

Hi Lisandro,

I am extremely sorry to see messages like these (which some would call 
spam) being posted to the list. As a general etiquette, please first 
discuss with the chairs before sending out such advertisement emails. 
People on other lists have already expressed their displeasure about 
this: https://mailarchive.ietf.org/arch/msg/6lo/YCw6WUWNCTkKOhgL17cvUyd4pe8


@LWIG: Please understand that we (Zhen and I), as list administrators 
are trying our best to limit the amount of emails you have to process. 
There were even emails advertising job openings which were posted to the 
LWIG recently. Thankfully, we have been successful in moderating them 
before they reached you.


Zhen and Mohit

On 10/23/18 5:39 PM, Lisandro Zambenedetti Granville wrote:



                   Call for Papers
                  IEEE NetSoft 2019

The 5th IEEE International Conference on Network Softwarization
      "Unleashing the Power of Network Softwarization"
           June 24-28, 2019 - Paris, France
http://ieee-netsoft.org 



The 5th  IEEE  International Conference on Network Softwarization 
(NetSoft 2019)
will be held on June 24-28, 2019 in Paris, France. IEEE NetSoft has 
been created
as  a  flagship  conference  aiming  at  addressing ìSoftwarization" 
of networks
and  systemic  trends  concerning  the convergence of Cloud Computing, 
Software-

Defined Networking (SDN), and Network Functions Virtualization (NFV).

*** Scope ***
*
Over the  years, software has become the core value provider in the 
telecommuni-
cations industry. Boosted by scientific breakthrough, continuous 
 innovation and
stringent requirements for  new  services, the telecommunications 
transformation
is  on  track  and  filled  with  opportunities. The supporting 
technologies are
maturing  at  great  pace  and  softwarization  is recognized as a 
major enabler

by many standardization efforts and industrial initiatives.

This  trend will be reflected in  NetSoft 2019 in the various topics 
of interest
under  the  theme  "Unleashing  the  power  of  network 
 softwarization" and the
conference  will serve as a forum to discuss the latest advances in 
this area in

both industry and academia related.

*** Topics of interest ***
**
NetSoft  2019  will  feature technical paper presentations, keynotes, 
tutorials,
demos and exhibitions from world-leading experts representing service 
providers,
vendors,  research institutes, open source projects, and academia. 
Additionally,
topical  workshops  will be co-located so various call for proposals 
are issued.

The topics of interest include, but are not limited to:

- Programmable SDN and NFV: languages, architectures, environments
- Softwarized cloud, fog, and edge infrastructures
- Cognitive and autonomic networking
- Network slicing and slice management
- Mobility management in software networks
- Policy-based and Intent-Based Networking
- Centralized vs Distributed control, management & orchestration
- Abstractions and virtualization of resources, services, and functions
- Service Function Chaining
- Container/microservice-based network functions
- Efficient network/service monitoring in SDN/NFV
- AI techniques to support network automation
- Analytics and big data approaches for managing softwarized networks
- QoS and QoE in softwarized infrastructures
- Resilience, reliability, and robustness of softwarized networks
- Cooperative multi-party, multi-domain, multi-tenant SDN/NFV environments
- Security, Safety, Trust and Privacy support in virtualized environments
- SDN switch/router architecture and design
- Dynamic resource   discovery   mechanisms   and  service 
 parameter/resource

negotiation schemes
- APIs, protocols, and languages for programmable networks
- Lifecycle management of network software
- DevOps methodologies for network softwarization
- Debugging and introspection of software-defined virtualized systems
- Service fulfillment assurance systems in SDN/NFV environments
- Softwarized platforms for Internet of Things (IoT)
- Energy efficient and green software-defined infrastructures (SDI)
- Transition strategies from existing networks to SDN/NFV
- New service models and paradigms enabled by softwarization
- New value chains and business models
- Socio-economic impact and regulatory implications for softwarization
- Experience reports from experimental testbeds and deployments

*** Paper Submissions ***
*
Prospective  authors are  invited to submit technical papers, 
tutorial, demo and

workshop proposals that fall into the conference topics of interest.
Deadlines are:

- Technical Papers:December 3, 2018
- Workshop Proposals:November 12, 2018
- Tutorial Proposals:January 15, 2019
- Demo Proposals:February 25, 2019

For  specific details

Re: [Lwip] [COSE] draft-ietf-lwig-curve-representations-13

[Mohit Sethi M]

Hi John,

As a co-chair of the LWIG working group, I am happy that you find this draft 
from LWIG "very good" and believe that it could help solve "some of the 
problems IoT devices have with Ed25519".

The IANA registrations of this draft have been reviewed by experts such as Russ 
Housley and Jim Schaad in the past. We had also received a confirmation from 
IANA (Sabrina Tanamal) that the JOSE expert has approved the corresponding 
registrations.

It for the designated experts of various registries to decide wheter some 
registrations need coordination with other working groups.That being said, more 
reviews are always welcome (even at this late stage). I am sure Rene can 
present an update for the COSE working group during IETF 109. Note that the 
draft has already cleared the IETF last call and the authors/chairs would like 
to finish this soon(ish).

--Mohit

On 11/7/20 12:04 AM, John Mattsson wrote:

Hi,



I looked through this draft again. I think it is a very good draft and I think 
it will be a solution to some of the problems IoT devices have with Ed25519. I 
will bring up this draft for discussion in the LAKE WG at IETF 109.



I find it strange that the IANA registration has not been coordinated with COSE 
WG at all. I am a bit surprised to see IANA registrations for 
COSE/JOSE/PKIX/CMS at all in a LWIG draft (is that in charter?). If LWIG wants 
to register new algorithms, I think LWIG at a minimum should coordinate with 
COSE WG and other groups. I think this draft should be presented at the next 
COSE WG meeting.



I support registration of W-25519 and W-448 curves as long they agree with 
NIST. I would like answers to the questions why ECDSA25519 and ECDH25519 are 
needed at all. There is no ECDSAP256 and no ECDHP256, so why are specific 
algorithm registration needed for W-25519?  It makes no sense to me that a 
special signature registration is needed for COSE but not for PKIX? If PKIX can 
use ecdsa-with-SHA256 why cannot COSE use ES256?



I don't think ANSI X9.62 is an acceptable normative reference. NIST just 
removed the normative reference to ANSI X9.62 in SP 186-5.

Cheers,
John

From: COSE  on behalf of 
Rene Struik 
Date: Friday, 6 November 2020 at 20:37
To: Göran Selander 
,
 "lwip@ietf.org" , 
"c...@ietf.org" 
Subject: Re: [COSE] draft-ietf-lwig-curve-representations-13

Hi Goran:

Please find below some brief feedback on your note:
- the naming wei25519 has been around since the first draft (Nov 13, 2017, 
i.e., 3 years minus 1 week ago), see [1]. NIST indeed produced two draft 
documents, viz. Draft NIST SP 800-186 and Draft FIPS Pub 186-5 (on October 31, 
2019), which generated lots of (to my knowledge still unresolved) comments 
during public review. It is hard to refer to that document, since it is only a 
draft and unfortunately has quite a few errors.
- earlier versions of the lwig draft have received reviews by the crypto review 
panel (Stanislavslav Smyshlyaev), iotdir early-review (Daniel Migault); the 
sections on COSE/JOSE code point assignments resulted from a phone call and 
various email exchanges with Jim Schaad; the section on PKIX/CMS was suggested 
during IETF Last-Call secdir-review (Russ Housley) and reviewed by him. The 
document had IETF Last-Call Aug 24, 2020. See, e.g., the status pages [1].
- ECDSA has been around since 1999, has been widely standardized, and has seen 
lots of analysis, where ECDSA25519 is simply yet another instantiation. 
Signature generation and verification times for ECDSA25519 should be similar to 
those of Ed25519 (since timing is dominated by scalar multiplication, where one 
could simply use Montgomery arithmetic [3]). In my personal view, ECDSA25519 
may be more secure than Ed25519 (if only because it is non-deterministic, see 
Security section [6]); similar side-channel care has to be taken in either case.
 - As mentioned in the draft, one can easily switch between Wei25519 and 
Curve25519 (which requires a single field addition or subtraction only, i.e., 
<.01%, see Appendix E.2 [7]). As mentioned in the draft, one could use 
Wei25519.-3 with an existing generic implementation that hardcodes the domain 
parameter a=-3, but needs to compute an isogeny and dual isogeny for this 
(adding 5-10% cost, see Appendix G.2 [8]]) and a ~9.5kB table (see Section 5.3 
[4]). However, if one already has generic hardware support, one may still have 
a significant win (see Section 6 [5]).
- The isogeny for Wei25519.-3 has odd degree l=47, which is co-prime with the 
order of the curve, so is in fact invertible. With Wei448.-3, the isogeny has 
degree l=2, so is not invertible; however, this does not really matter, since 
it is invertible with correctly generated public-private key pairs (which have 
prime/odd order) and the factor two is abso

Re: [Lwip] [COSE] draft-ietf-lwig-curve-representations-13

[Mohit Sethi M]

Hi John,

These are all valid points and I am sure the authors will address them.

Regarding the process of IANA registrations, RFC 8126 
(https://tools.ietf.org/html/rfc8126#section-5.2) notes:

   The designated expert is responsible for coordinating the appropriate
   review of an assignment request.

As you can see from the document history 
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/history/ 
:

2020-10-20
12  Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from 
Reviews assigned
2020-10-20
12  Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed 
from IANA - Not OK
2020-09-08
12  Sabrina Tanamal IANA Experts State changed to Reviews assigned
2020-09-08
12  (System)IANA Review state changed to IANA - Not OK from IANA - 
Review Needed

we were made to believe that the registrations are OK. Göran is one of the 
designated experts for the COSE registries and has brought forward the 
potential issues to the COSE working group. So the process works (albeit its 
not perfect).

Your feedback asking us to better coordinate with the COSE working group is 
very much appreciated and we in LWIG will try to ensure this in the future.

--Mohit

On 11/10/20 2:26 PM, John Mattsson wrote:
Hi,
While any working group can register algorithms for COSE, I find it 
disappointing that nobody took 10 seconds to send an email to COSE before Göran 
did. I did not at all expect LWIG to standardize new curves and register them. 
When I reviewed the draft some time ago it only contained formulas to enable 
use of existing implementations. Ben sent an email to CFRG to a couple of month 
ago, but as the abstract has not been updated since the -00 version, I did not 
read it again.
- The draft tries to register a lot of low values (-1, -2, -9, -24, -48, -49) 
in the COSE registries which it obviously cannot as the draft is informational, 
and the registrations require standards action.
- If a new ECDSA25519 registration is needed for COSE, it should be needed for 
PKIX as well. My understanding is that ES256 and ecdsa-with-SHA256 are the same.
- I really do not want to repeat the mess with secp256r/prime256v1/P-256 where 
different SDOs standardized different names for the same curve.
- IETF curve definition and OID and IANA registrations of curve25519 in 
Weirstrass form should absolutely be coordinated with NIST. The last thing 
anybody want is two identifiers for the same curve, or even worse, two slightly 
different versions of curve25519 in Weirstrass form. Looking at 
draft-ietf-lwig-curve-representations-13 and NIST.SP.800-186-draft it looks 
like the y-coordinate of G is different for Wei25519 and W-25519...
Cheers,
John

From: Mohit Sethi M 
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
Date: Tuesday, 10 November 2020 at 09:40
To: John Mattsson 
<mailto:john.matts...@ericsson.com>, Rene Struik 
<mailto:rstruik@gmail.com>, Göran Selander 
<mailto:goran.selan...@ericsson.com>, 
"lwip@ietf.org"<mailto:lwip@ietf.org> <mailto:lwip@ietf.org>, 
"c...@ietf.org"<mailto:c...@ietf.org> <mailto:c...@ietf.org>
Subject: Re: [Lwip] [COSE] draft-ietf-lwig-curve-representations-13


Hi John,

As a co-chair of the LWIG working group, I am happy that you find this draft 
from LWIG "very good" and believe that it could help solve "some of the 
problems IoT devices have with Ed25519".

The IANA registrations of this draft have been reviewed by experts such as Russ 
Housley and Jim Schaad in the past. We had also received a confirmation from 
IANA (Sabrina Tanamal) that the JOSE expert has approved the corresponding 
registrations.

It for the designated experts of various registries to decide wheter some 
registrations need coordination with other working groups.That being said, more 
reviews are always welcome (even at this late stage). I am sure Rene can 
present an update for the COSE working group during IETF 109. Note that the 
draft has already cleared the IETF last call and the authors/chairs would like 
to finish this soon(ish).

--Mohit
On 11/7/20 12:04 AM, John Mattsson wrote:

Hi,



I looked through this draft again. I think it is a very good draft and I think 
it will be a solution to some of the problems IoT devices have with Ed25519. I 
will bring up this draft for discussion in the LAKE WG at IETF 109.



I find it strange that the IANA registration has not been coordinated with COSE 
WG at all. I am a bit surprised to see IANA registrations for 
COSE/JOSE/PKIX/CMS at all in a LWIG draft (is that in charter?). If LWIG wants 
to register new algorithms, I think LWIG at a minimum should coordinate with 
COSE WG and other groups. I think this draft should be presented at the next 
COSE WG meeting.



I support registration of W-25519 and W-448 curves as long they agree with 
NIST. I would like answers to the questions why ECDSA25519 and ECDH25519 a

[Lwip] WGLC for draft-ietf-lwig-minimal-esp

[Mohit Sethi M]

Dear all,

This email initiates the working group last call (WGLC) for 
draft-ietf-lwig-minimal-esp:
https://tools.ietf.org/html/draft-ietf-lwig-minimal-esp-02

The draft has been reviewed by Tero, Scott, and Valery in the past.

If you have any remaining concerns or issues, please comment on the mailing 
list before the WGLC expires on December 22, 2019. If you have previously 
reviewed the document and feel that it is ready for IESG review, please express 
support on the mailing list. The document shepherd can use this information in 
the writeup.

This WGLC is also CCed to ipsecme.

Zhen and Mohit
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Magnus Westerlund's Discuss on draft-ietf-lwig-curve-representations-19: (with DISCUSS)

[Mohit Sethi M]

Argh, I find this email very misleading. I did change the status of the draft 
but the ADs were well aware of this change. Erik Kline in his email on 14th Jan 
wrote:

Rene,

I'm trying to catch up on all the changes between -12 and -19.  At a minimum, 
since this has been changed from Informational to Standards Track I think we 
should have another IETF Last Call.  I'll have a read through the full diff 
tomorrow afternoon and see if I can figure out what's next.

In my email response I did state that running another last call may not 
necessarily bring in more reviews as the draft is rather crypto-heavy (and the 
contents have remained the same). But I left the final decision to the ADs. I 
had written:

I feel that another last call may not necessarily result in more meaningful 
reviews. Obviously, as ADs, you have much more experience and I trust your 
judgement call on this.

My original shepherd writeup noted the conflict between the requested values 
and the intended status:

The values requested require "Standards Action With Expert Review" however the 
requested RFC type is Informational. However, Jim Schaad who is one of the 
experts for the IANA registries has stated in a private email thread that the 
IANA section of this draft looks correct.

Obviously, ADs can forget in the deluge of drafts. But to hint in anyway that 
this was changed and no one noticed would be grossly incorrect.

--Mohit

On 2/16/21 2:43 AM, Erik Kline wrote:

On Mon, Feb 15, 2021 at 6:12 AM Magnus Westerlund via Datatracker
<mailto:nore...@ietf.org> wrote:


Magnus Westerlund has entered the following ballot position for
draft-ietf-lwig-curve-representations-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/



--
DISCUSS:
--

So this is process violation discuss. This document is up for approval as
standards track. However, there are no evidence that it was ever IETF last
called for standards track. I only find evidence for a IETF last call intended
for informational on 2020-08-25.

I have not reviewed the content of document yet. I would propose that the
responsible AD pulls this document from this telechat and then performs the
IETF last call before it gets scheduled again.


Argh, I completely missed that the intended status had been changed on
draft 14 from the LC (draft 12).

2020-11-18 14 Mohit Sethi Changing to proposed standard as
requested by the COSE experts.
2020-11-18 14 Mohit Sethi Intended Status changed to Proposed
Standard from Informational

___
Lwip mailing list
Lwip@ietf.org<mailto:Lwip@ietf.org>
https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Magnus Westerlund's Discuss on draft-ietf-lwig-curve-representations-19: (with DISCUSS)

[Mohit Sethi M]

Argh, the IESG writeup is a replica of my shepherd writeup 
(https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/shepherdwriteup/).
 I had noted that:

Since this draft is crypto-heavy only a few working group members were able to 
provide detailed reviews.

I had also noted the discrepancy between the requested values and the stream 
way before IETF last call was issued and before the current COSE experts 
objected:

The values requested require "Standards Action With Expert Review" however the 
requested RFC type is Informational.

When the draft was adopted to the working group, it did not have any 
registration requests 
(https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-00#section-5).
 The question of whether LWIG is the right venue or not is something that many 
of us have struggled with over time. This was noted by me, Suresh (AD at the 
time of adoption) and Ben (when he saw the IoT directorate review in 2019: 
https://datatracker.ietf.org/doc/review-ietf-lwig-curve-representations-08-iotdir-early-migault-2019-10-25/).

In hindsight, another IETF last call after the change to standards track would 
have been nice regardless of whether it would have resulted in more review. But 
I think I have been following all the processes diligently and doing everything 
I can (and perhaps am supposed to) as a co-chair/document shepherd. If you have 
some feedback for improving things, I'm all ears.

--Mohit

On 2/17/21 1:43 PM, John Mattsson wrote:

Argh,



2020-11-18 14 Mohit Sethi Changing to proposed standard as requested by the 
COSE experts.



I think this might have been triggered by my comment on the COSE list. If that 
is the case, I would like to clarify that I am not a designated IANA COSE 
expert and I did not "request" this. I just pointed out that the requested 
numbers could not be assigned by an informational draft.

This is a curve that could benefit from a 1-2 byte COSE identifier, but it will 
probably also work very well with a 3 byte identifier. In some use cases like 
EDHOC it does not matter at all as the identifier is not sent on the wire.



At a minimum, since this has been changed from Informational to Standards Track 
I think we >should have another IETF Last Call.



Making this LWIG document standards track seems strange. The IESG writeup "only 
a few working group members were able to provide detailed reviews" seems to 
contradict the "has received significant community review" requirement for 
standards track.

I personally see no need to change the status of this document to standards 
track. If a 3 byte COSE identifiers are unacceptable it seems better to write a 
short standards track COSE draft for that part and publish the rest as 
informational.

Cheers,
John

___
Lwip mailing list
Lwip@ietf.org<mailto:Lwip@ietf.org>
https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Magnus Westerlund's Discuss on draft-ietf-lwig-curve-representations-19: (with DISCUSS)

[Mohit Sethi M]

Hi Murray, IESG,

Sorry for the somewhat long email but I thought it is worth elaborating on the 
history of this document a little. I guess many of us struggled with the 
question if LWIG is the right venue before this document was adopted. Suresh 
(AD at the time of adoption), Ben Kaduk, and I (co-chair) did note that this 
draft is crypto-dense. Ben in 2019 asked:

Hi all,

I happened to see the IoTdir review of
draft-ietf-lwig-curve-representations go by, and was kind of struck by how
math/crypto-dense it was (and how long it was).  It's really the sort of
thing I expect to see come out of CFRG, and doesn't strike me as really
LWIG's core competency.

Could you say a bit more about why it's being pursued in LWIG?

Thanks,

Ben

and Suresh responded:

Yes. It has been very concerning to me and and I did raise my concern several 
times with the IESG including the last time at the IESG wrap up meeting for 
Prague on March 29. I was also concerned about the crypto heavy nature and 
proceeded based on the Stanislav Smyshlyaev review from the Crypto Review 
panel. I had also specifically asked for a SecDir review before I send this off 
to IETF LC but the Sec Dir review due on 10/04 has not arrived yet. I will let 
Mohit and Zhen make the call, but if you think the cfrg would be a good venue 
for this I would personally be happy to approve the move.

Thanks
Suresh

I think some of our concerns were assuaged because this draft was sent to the 
IETF Crypto Review Panel 
(https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel) through Alexey 
Melnikov. Stanislav Smyshlyaev reviewed the document and the formulae. I 
believe comments from the Crypto Review Panel were addressed by Rene.

Ben later responded:

Hi Mohit,

I didn't know that Stanislav had done a crypto review (or rather, I forgot,
since I think I am on that mailing list as a courtesy); he does good work,
and that alleviates most of my concerns.

My gut feeling remains that CFRG is "more appropriate" in some abstract
sense, but it's not clear that the benefit of moving the document is worth
any gains that might be had.  Hopefully one of us can remember to forward
the IETF LC note to the CFRG when that happens, which should be enough
awareness there.

Thanks for the extra background,

Ben

LWIG has done lots of security related RFCs and drafts:

RFC 7815: Minimal Internet Key Exchange Version 2 (IKEv2) Initiator 
Implementation: https://datatracker.ietf.org/doc/rfc7815/
RFC 8387: Practical Considerations and Implementation Experiences in Securing 
Smart Object Networks: https://datatracker.ietf.org/doc/rfc8387/
draft-ietf-lwig-minimal-esp: Minimal ESP: 
https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/

When Rene's draft was adopted, there were no IANA registrations 
(https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-00#section-5).
 As it happens sometimes, the scope of the work expanded after working group 
adoption and perhaps everyone involved could have been more diligent. I 
understand the IESG concerns about LWIG charter not covering this work item 
precisely. But as an individual contributor: I think we are at a point of 
diminishing returns and pursuing this document elsewhere is perhaps not the 
best choice. I like Carsten's suggestion of reverting this document to 
informational and allowing some values to be registered even if they require 
standards action. Carsten explains the logic rather nicely here: 
https://mailarchive.ietf.org/arch/msg/cose/g8UaczrsG6zHqR6qDIxRt-JJMtM/

Obviously, you, the IESG members have way more experience than me and I'll 
follow your recommendations here (both as co-chair and document shepherd).

--Mohit

On 2/18/21 4:29 AM, Murray S. Kucherawy wrote:
On Wed, Feb 17, 2021 at 10:57 AM Rene Struik 
mailto:rstruik@gmail.com>> wrote:
I am sure you have much more process experience than I do. However, I have 
trouble understanding how having a IANA section makes this suddenly a process 
violation. Do I understand correctly that, in your mind, this process issue 
would be moot if I would simply partition the doc into two parts A and B, where 
C:=A+B is the current document and where A=C\B and B:={Section 12.2, Section 
12.3}?

[...]

I simply would like to understand, since I do not right now.

Hopefully this helps rather than muddies things further, and Magnus (and Erik, 
and Ben, etc.) can correct me if I'm wrong:

The first issue: The Last Call announcement for this document indicated that 
the working group wants it to have Informational status when published.  After 
that Last Call was completed, our procedures assert that the document, with any 
Last Call feedback worked into it, has IETF consensus to be published with that 
specific status.  Changing the status being sought to Standards Track without 
also running a new Last Call saying so violates our procedures; the document 
can't go forward unless that status change is reverted, or a second Last Call 
is done indicating

[Lwip] draft-ietf-lwig-minimal-esp shepherd writeup

[Mohit Sethi M]

I am now preparing the shepherd writeup for draft-ietf-lwig-minimal-esp. 
I wanted to clarify and double check a few things:

- If the SPI is not random and is chosen by some application specific 
method -> it can reveal the application using ESP.

- I assume a resource-constrained device would not have many inbound 
connections. Would it make sense to generate a byte of randomness 
instead of entire 32-bit SPI? At least some APIs allow asking for a byte 
of randomness (randomByte()). This is assuming an upper limit on the 
number of inbound connections.

- When sequence numbers are time -> won't it reveal the time at which 
the packet was sent.

- Are we comfortable with the recommendation: 'A node MAY drop 
anti-replay protection provided by IPsec, and instead implement its own 
internal mechanism.'? What might this internal mechanism look like?

A few typos:

-

Section 3:

Please expand SAD on first usage.

Section 4:

Typo: In a constrainted environment -> In a constrained environment

I looked at old RFCs and they seem to use both crypto-suite and 
cryptosuite. I have a preference for the later. Perhaps we can remove 
the hyphen.

-

--Mohit



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] draft-ietf-lwig-minimal-esp shepherd writeup

[Mohit Sethi M]

The current version of the shepherd writeup is now in datatracker: 
https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/shepherdwriteup/.

I have copied the text here for your convenience:

Mohit Sethi is the document Shepherd. Erik Kline is the responsible Area 
Director.

The document defines techniques for a minimal implementation of the 
Encapsulation Security Payload (ESP) defined in RFC 4303. It does not 
update or modify RFC 4303 in any way. In case of any conflicts RFC 4303 
is treated as authoritative description.

The following people reviewed and provided comments: Tero Kivinen, 
Valery Smyslov, and others. Paul Wouters had expressed strong 
reservations 
(https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0/) 
during the call for adoption. He had reservations against relaxing the 
randomness requirements for SPI. He also noted that the argument for not 
having a sequence number counters are weak as AES-GCM and 
CHACHA20POLY1305 require a counter anyways. Paul was amenable to 
adopting the document as long as it was defining an ESP profile for 
resource-constrained devices and not modifying the protocol itself.

No issues were raised during the working group last call. The document 
shepherd has solicited reviews from the security and IoT directorate as 
well as the gen-art team.

The Shepherd has verified that all of the authors have already disclosed 
any IPR related to this document, as is required by BCPs 78 and 79.

There are no DOWNREFs.

There are no IANA considerations.

--Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [IPsec] draft-ietf-lwig-minimal-esp shepherd writeup

[Mohit Sethi M]

Hi Paul,

Adding Ben (IPsecME AD) and Erik (LWIG AD) to the CC list for an early heads up.

Thanks for reviewing the document. I'll let the authors provide answers to your 
review.

On the procedural side of things: this document is within the LWIG charter 
(https://datatracker.ietf.org/wg/lwig/charter/) and follows the path taken by 
Minimal IKEv2 which was also completed in LWIG as RFC 7815 
(https://datatracker.ietf.org/doc/rfc7815/).

During the call for adoption, there was a general consensus to proceed in LWIG 
while keeping close contacts with IPsecME (as well as an agreement to issue a 
joint last call). Tero 
(https://mailarchive.ietf.org/arch/msg/lwip/Shf2oUKvtIsb0uzY2zRwuBurm58/), 
Valery 
(https://mailarchive.ietf.org/arch/msg/lwip/p1i4hZBjn7PD3ksS9kh8C0ouUOU/) and 
Scott (https://mailarchive.ietf.org/arch/msg/lwip/dF3eZXG8GTV-o7aH4BnFk2zlR6c/) 
for example provided reviews of the draft.

I think your comments during the adoption 
(https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0/) did 
not argue moving this draft to IPsecME (unless I missed something):

If the document is defining a minimum/battery optimized ESP
configuartion, I have no problems with it and I will review further
text and welcome adoption. If it makes changes to the ESP protocol,
then I think there should be more discussion before adoption.

Paul

That being said, I am not fundamentally opposed to moving this document to 
IPsecME. However, it is important to consider that the document has already had 
a relatively long lifecycle in LWIG.

--Mohit

On 3/22/21 6:12 AM, Paul Wouters wrote:
On Sun, 21 Mar 2021, Daniel Migault wrote:

(replying to some issues here, but also added a full review of the document)

Side note: I am bit confused why this document would not be a document
from the IPsecME WG ? I know we talked about this before? Did we decide
against adoption at IPsecME ? Can the authors, WG chairs of IPsecME or
the responsible AD shed some light on the history here?

In general, this draft is very "wordy" because it is trying to steer
itself around a lot of problems, without making firm decisions. But
the point of an RFC is that it should make clear decisions that
implementers can adopt clearly. As such, I'm not in favour of this
draft. I believe I stated this before?

[1] 
https://protect2.fireeye.com/v1/url?k=267ff37b-79e4ca56-267fb3e0-8692dc8284cb-4b11e1d62003bf58&q=1&e=de278ec7-abe4-4a5c-bad8-76ad8f57cf87&u=https%3A%2F%2Fgithub.com%2Fmglt%2Fdraft-mglt-lwig-minimal-esp%2Fcommit%2F47f1351b1928ba687af18e75e253e98720448e8e
On Sat, Mar 20, 2021 at 5:12 AM Mohit Sethi M 
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
 wrote:
  I am now preparing the shepherd writeup for draft-ietf-lwig-minimal-esp.
  I wanted to clarify and double check a few things:

  - If the SPI is not random and is chosen by some application specific
  method -> it can reveal the application using ESP.


It is correct that the use of non random SPI may have some privacy impacts and 
one of these impacts is that in some cases, a SPI may be used to track an 
application. Note that our intention was to make it
clear that when SPI are non randomly generated, there are some privacy 
implications to consider as well as that randomly generated SPI is preferred.

At the time I also mentioned one attack against IKE that was twarted by
having 4 random bytes as SPI. It remains dangerous to change this
property of ESP, and I recommended to not do that.

https://access.redhat.com/blogs/product-security/posts/sloth

But it seems that although my comments caused the draft to be modified,
it still allows non-random SPIs:

   However, for some constrained nodes, generating and handling 32 bit
   random SPI may consume too much resource, in which case SPI can be
   generated using predictable functions or end up in a using a subset
   of the possible values for SPI.  In fact, the SPI does not
   necessarily need to be randomly generated.  A node provisioned with
   keys by a third party - e.g. that does not generate them - and that
   uses a transform that does not needs random data may not have such
   random generators.  However, nonrandom SPI and restricting their
   possible values MAY lead to privacy and security concerns.  As a
   result, this alternative should be considered for devices that would
   be strongly impacted by the generation of a random SPI and after
   understanding the privacy and security impact of generating nonrandom
   SPI.

So I feel I raised a security issue, and the text just copied my concern
but still basically states implementations MAY do this. I believe this
is wrong.

Note that the draft defined one (common way) to generate the SPI value that is 
using a random generator to generate this SPI value. All other means fall into 
the category of using deterministic functions.
This does not necessarily mean that a fix of predefined SPI will necessarily be 

[Lwip] Agenda Items for IETF 103

[Mohit Sethi M]

Dear all,

Please send Zhen and I requests for presentation slots during IETF 103. 
According to the preliminary agenda, we have a 1 hour session on 
Wednesday, November 7, between 11:20-12:20 in room Boromphimarn 1/2.

Don't forget to include the title of your presentation, related drafts, 
and the approximate amount of time that you need.

Please also let us know if you plan to present remotely.

Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Agenda Items for IETF 103

[Mohit Sethi M]

Dear all,

Please let us know if you need a presentation slot during the LWIG
session at IETF 103.

Zhen and I have prepared a preliminary agenda based on the requests we
have received so far:
https://datatracker.ietf.org/meeting/103/materials/agenda-103-lwig-00

--Mohit

On 10/9/18 4:58 PM, Mohit Sethi M wrote:
> Dear all,
>
> Please send Zhen and I requests for presentation slots during IETF 103. 
> According to the preliminary agenda, we have a 1 hour session on 
> Wednesday, November 7, between 11:20-12:20 in room Boromphimarn 1/2.
>
> Don't forget to include the title of your presentation, related drafts, 
> and the approximate amount of time that you need.
>
> Please also let us know if you plan to present remotely.
>
> Zhen and Mohit
>
> ___
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued"

[Mohit Sethi M]

Hi Paul, Heinrich and Tero,

The authors have updated the draft based on the feedback received:

https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/

Please let us know whether you still have objections to this being
adopted as a WG document.

--Mohit

On 8/31/18 7:50 PM, Paul Wouters wrote:
> On Fri, 31 Aug 2018, Tero Kivinen wrote:
>
>> There is no requirement for SPI to be random and originally it was
>> written that way so implementations can use whatever method to
>> allocate SPIs they like.
>
> However, the randomized SPIs does give us some security, as we saw in
> the SLOTH attack, that was only stopped because of the effort of 2^77
> to break. If we used predictable SPIs for IKE, then IKE would have
> fallen to the SLOTH attack as well.
>
> https://access.redhat.com/blogs/product-security/posts/sloth
>
> Although in this case, I guess we are talking about ESP/AH SPIs. There
> is still benefits in randomness, even if it is not cryptographically
> random. Just to ensure the same SPIs aren't re-used too quickly and
> get confused. The document does correctly point out not to use SPIs
> below 256.
>
>> Adding requirement that SPI needs to be random would be modifying the
>> base ESP, and is not in the scope of draft trying to define minimal
>> ESP. Saying that in contrained devices which have very few SPIs the
>> SPIs can be allocated using some other method than random is in scope
>> of the this draft.
>
> Agreed.
>
>> On the other hand sender is REQUIRED to send sequence numbers in such
>> way they are monotonically incrementing (not necessarely by one), and
>> if it has any kind of other monotonically incrementing counter like
>> clock, it can use that to generate the sequence numbers and get rid of
>> the requirement to store outgoing sequence number to the flash.
>
> Wouldn't not incrementing by one screw up the windoz sizes of receiving
> ends? Eg if they received #64, they might accept 65-128 so receiving 300
> might just make them do more work or effectively have no window?
>
>> I have not actually never seen anybody sending dummy packets or TFC
>> padding packets in any implementations.
>
> Yup. Linux supports it. With libreswan you can configure tfc= with a
> value of zero meaning pad to MTU. We haven't yet enabled this by default,
> since there are reasons for and against it. It's much better for privacy
> obviusly, but if this is going of mobile data, you are paying for the
> padding.
>
>> not even sure which implementation support for sending dummy packets.
>
> That I don't know either. although there are already so many "dumb" DPD
> packets, we sort of have this already over port 4500 :)
>
>> So as those are not really used in non-constrained devices
>
> Hmm, I guess the Lantronix Xport Pro does not count as constrained?
> Because it does run Linux and libreswan in 8MB SDRAM with NOMMU :)
>
> I still have to read the full document before I decide if I am in favour
> of adopting or not.
>
> Paul
>
> ___
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [Suit] https://tools.ietf.org/html/draft-urien-suit-security-classes-00

[Mohit Sethi M]

LWIG has time available on its agenda.

Let us (Zhen and I) know if you intend to present in LWIG tomorrow 
(Wednesday 11:20 - 12:20).

--Mohit

On 11/6/18 1:05 PM, Carsten Bormann wrote:
> Hi Pascal,
>
> One document that is intended to collect classifications like the one you 
> propose here is the lwig terminology:
>
> RFC 7228
> draft-bormann-lwig-7228bis
>
> Maybe we can ask the LWIG chairs whether there is some space on the agenda?
>
> (Assuming that the classification here is not so specific to SUIT that it 
> needs to be done in that WG.)
>
> Grüße, Carsten
>
>
>
>
>> On Nov 6, 2018, at 12:25, Pascal Urien  wrote:
>>
>> Hi All
>>
>> The purpose of this draft is to evaluate the resistance of software to 
>> hacking according to various criteria based on current state of art
>>
>> if room on thrusday session i will be happy to shorly present this idea
>>
>> Rgs
>>
>> Pascal Urien
>> ___
>> Suit mailing list
>> s...@ietf.org
>> https://www.ietf.org/mailman/listinfo/suit
> ___
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Meeting Minutes from LWIG @ IETF 103

[Mohit Sethi M]

Hi all,

Thank you for participating in the LWIG session at IETF 103. A special 
thank you to Lijo Thomas and Ari Keränen for taking the minutes and to 
Rahul for serving as the jabber scribe.

The minutes from IETF 103 are uploaded here:

https://datatracker.ietf.org/meeting/103/materials/minutes-103-lwig-00

Feel free to report any issues within one week.

We would also use this opportunity to encourage others in the working 
group to serve as minute takers and jabber scribes. Taking notes does 
not mean writing down every word that is spoken. It is meant for 
summarizing important questions and decisions made in the working group.

Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Fwd: Review of draft-ietf-lwig-curve-representations-00 by crypto review panel

[Mohit Sethi M]

Hi all,

We have received the following detailed review of 
draft-ietf-lwig-curve-representations from Stanislav Smyshlyaev on behalf of 
the Crypto Review Panel.

Thank you Stanislav for the excellent review. It would be great if the authors 
can address his feedback and submit a new version.

Please feel free to chime in if you have any additional feedback on this 
document at this stage.

Zhen and Mohit


 Forwarded Message 
Subject:Review of draft-ietf-lwig-curve-representations-00 by crypto 
review panel
Date:   Tue, 11 Dec 2018 07:50:11 +0200
From:   Stanislav V. Smyshlyaev <mailto:smys...@gmail.com>
To: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>, 
sur...@kaloom.com<mailto:sur...@kaloom.com> 
<mailto:sur...@kaloom.com>, 
zhencao.i...@gmail.com<mailto:zhencao.i...@gmail.com> 
<mailto:zhencao.i...@gmail.com>, Alexey Melnikov 
<mailto:aamelni...@fastmail.fm>


Good afternoon,

Please find below the review of the document made on behalf of Crypto Review 
Panel.

I'll be happy to discuss all questions raised in the review directly via 
e-mail: smys...@gmail.com<mailto:smys...@gmail.com>


Document: draft-ietf-lwig-curve-representations-00
Reviewer: Stanislav Smyshlyaev
Review Date: 2018-11-26
Summary: Revision needed

The document “Alternative Elliptic Curve Representations” contains procedures 
and formulae of representing Montgomery curves and (twisted) Edwards curves in 
short Weierstrass form.
The reviewer believes that the document is very helpful and can be used by 
developers implementing ECC operations in real-world applications.
The reviewer has verified all decimal numbers (and hexadecimal numbers, where 
they are provided in the draft) and does not have any concerns besides the 
following ones.

Since some of the concerns seem to be important enough for the overall 
document, the reviewer recommends to send an updated version of the draft to 
Crypto Review Panel for a new review.

The review was made for draft-ietf-lwig-curve-representations-00. During the 
review process an updated version draft-ietf-lwig-curve-representations-01 was 
published – some comments about the -01 version can be found in the end of the 
current review.

Comments:
1) Section C.2: The mapping from Weierstrass curves to Montgomery curves is not 
defined in the current version. The mapping from Weierstrass to Montgomery 
cannot usually be described as shortly as others, but maybe it could still be 
useful here. For example, the root of x^3+ax+b in Fp could be provided 
explicitly.
2) It would be better to stress in Appendix C.1 that formulae provided there do 
not allow to get parameter a of the twisted Edwards curve equal to 1 or -1. In 
Appendix D.2 additional constant c is used that helps to obtain the curve with 
a equal to -1 (this fact by the way implies that the phrase “Here, we used the 
mapping of Appendix C.1” is inaccurate).
2a) Section D.2: The formulae (u,v) -> (c*u/v, (u-1)/(u+1)) lead to an error. 
It is not clear why it is needed to multiply by the constant c.
2b) Section D.3: The Montgomery curve Curve25519 doesn’t correspond to Twisted 
Edwards curve Edwards25519 because of (A+2)/B = (486662+2)/1 != -1.
2c) If one uses the formula from C.1 for Montgomery to Edwards mapping 
(a:=(A+2)/B and d:=(A-2)/B), she obtains that d for Edwards25519 is equal to 
486660 but not the value of d which is provided in D.3.
3) Section E.1: The isomorphic mapping between W_{a,b} and W_{a',b'} should be 
defined as a’:=a*s^4 and b’:=b*s^6, instead of a:=a'*s^4 and b:=b'*s^6. 
Otherwise the mapping is defined incorrectly and the test vectors from F.3 are 
incorrect.
4) It seems that the formula for lambda in case Q:=2P for Montgomery curve is 
wrong. According to http://hyperelliptic.org/EFD/g1p/auto-montgom.html and to 
https://eprint.iacr.org/2017/212.pdf (page 4) it should be: lambda = (3*x1^2 + 
2*A*x1 + 1)/(2*B*y1). So you need to add “B” as a factor in the denominator.
5) in Appendix D.2 it would be better to stress explicitly that we work with 
projective coordinates, otherwise the formulae do not have to be correct.

Editorial comments:
a) It seems that the text will be easier to read if the formulae for group law 
are provided in the following form (for example, for Weierstrass):
   x = lambda^2 – x1 – x2
   y = lambda * ... (at a new line, but with “and”)
   lambda = ... (again at a new line)
b) In reviewer’s opinion, the text will be easier to read if different symbols 
for coordinates of different forms of a curve are used. For example, (x,y) for 
Weierstrass, (X,Y) for Montgomery and (u,v) for Edwards. And it would be better 
to use the same symbols in different parts of the document (now (u,v) is used 
for Montgomery in A.2 and (x,y) for Montgomery in B.2).
c) The term “short Weierstrass form” is widely used in publications as is. The 
draft, however, has two variants of it – “short” Weierstrass

[Lwip] Fwd: Re: (initial triage - final disposition with rev-02) Re: Fwd: Review of draft-ietf-lwig-curve-representations-00 by crypto review panel

[Mohit Sethi M]

Forwarding this to the correct working group email address.

In future, I hope that all of you can include the correct working group email 
addressing when responding.

The reason why LWIG working group has lwip@ietf.org as its list address is not 
something that I can answer. This was much before my term as a co-chair started.

--Mohit

PS: I also hope that we won't start a discussion about correct list address 
etc. or changing lwip@ietf.org<mailto:lwip@ietf.org> to 
l...@ietf.org<mailto:l...@ietf.org>. It is what it is and our energies are 
better spent on technical work.


 Forwarded Message 
Subject:Re: (initial triage - final disposition with rev-02) Re: Fwd: 
Review of draft-ietf-lwig-curve-representations-00 by crypto review panel
Date:   Wed, 12 Dec 2018 08:24:30 +0200
From:   Stanislav V. Smyshlyaev <mailto:smys...@gmail.com>
To: Rene Struik <mailto:rstruik....@gmail.com>
CC: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>, 
l...@ietf.org<mailto:l...@ietf.org> <mailto:l...@ietf.org>, 
Николаев Василий Дмитриевич 
<mailto:nikol...@cryptopro.ru>


Dear Rene,

Thank you very much for your comments and clarifications!

Regarding the remaining questions (I'm cc'ing my colleague Vasily Nikolaev, who 
checked this issue with conversion formulae):
The formulae for conversion between twisted Edwards and Montgomery curves (as 
described in Section D.1) when used directly, doesn't seem to be able to lead 
us to twisted Edwards curve with d equal to +-1. In Section E.2 a slightly 
different formula with coefficient “c” is used which helps us to achieve this - 
and it's good. Maybe it will be better to add some explanations for this in 
text (or to stress explicitly that in E.2 we use another formula and it is OK, 
so readers are not confused).

The same could be applied for formulae for conversion between Weierstrass and 
Montgomery curves in sections D.2 and E.2 respectively. In D.2 we have 
coefficient B in denominator, while this coefficient is absent in formulae in 
E.2.

I believe that these issues are worth to be clarified in the text.

Best regards,
Stanislav Smyshlyaev, Ph.D.
CISO, CryptoPro LLC


вт, 11 дек. 2018 г. в 17:36, Rene Struik 
mailto:rstruik@gmail.com>>:
Hi Stanislav:

Thanks for your review.

Some brief initial feedback now; final disposition will be with rev02. (One my 
"to dos prior to 2018-end" is to add test vectors to a draft-02 version that I 
have had on my machine since Nov 15th. That version also includes some minor 
editorial massaging.)

BTW - all calculations (including isogenies) were done in Sage and write-up is 
based on an extensive LaTeX document with curve constructions for personal use. 
I will double-check everything prior to releasing rev-02.

On 12/11/2018 7:46 AM, Mohit Sethi M wrote:

Hi all,

We have received the following detailed review of 
draft-ietf-lwig-curve-representations from Stanislav Smyshlyaev on behalf of 
the Crypto Review Panel.

Thank you Stanislav for the excellent review. It would be great if the authors 
can address his feedback and submit a new version.

Please feel free to chime in if you have any additional feedback on this 
document at this stage.

Zhen and Mohit


 Forwarded Message 
Subject:Review of draft-ietf-lwig-curve-representations-00 by crypto 
review panel
Date:   Tue, 11 Dec 2018 07:50:11 +0200
From:   Stanislav V. Smyshlyaev <mailto:smys...@gmail.com>
To: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>, 
sur...@kaloom.com<mailto:sur...@kaloom.com> 
<mailto:sur...@kaloom.com>, 
zhencao.i...@gmail.com<mailto:zhencao.i...@gmail.com> 
<mailto:zhencao.i...@gmail.com>, Alexey Melnikov 
<mailto:aamelni...@fastmail.fm>


Good afternoon,

Please find below the review of the document made on behalf of Crypto Review 
Panel.

I'll be happy to discuss all questions raised in the review directly via 
e-mail: smys...@gmail.com<mailto:smys...@gmail.com>


Document: draft-ietf-lwig-curve-representations-00
Reviewer: Stanislav Smyshlyaev
Review Date: 2018-11-26
Summary: Revision needed

The document “Alternative Elliptic Curve Representations” contains procedures 
and formulae of representing Montgomery curves and (twisted) Edwards curves in 
short Weierstrass form.
The reviewer believes that the document is very helpful and can be used by 
developers implementing ECC operations in real-world applications.
The reviewer has verified all decimal numbers (and hexadecimal numbers, where 
they are provided in the draft) and does not have any concerns besides the 
following ones.

Since some of the concerns seem to be important enough for the overall 
document, the reviewer recommends to send an updated version of the draft to 
Crypto Review Panel for a new review.

The review was made for draft-ietf-lwig-curve-representations-00. During the

[Lwip] Agenda Items for IETF 104

[Mohit Sethi M]

Dear all,

Some of you have already sent in a request for presentation time during 
the LWIG session @ IETF 104. Thank you!

For those who haven't, please send Zhen and I requests for presentation 
slots.  We have a 1 hour session on Tuesday, March 26, between 
11:20-12:20 in room Athens/Barcelona.

Don't forget to include the title of your presentation, related drafts, 
and the approximate amount of time that you need.

Please also let us know if you plan to present remotely.

Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Preliminary agenda for LWIG @ IETF 104

[Mohit Sethi M]

Dear all,

Based on the presentation requests received so far, we have prepared the 
preliminary agenda for LWIG @ IETF 104.

The agenda is now available online: 
https://datatracker.ietf.org/meeting/104/materials/agenda-104-lwig-00 and 
copied below for convenience.

Zhen and Mohit

LWIG WG Meeting
IETF 104 - Prague

Room: Athens/Barcelona
Date: Tuesday, March 26, 2019, 11:20-12:20
Chairs:   Zhen Cao, Mohit Sethi
AD:   Suresh Krishnan
Presentation materials: https://datatracker.ietf.org/meeting/104/session/lwig

===

Meetecho for remote participants: https://www.meetecho.com/ietf104/lwig/
Etherpad for notes: 
https://etherpad.tools.ietf.org/p/notes-ietf-104-lwig?useMonospaceFont=true

1.  Administrative and Agenda Bashing (Chairs, 5 min)
Note Well, Note Takers, Jabber Scribes, Agenda Bashing

LWIG Agenda:
--

2.  Carlos: TCP Usage Guidance in the Internet of Things (IoT) (10 min)
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-05

3.  Rahul: Neighbor Management Policy for 6LoWPAN  (15 min)
https://tools.ietf.org/html/draft-ietf-lwig-nbr-mgmt-policy-03

4.  Rene (remote): Alternative Elliptic Curve Representations (10 min)
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-01

5. John: Comparison of CoAP Security Protocols (15 min)
   https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-03

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Meeting Minutes for LWIG @ IETF 104

[Mohit Sethi M]

Hi all,

Thank you for participating in the LWIG session at IETF 104. A special 
thank you to Jiye Park for writing the detailed minutes of the meeting, 
and to Francesca Palombini for serving as the jabber scribe.

The minutes from IETF 104 are uploaded here:

https://datatracker.ietf.org/meeting/104/materials/minutes-104-lwig-00

Feel free to report any issues within one week.

Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] WGLC for draft-ietf-lwig-tcp-constrained-node-networks

[Mohit Sethi M]

Dear all,

This email starts the WGLC for draft-ietf-lwig-tcp-constrained-node-networks
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-07

Many of you have already provided useful feedback that has helped us 
improve this document. If you have any remaining concerns or issues, 
please comment on the mailing list before the WGLC expires. The WGLC 
will end in four weeks on 30th April 2019.

If you have previously reviewed the document and feel that it is ready 
for IESG review, please express support on the mailing list. It helps 
the document shepherd to move the document forward.

This WGLC will also be forwarded to the TCMP mailing list. Thank you 
authors for your hard work.

Zhen and Mohit


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued"

[Mohit Sethi M]

Dear all,

Thank you for all those who provided feedback during the call for 
adoption of this document. There is clearly interest in doing this work 
as long as the WG does not change ESP and only defines a minimal profile.

Based on the feedback, comments, and support; the document is now adopted.

@Authors: please submit as a working group document.

Zhen and Mohit

On 2/14/19 5:33 PM, Daniel Migault wrote:
> Hi Paul,
>
> Thanks for the review. From your response [1] I understand we can proceed to 
> the adoption of the document if no changes are performed on ESP. This 
> condition is fully stated in the abstract [2] as well as in the charter [3].  
> As a result, I believe the draft is ready for adoption. Of course we welcome 
> further reviews!
>
> Please find inline my responses to the current review. If the changes address 
> your concern, I am happy to update the draft with the proposed text. I am 
> happy to take more reviews as you volunteered to provided further reviews. 😉
>
> For full transparency, my understanding of the current reviews is that they 
> will result in minor -- thought useful -- changes to the current draft. The 
> concerns you expressed are in my opinion mostly due to a confusion with 
> another draft "ESP Header Compression and Diet-ESP" 
> (draft-mglt-ipsecme-diet-esp). This draft is discussed in ipsecme not in lwig 
> and so are sort of out of scope. All comments are answered below.
>
> Yours,
> Daniel
>
> [1]
> """
> If the document is defining a minimum/battery optimized ESP configuartion, I 
> have no problems with it and I will review further text and welcome adoption. 
> If it makes changes to the ESP protocol, then I think there should be more 
> discussion before adoption.
> """
>
> [2]
> """
>This document describes a minimal implementation of the IP
> Encapsulation Security Payload (ESP) defined in RFC 4303.
> [...]
>This document does not update or modify RFC 4303, but provides a
> compact description of how to implement the minimal version of the
> protocol.  If this document and RFC 4303 conflicts then RFC 4303 is
> the authoritative description.
> """
>
> [3]
> """
> "LWIG is chartered to provide guidance on lightweight implementations.
> Almost all drafts in this WG are informational in nature and we don't intend
> to change existing standards or define new ones.
> """
>
> [4] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06
>
> -Original Message-
> From: Paul Wouters 
> Sent: Wednesday, February 13, 2019 1:09 PM
> To: Daniel Migault 
> Cc: Mohit Sethi M ; Tero Kivinen 
> ; Heinrich Singh ; lwip@ietf.org
> Subject: Re: [Lwip] [IPsec] The LWIG WG has placed 
> draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued"
>
> On Tue, 12 Feb 2019, Daniel Migault wrote:
>
>> I am wondering what is currently the status of the draft. Feel free to let 
>> me know if I something is expected on my side.
> I cannot answer that question, I'll leave that to the chairs, but I do have 
> several strong reservations on the document. Especiallt with the complex 
> framework to reduce a number of bytes.
>
> 
> I understand that the strong reservations concern the modification of ESP as 
> well as the compression framework. Such reservations do not apply here. I 
> believe this statement is clearly mentioned in the abstract [1] as well as in 
> the lwig charter[2].  I think what you're referring to is another draft in 
> ipsecme "ESP Header Compression" (draft-mglt-ipsecme-diet-esp) [3] which does 
> not apply here.  We think the abstract of the document states that clearly, 
> but we're happy to state this point stronger if you feel that's necessary.
>
> To be clear:
> * draft-mglt-lwig-minimal-esp does not modify ESP
> * draft-mglt-lwig-minimal-esp  does not reduce any bytes of ESP
> * draft-mglt-lwig-minimal-esp does not describe any framework.
>
> [1]
> """
>This document describes a minimal implementation of the IP
> Encapsulation Security Payload (ESP) defined in RFC 4303.
> [...]
>This document does not update or modify RFC 4303, but provides a
> compact description of how to implement the minimal version of the
> protocol.  If this document and RFC 4303 conflicts then RFC 4303 is
> the authoritative description.
> """
>
> [2]
> """
> If the document is defining a minimum/battery optimized ESP configuartion, I 
> have no problems with it and I will review further text and welcome adoption. 
> If it makes changes to

Re: [Lwip] Fwd: I-D Action: draft-ietf-lwig-curve-representations-04.txt

[Mohit Sethi M]

Hi Rene,

In Section 1, the draft says:

 Montgomery curve, and of points of Edwards25519, a so-called twisted
   Edwards curve, which are both specified in 
[RFC7748]

What about referencing RFC 8032: https://tools.ietf.org/html/rfc8032?

A lot of normative parts are currently in the appendix. Wouldn't it make sense 
to move them into the actual document body. I looked at RFC 7748 for example 
and it defines Curve25519 in the main body: 
https://tools.ietf.org/html/rfc7748#section-6.1. It is good to keep the example 
computations in  Appendix E.3 and Appendix G.3, see Appendix K as the document 
currently does.

In Section 5, wouldn't it make sense to mention that while re-using the same 
code base has advantages, it can also negatively affect the performance in 
terms of the computation time?

--Mohit

On 4/19/19 5:50 PM, Rene Struik wrote:

Dear colleagues:

I slightly updated the draft. Main changes: (technical) I added COSE parm 
requests (Section8.4-8.6); (editorial) some tiny word-smything and addition of 
two more references.

Of course, more references are possible, but - apart from that - I think the 
document is technically ready.

FYI - Stanislav Smyshlyaev and Vasily Nikolaev did kindly review the previous 
version of this draft and verified all numbers, formulas, etc. Their main 
editorial comment was that the document could use more references. {I will see 
whether I can find more references, or perhaps I should see if I can post a 
full technical paper on all kinds of curve formulas,, tricks, etc. This will 
take some time, though. This should not stop proceeding with this, imho.}

Best regards, Rene


 Forwarded Message 
Subject:[Lwip] I-D Action: draft-ietf-lwig-curve-representations-04..txt
Date:   Fri, 19 Apr 2019 07:33:44 -0700
From:   internet-dra...@ietf.org
Reply-To:   lwip@ietf.org
To: i-d-annou...@ietf.org
CC: lwip@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Light-Weight Implementation Guidance WG of the 
IETF.

Title : Alternative Elliptic Curve Representations
Author : Rene Struik
Filename : draft-ietf-lwig-curve-representations-04.txt
Pages : 61
Date : 2019-04-19

Abstract:
This document specifies how to represent Montgomery curves and
(twisted) Edwards curves as curves in short-Weierstrass form and
illustrates how this can be used to carry out elliptic curve
computations using existing implementations of, e.g., ECDSA and ECDH
using NIST prime curves.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-04
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-curve-representations-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] I-D Action: draft-ietf-lwig-curve-representations-05.txt

[Mohit Sethi M]

Hi Rene,

Thanks for addressing the comments. I wasn't looking for exact computational 
cost comparisons and rather some hints on what to expect if I re-use the 
underlying implementation of a different curve. Your statement "the overall 
cost differential is somewhere in the interval [1.00 - 1.25]" is useful (and 
perhaps sufficient).

I had one remaining suggestion. RFC 7942 (https://tools.ietf.org/html/rfc7942) 
describes how to improve awareness of running code. Perhaps you could add a 
section on implementations of Wei25519: https://github.com/ncme/c25519 and that 
tinydtls https://github.com/ncme/tinydtls now supports Wei25519.

--Mohit

On 5/15/19 10:21 PM, Rene Struik wrote:
Dear colleagues:

I slightly updated the draft to address Mohit Sethi's comment [1] on trade-offs 
between code reuse and computational efficiency. To this end, I added a little 
section (now Section 6) on "implementation considerations" - see[2].

As already suggested in [3], I did not give an explicit computational cost 
comparison, since this is highly device and application dependent and alone 
would not do justice other considerations that come into play when deciding on 
a crypto implementation strategy.

Best regards, Rene

[1]https://mailarchive.ietf.org/arch/msg/lwip/DQ5oYwFusICBx_llv1Wenc1EZCQ
[2] 
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-05#section-6
[3] https://mailarchive.ietf.org/arch/msg/lwip/vSnhe1lO03AfLONxHGmixuP4z64

On 5/15/2019 3:04 PM, internet-dra...@ietf.org 
wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Light-Weight Implementation Guidance WG of the 
IETF.

Title   : Alternative Elliptic Curve Representations
Author  : Rene Struik
Filename: draft-ietf-lwig-curve-representations-05.txt
Pages   : 62
Date: 2019-05-15

Abstract:
   This document specifies how to represent Montgomery curves and
   (twisted) Edwards curves as curves in short-Weierstrass form and
   illustrates how this can be used to carry out elliptic curve
   computations using existing implementations of, e.g., ECDSA and ECDH
   using NIST prime curves.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-05
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-curve-representations-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip



--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] WGLC for draft-ietf-lwig-curve-representations

[Mohit Sethi M]

Dear all,

This email initiates the working group last call (WGLC) for 
draft-ietf-lwig-curve-representations: 
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-08

The draft has an implementation and has been reviewed by the Crypto 
Review Panel (Stanislav Smyshlyaev).

If you have any remaining concerns or issues, please comment on the 
mailing list before the WGLC expires on August 20, 2019. If you have 
previously reviewed the document and feel that it is ready for IESG 
review, please express support on the mailing list. It helps the 
document shepherd to move the document forward.

Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Review of draft-ietf-lwig-tcp-constrained-node-networks-04

[Mohit Sethi M]

Hi Ilpo and Markku,

Could you confirm that -08 version of the draft addresses all your 
concerns. We will then send it to the IESG for review.

Zhen and Mohit

On 6/5/19 11:58 AM, Carles Gomez Montenegro wrote:
> Hi Ilpo,
>
> (CC'ing also TCPM.)
>
> First of all, sorry for the delay in our response.
>
> Thank you very much for reviewing the draft again, and for answering our
> questions. Your comments have been very useful to improve the quality of
> the document. Our updates can be found in revision -08.
>
> Please find below our inline responses to your comments.
>
>> On Sun, 10 Mar 2019, Carles Gomez Montenegro wrote:
>>
 General Comments / Structure
 
>> I've read the document (-07) through once again, and in general I got
>> a feeling that it has improved substancially!
> Thank you!
>
>>> In the new draft version, in some cases, we have tried to be more
>>> specific
>>> (e.g. ?message overhead?, ?memory overhead?, etc.). However, in some
>>> other
>>> cases the context may help to better determine the scope of ?overhead?,
>>> or
>>> ?overhead? relates with all the dimensions you listed (and for
>>> simplicity,
>>> we prefer to keep just ?overhead?).
>> I didn't find unqualified "overheads" a problem anymore either (that is,
>> in case there were some as I didn't even notice them anymore).
> Thanks for your confirmation.
>
 Small Points
 

 Sec 3.2 Usage Scenarios, 3rd para: I fail to get the point of this
 paragraph. There are two distinct points about the environment:
 middleboxes on path and asymmetry in end point capabilities. No
 implications about bringing these two in particular up in the same
 paragraph are mentioned. That is, why I must note the asymmetry when
 there's a middlebox?
>>> Because the middlebox will often be transparent to TCP (but not to other
>>> protocols). Basically, the presence of such middleboxes is a major
>>> motivation for use of TCP in IoT environments (e.g. RFC 8323).
>> I still don't see the connection between a middlebox requiring use of
>> TCP and that I must note asymmetry in the scenario. But this not all that
>> important part of the text anyway so I guess it could be left like that.
>>
>> There's, however, duplication between the 1st and the last paragraphs
>> (and also somewhat with this 3rd paragraph text now that I look).
> In -08, we have merged part of the first and the third paragraph, which
> helped reduce redundancy. After this change, we believe that the first and
> the last paragraphs (of section 3.2) do not contain duplicated content.
>
 4.3.2 SACK

 IMHO, SACK should be subsection of loss recovery or 4.3.1
 should be retitled to only FR/FR.
>>> Yes, we agree with the suggestion, and prefer to make SACK a subsection
>>> of
>>> 4.3.1.
>>>
 Out-of-order queue handling is unrelated to SACK, should be
 covered somewhere else? There is implicit complexity & TCB
 impact when the flow may have >1 MSS wnd, maybe group all these
 (when not related to a particular mechanism that has its own
 discussion somewhere) under a single section).
>>> Not sure if the current wording may lead to different understandings,
>>> but
>>> out-of-order is mentioned here to denote the fact that a few segments
>>> may
>>> be lost and the receiver will need to inform about the data blocks
>>> actually received.
>> "The receiver supporting SACK will need to managed the reception of
>> possible out-of-order received segments, requiring sufficient buffer
>> space."
>>
>> This text seems to imply that because of SACK, managing ofo segments is
>> necessary but it is a feature that is needed also w/o SACK when TCP
>> supports multi-segment window. So any loss recovery regardless of SACK
>> will need to deal with that. What SACK adds to that on the receiver
>> side, is keeping track of the SACK blocks to send back.
> The text (after removing the SACK mention) is now before the SACK
> subsection. We have also added your point on the SACK-specific tasks to be
> done by a receiver supporting SACK.
>
 No sender-side SACK aspect covered?
>>> We currently have:
>>> ?a sender (having previously sent the SACK-Permitted
>>> option) can avoid performing unnecessary retransmissions, saving
>>> energy and bandwidth, as well as reducing latency.?
>>> Is there any particular aspect you think should be added ?
>> When the sender get SACK blocks from the receiver in ACKs, it need to
>> bookkeep the per seq/segment state to avoid sending the particular
>> data/segments again during the recovery.
>>
>> But perhaps there just isn't a convincing IoT scenario for the device to
>> be sending enough data to benefit from the sending side SACK in the first
>> place?
> Well, perhaps in some cases a device might keep a relatively large file
> (e.g. containing sensor readings taken over a relatively long time
> interval). For the sake of completeness, we have added your point on the
> 

Re: [Lwip] WGLC for draft-ietf-lwig-curve-representations

[Mohit Sethi M]

Hi all,

The WGLC has concluded. There were no objections. There was support from Kepeng 
during the WGLC and from Olaf and Nikolas earlier on in the process.

We will now do the shepherd writeup and then send it to the IESG.

Zhen and Mohit

On 8/20/19 5:05 AM, Kepeng Li wrote:
I think the draft is in a good shape, and it is ready for IESG review.

Thanks,

Kind Regards
Kepeng

--
Subject:
[Lwip] WGLC for draft-ietf-lwig-curve-representations
Date:
Tue, 6 Aug 2019 14:27:20 +
From:
Mohit Sethi M <mailto:mohit.m.se...@ericsson.com>
To:
lwip@ietf.org<mailto:lwip@ietf.org> <mailto:lwip@ietf.org>, Zhen 
Cao <mailto:zhencao.i...@gmail.com>, Stanislav V. 
Smyshlyaev <mailto:smys...@gmail.com>


Dear all,

This email initiates the working group last call (WGLC) for 
draft-ietf-lwig-curve-representations: 
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-08

The draft has an implementation and has been reviewed by the Crypto Review 
Panel (Stanislav Smyshlyaev).

If you have any remaining concerns or issues, please comment on the mailing 
list before the WGLC expires on August 20, 2019. If you have previously 
reviewed the document and feel that it is ready for IESG review, please express 
support on the mailing list. It helps the document shepherd to move the 
document forward.

Zhen and Mohit

___
Lwip mailing list
Lwip@ietf.org<mailto:Lwip@ietf.org>
https://www.ietf.org/mailman/listinfo/lwip




--

email: rstruik@gmail.com<mailto:rstruik@gmail.com> | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



___
Lwip mailing list
Lwip@ietf.org<mailto:Lwip@ietf.org>
https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [T2TRG] QUIC on IoT boards

[Mohit Sethi M]

Hi Eliot,

I find your example rather disturbing. I am sure a dad does not want everyone 
else on the Internet to see what his daughters toy is exfiltrating. You would 
need encryption for that?

I am totally with you on the need for knowing what's inside the device and how 
is the device behaving. RFC 8576 identifies this in Section 5.6 'Verifying 
Device Behavior': https://tools.ietf.org/html/rfc8576#section-5.6

--Mohit

On 1/20/20 7:00 PM, Eliot Lear wrote:
Hi Lars,

On 20 Jan 2020, at 16:08, Lars Eggert mailto:l...@eggert.org>> 
wrote:

Hi,

On 2020-1-20, at 16:52, Eliot Lear mailto:l...@cisco.com>> 
wrote:
• I only want that device speaking protocols it was designed to speak.

It’s that last one that has me worried from a long term perspective with QUIC.

I don't quite follow. Surely if someone ships an IoT device that uses QUIC for 
communication, that *is* a device "designed to speak" QUIC?

QUIC is the substrate.  It’s the applications atop that really are at issue.

If the stack hides means to determine directionality, as it does, and 
applications, as it does, we should take a pause to determine how we would 
detect whether it has services running on it that aren’t intended, as has 
happened all too often.[1]. These are use cases that QUIC was not designed to 
address.

So [1] is a case where the firmware web server had an embarrassing bug - it's 
not an example where someone hacked in and ran another service in addition to 
(or instead of) the manufacturer one. So that's not a fitting example for the 
point you are trying to raise.

Yes it is.  It’s a misconfiguration that could easily be blocked with the 
existing TCP model, and it was in a great many environments.  With QUIC, 
spotting these sorts of misconfigurations may prove more difficult.  Not 
impossible, mind you.


We can certainly debate whether more encryption and/or obfuscation makes 
network-based threat detection harder or not. It might even be the case that 
there are wrinkles in the IoT space that aren't there in the broader web space, 
in terms of appropriateness or trade-offs. But in general, I think this issue 
is a general one, and not IoT-specific.

Let’s agree that IoT is a pretty big category.  I gave you two very specific 
examples of where TLS 1.3 itself is more of a hindrance than a help because of 
the nature of the system in play.  Those examples comprise a common case for 
IoT.  I would never say the same thing about browser based communications.  
Because IoT is such a big category, there may be cases where privacy issues 
either conflict with or will overtake other concerns.

Let me give you a good example of conflict:

Dad wants to know what information daughter’s Internet toy is exfiltrating and 
to whom.  Does the toy have a camera or a microphone that wasn’t advertised in 
the documentation, as happened with one particular device[1]?  On the other 
hand, dad would very much like whatever information is being shared to only be 
shared with authorized parties.

Want more conflict?  Let’s assume that the CPAP machine I described above uses 
my local wifi and something goes wrong, and the patient dies.  The next of kin 
want the data, but the CPAP service owner refuses.  In fact, the CPAP service 
owner even refuses to describe what data is being collected.  On the other 
hand, a patient would very much like whatever information is being shared to 
only be shared with authorized parties (2nd verse, same as the first).

Now… some of this is encryption and some of this is transport, but the QUIC and 
H3 have intentionally intertwined the two to attempt to reduce middle box 
interference.  That very interference is what a great many IoT deployments need.


On the other hand, we do want the IoT community to leverage the best that the 
Web community has delivered, if and when it is appropriate, and even when the 
whole package is not, it is best that they adopt the components that are, so 
that they don’t end up having to repeat old mistakes.

Exactly. Given the ever increasing amount of engineering cycles that are being 
poured into QUIC, the IoT community should absolutely try to leverage that to 
the max, where it can.

But the community also requires guidance to understand where it is appropriate, 
and quite frankly I don’t think we know that yet.

Eliot

[1] 
https://edition.cnn.com/2019/02/20/tech/google-nest-microphone-secret/index.html




___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] CoAP Implementation Guidance and IPV6_RECVERR

[Mohit Sethi M]

Hi Christian,

Yes, we (Zhen and I) as chairs are definitely interested in finishing this 
document. There is plenty of valuable information there.

@Authors (Matthias, Olaf, Carsten): What do you think? Do you need any help to 
revive and finish this document?

Zhen and Mohit

On 3/10/20 6:55 PM, Christian Amsüss wrote:

Hello CoRE and LWIG,

(retransmitting as I missed the LWIG list name oddity, please reply to
this to keep the thread intact)

working on the portability of my aiocoap library I had trouble reusing
the IPV6_RECVERR option recommended in draft-ietf-lwig-coap-06[1], and
found that it does not seem to be portable at all; unlike the
IPV6_RECVPKTINFO option recommended in the paragraph above, IPV6_RECVERR
is only mentioned in the IETF scope in this document, and otherwise
appears to be proprietary to Linux.

Is that a known shortcoming? Are there any more portable mechanisms that
can be recommended instead?

Best regards
Christian

[1]: I see has expired -- is there interest in having this continued? It
 has been valuable so far





___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Fwd: Reminder: Survey on planning for possible online IETF meetings

[Mohit Sethi M]

You have a chance to influence how the upcoming IETF meetings for this year are 
organized. Please answer the survey if you haven't already. See the details 
below.

Here is the link for your convenience: https://www.surveymonkey.com/r/5328FFJ

--Mohit

Begin forwarded message:

From: IETF Executive Director 
mailto:exec-direc...@ietf.org>>
Subject: Reminder: Survey on planning for possible online IETF meetings
Date: May 4, 2020 at 3:03:35 AM EDT
To: "IETF Announcement List" 
mailto:ietf-annou...@ietf.org>>
Reply-To: ietf108plann...@ietf.org

This is a reminder that we need the IETF community to help us plan for the 
possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 
may not be able to go ahead in person.  You can help us with this by filling 
out the following survey:

https://www.surveymonkey.com/r/5328FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to complete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims
3. Replacing a cancelled in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that you 
explicitly provide.

Thank you in advance for your help.

--
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Publication has been requested for draft-ietf-lwig-minimal-esp-05

[Mohit Sethi via Datatracker]

Mohit Sethi has requested publication of draft-ietf-lwig-minimal-esp-05 as 
Informational on behalf of the LWIG working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Publication has been requested for draft-ietf-lwig-curve-representations-08

[Mohit Sethi via Datatracker]

Mohit Sethi has requested publication of 
draft-ietf-lwig-curve-representations-08 as Informational on behalf of the LWIG 
working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip