Please do not confuse IoT with "constrained devices/networks". The later has
been
the mayority of focus of IoT work in the IETF for almost two decades now, but it
is not how IoT is used outside the IETF - including how most non-IETF attendants
would read the term "IoT" in RFCs (not knowing the IETFs constrained history of
IoT).
For a BCP, the current draft is just sadly non-addressing the issues
of many IoT industries:
- It does not provide a sufficiently long enough deadline to raise requirements,
without them, even if industries wanted to adopt, they could not
- It does not provide any evidence of actual applicability, such as my
aforementioned considerations for non-system, but application-level TLS stacks
to allow support on existing certified systems. I don't think anyone involved
in the draft did try to evaluate whether they broad enough applicable today.
Cheers
toerless
P.S.:
If you want to get really scared of how outdated security designs are
in industrial IoT, take a look at this talk:
https://media.ccc.de/v/37c3-11717-why_railway_is_safe_but_not_secure
This is OT wrt. TLS1.3, but i thought it would be fun for all you train lovers
out there trying to avoid flying to the next IETF meetings when you can.
On Wed, Apr 09, 2025 at 06:24:33PM +0300, Alper Kamil Demir wrote:
> +1
>
> Behcet Sarikaya <sarikaya2...@gmail.com>, 9 Nis 2025 Çar, 17:53 tarihinde
> şunu yazdı:
>
> >
> >
> > On Wed, Apr 9, 2025 at 1:15 AM Valery Smyslov <val...@smyslov.net> wrote:
> >
> >> (speaking not as UTA chair)
> >>
> >> Hi Toerless,
> >>
> >> if we are talking about IOT devices, then I've been told a lot of times by
> >> more knowledgeable than I
> >> people that IOT devices mostly rely on DTLS and not on TLS. And DTLS is
> >> explicitly
> >> mentioned in the draft as being out of scope.
> >>
> >>
> > +1
> >
> > Behcet
> >
> >> Regards,
> >> Valery.
> >>
> >>
> >> > Dear IESG, *:
> >> >
> >> > We received IESG review for draft-ietf-anima-brski-prm that was asking
> >> to
> >> make
> >> > the use of TLS 1.3 mandatory based on the expectation that
> >> draft-ietf-uta-require-
> >> > tls13 would become RFC - unless we provide sufficient justification in
> >> our
> >> (prm)
> >> > draft.
> >> >
> >> > I would like to point out, that it is the current version of
> >> draft-ietf-uta-require-tls13
> >> > whose core applicability reasoning is misleading:
> >> >
> >> > "since TLS 1.3 use is widespread, ...
> >> > new protocols that use TLS must require and assume its existence
> >> >
> >> > This is not correct. Correct would be is:
> >> >
> >> > "since TLS 1.3 use is widespread in browser, ...
> >> > new protocols that use browsers and TLS must require its use and
> >> assume
> >> its
> >> > existence,
> >> > protocols not using browsers must recommend its use and assume its
> >> existance
> >> >
> >> > Recommending, but not requiring the use of TLS 1.3 is unfortunately
> >> necessary for
> >> > quite a while for the much larger space of IOT equipment and protocols
> >> written for
> >> > non-browser enviroments where IOT equipment is important to be
> >> supported.
> >> > Such IOT equipment often comes with SDK that can not be upgraded for
> >> long
> >> > periods of time, sometimes as long as 10 years or longer, and/or
> >> solutions
> >> where
> >> > upgrade of SDK (including OS) would require very expensive
> >> re-certification such
> >> > as FIPS 140 or required regulatory requirements.
> >> >
> >> > If you think this is not appropriate, then please stop flying planes,
> >> because planes
> >> > are one example of systems in which basic systems are not possible to
> >> rewrite
> >> > from scratch because they can not for various, including financial
> >> reasons
> >> be re-
> >> > qualified at such a base level.
> >> >
> >> > I hope other readers of this email worrying about being able to apply
> >> IETF
> >> protocol
> >> > standards to IOT environment can chime in on this concerns.
> >> >
> >> > Short of that, the above text is suggested re-write of the core
> >> applicability point of
> >> > the UTA draft. There may be other text to update.
> >> >
> >> > Cheers
> >> > Toerless
> >>
> >> --
> >> Iotops mailing list -- iot...@ietf.org
> >> To unsubscribe send an email to iotops-le...@ietf.org
> >>
> > --
> > Iotops mailing list -- iot...@ietf.org
> > To unsubscribe send an email to iotops-le...@ietf.org
> >
>
> --
> **“Uyarı: Bu e-posta mesajı kişiye özel olup, gizli
> bilgiler içeriyor
> olabilir. Eğer bu e-posta mesajı size yanlışlıkla ulaşmışsa,
> içeriğini
> hiçbir şekilde kullanmayınız ve ekli dosyaları açmayınız. Bu durumda
> lütfen
> e-posta mesajını gönderen kullanıcıya haber veriniz ve tüm elektronik ve
> yazılı kopyalarını siliniz. Adana Alparslan Türkeş Bilim ve Teknoloji
> Üniversitesi, bu e-posta mesajının içeriği ile ilgili olarak hiçbir
> hukuksal
> sorumluluğu kabul etmez.”**
> **
> **
> **“Di****sclaimer: T****his
> e-mail message is personal and may contain confidential information. If
> this e-mail message reaches you by mistake, do not use its contents in any
> way and do not open the attached files. In this case, please notify the
> user who sent the e-mail message and delete all electronic and written
> copies. Adana Alparslan Türkeş Science and Technology University does not
> accept any legal responsibility for the content of this e-mail message."**
> **
> **
>
--
---
t...@cs.fau.de
_______________________________________________
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
