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

["Gabriel Montenegro" <[e-mail]>]

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:[e-mail]] On Behalf Of Hannes
> Tschofenig
> Sent: Tuesday, September 8, 2015 12:24
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> 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, [e-mail] 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 <[e-mail]>
> > 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
> >     [e-mail] <mailto:[e-mail]> mailing lists by 2015-09-04.
> >     Exceptionally, comments may be
> >     sent to [e-mail] <mailto:[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtls-iot
> >