[Lwip] Eric Rescorla's No Objection on draft-ietf-lwig-crypto-sensors-05: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-lwig-crypto-sensors-05: No Objection

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-crypto-sensors/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   both parties, there are some remaining vulnerabilities that may or
   may not be acceptable for the application in question.  For example,
   leap-of-faith or trust-on-first-use based pairing methods assume that
This is not strictly correct. SAS is an example that requires neither of these.

   the attacker is not present during the initial setup and are
   vulnerable to eavesdropping or man-in-the-middle (MitM) attacks.
You might be interested in
Secure In-Band Wireless Pairing
Shyamnath Gollakota, Nabeel Ahmed, Nikolai Zeldovich, and Dina Katabi
USENIX Security 2011, San Francisco, CA, August 2011.

   not completely secure method where the last few digits of the
   identity are printed on a tiny device just a few millimeters across.
   Alternatively, the packaging for the device may include the full
This is subject to trivial attacks no?

      Igrp = h(Pdev1|Pdev2|...|Pdevm)
1.Where do you use Idev?

This does work, I guess, but requires you to have the public keys of every
device. Why not use a Merkle tree?

      filtering, storage and other actions, again without impacting the
      security of the data being transmitted or stored.
It's not clear from this text why these benefits obtain (caching especially).
Is that because the data is in self-contained PDUs which can be interpreted
even if there is transport/network level modification?

      different symmetric key algorithms such as AES, triple DES and
      SkipJack.  It provides RSA as an asymmetric key algorithm.  Parts
      of the library were written in AVR-8 bit assembly language to
Skipjack? 3DES? Back to the future!

      of a large variety of cryptographic algorithms.  This not only
      includes RSA and ECC, but also pairing based asymmetric
      cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures
It might be useful to know whether it's just the NIST curves or also X25519 and
X448.

      based public key cryptography on sensor networks.  It is written
      in nesC programming language and as such is designed for specific
      use on TinyOS.  However, the library can be ported to standard C
What is the nesC programming language? Maybe a cite?

      implementation as well as X509 certificate handling.  The library
      provides an intuitive API for developer with a minimal code
      footprint.  It is intended for various ARM platforms such as ARM
"intuitive" seems a bit subjective.

   +--------------+------------------------+---------------------------+
   | 2048         |                1587567 |                     1,280 |
   +--------------+------------------------+---------------------------+
The time value would be easier to read if you used comma separators, as you did
with memory footprint.

   In Table 2 we present the results obtained by manually porting
   TinyECC into C99 standard and running ECDSA signature algorithm on
   the Arduino Uno board.  TinyECC supports a variety of SEC 2
Nit: "the ECDSA"

   | secp192k1   |          3425 | 1008            |              1536 |
   | secp192r1   |          3578 | 1008            |              1536 |
   +-------------+---------------+-----------------+-------------------+
Note: IETF's minimal size is 256-bit and we also wouldn't use any of the k1
curves probably.

Do you have a cite for the key length comparisons. Opinions vary a bit here.
And I understood the consensus to be that 192-bit was rather stronger than 1536.

   | NIST K233       |         1736 | 3675           |            2048 |
   | NIST B233       |         4471 | 3261           |            2048 |
   +-----------------+--------------+----------------+-----------------+
You should use the same naming convention as with the precious tables.

   that the IETF community uses these curves for protocol specification
   and implementations.
I'm confused by this statement. I would in fact expect X25519 to be faster, but
your table 6 show Relic out performing this:

NIST B233 | 6100 | 2737 | 2048 |

   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
You should probably note that RSA key pair generation is very expensive
compared to signing, whereas ECDSA key pair generation is quite cheap compared
to signing (it is a fixed-base operation).

   Sequence numbers can wrap-around at their maximum value and,
   therefore, it is essential to ensure that sequence numbers are
Nit: no hyphen in wrap around because it' sbeing used as a verb.

      time it passes through an application level entity, it is not
      clear that there are attacks beyond denial-of-service.
This is very dependent on exactly how you build the data object protection
protocol.

   ability to scale to hundreds of millions of devices, let alone
   billions.  But the authors do not believe scaling is an important
   differentiator when comparing the solutions.
I don't believe about PKs not scaling is true at this point. Even if you don't
count TLS, here are several widely used PK-based IM protocols.