ietf
[Top] [All Lists]

RE: [Dtls-iot] Last Call: <draft-ietf-dice-profile-14.txt> (TLS/DTLS Profiles for the Internet of Things) to Proposed Standard

2015-09-08 15:14:21
Hi, Hannes,

I see your point about preprocessor directives to derive different versions
of binaries based on the same code. The point I was trying to make was
different though. When I said " the same stack could be used for scenarios
outside of IoT", I meant at the same time. This can happen either because a
device participates simultaneously in both the IoT and the general domain
(using mainstream IETF protocols), or because the lines between both become
blurry. I believe in the future we will see more and more of the lines
becoming blurrier as mainstream protocols become better profiled and/or
adapted for certain IoT scenarios (as we've seen with other industries in
the past).

Thanks for your response, and I'm glad the proposed wording is ok with you. 

Gabriel

-----Original Message-----
From: dtls-iot [mailto:dtls-iot-bounces(_at_)ietf(_dot_)org] On Behalf Of 
Hannes
Tschofenig
Sent: Tuesday, September 8, 2015 12:24
To: g_e_montenegro(_at_)yahoo(_dot_)com; ietf(_at_)ietf(_dot_)org
Cc: dtls-iot(_at_)ietf(_dot_)org
Subject: Re: [Dtls-iot] Last Call: <draft-ietf-dice-profile-14.txt>
(TLS/DTLS
Profiles for the Internet of Things) to Proposed Standard

Hi Gabriel,

thanks for your review comments.

I am OK with the proposed text changes.

A minor remark regarding the stacks used in IoT devices: In the stacks I
have
seen the developer has the possibility to include or exclude certain
features
using preprocessor directives. Even if you have the ability to re-use a
TLS/DTLS stack on devices that have nothing to do with IoT and have no
code
size restriction you will typically have to remove features for an IoT
device to
keep the code size at a reasonable level.

I am, of course, aware of devices that have very few limitations in terms
of
processing speed, RAM, and flash size. The boundaries between IoT devices
and non-IoT devices is certainly fuzzy.

Ciao
Hannes

On 09/04/2015 01:21 AM, g_e_montenegro(_at_)yahoo(_dot_)com wrote:
Overall, looks good, thanks for this work. I do have some comments.

Not sure if these are "substantive comments" as requested, but after
some discussion with some collegues we'd like to point out issues with
some of the normative language.

In particular, we suggest modifying the language here:

Hence, RFC 7366 and RFC 6066 are not applicable to this specification
and MUST NOT be implemented.

Whereas CCM and AEAD ciphers in general render RFC7366 moot, a MUST
NOT on implementation is too strong (i.e., from the intro, "This
document does not alter TLS/DTLS specifications") and potentially
damaging: the same stack could be used for scenarios outside of IoT,
where RFC7366 could still provide some benefit. As for RFC6066, a
blanket statement saying it "MUST NOT implement" is not only wrong, it
is also contradictory with other statements within this draft which
recommend other parts of RFC6066. Instead, the language should limit
itself to the specific extension of RFC6066.

Also, with other extensions the doc does not prohibit
*implementation*, but recommends against it or against its use (by
using "NOT RECOMMENDED"). So I'd change the above text to something
like:

In https://tools.ietf.org/html/draft-ietf-dice-profile-14#section-15:
OLD:
        Hence, RFC 7366 and RFC 6066 are not applicable to this
       specification and MUST NOT be implemented.
NEW:
         Hence, RFC 7366 and the Truncated MAC extension of RFC 6066
are not applicable to this
        specification and are NOT RECOMMENDED.

Similarly, in
https://tools.ietf.org/html/draft-ietf-dice-profile-14#section-10 my
suggestion would be:
OLD:
        This TLS/DTLS profile MUST NOT implement TLS/DTLS layer
compression.
NEW:
        TLS/DTLS layer compression is NOT RECOMMENDED by this TLS/DTLS
profile.

thanks,

Gabriel



On Friday, August 21, 2015 6:53 AM, The IESG 
<iesg-secretary(_at_)ietf(_dot_)org>
wrote:




    The IESG has received a request from the DTLS In Constrained
    Environments
    WG (dice) to consider the following document:
    - 'TLS/DTLS Profiles for the Internet of Things'
      <draft-ietf-dice-profile-14.txt> as Proposed Standard

    The IESG plans to make a decision in the next few weeks, and
solicits
    final comments on this action. Please send substantive comments to
the
    ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org> mailing 
lists by 2015-09-04.
    Exceptionally, comments may be
    sent to iesg(_at_)ietf(_dot_)org <mailto:iesg(_at_)ietf(_dot_)org> 
instead. In either
    case, please retain the
    beginning of the Subject line to allow automated sorting.

    Abstract


      A common design pattern in Internet of Things (IoT) deployments is
      the use of a constrained device that collects data via sensor or
      controls actuators for use in home automation, industrial control
      systems, smart cities and other IoT deployments.

      This document defines a Transport Layer Security (TLS) and
Datagram
      TLS (DTLS) 1.2 profile that offers communications security for
this
      data exchange thereby preventing eavesdropping, tampering, and
      message forgery.  The lack of communication security is a common
      vulnerability in Internet of Things products that can easily be
      solved by using these well-researched and widely deployed Internet
      security protocols.




    The file can be obtained via
    https://datatracker.ietf.org/doc/draft-ietf-dice-profile/

    IESG discussion can be tracked via
    https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ballot/


    No IPR declarations have been submitted directly on this I-D.






_______________________________________________
dtls-iot mailing list
dtls-iot(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dtls-iot



<Prev in Thread] Current Thread [Next in Thread>