On 7/15/22 11:54 AM, Rob Sayre wrote:
On Fri, Jul 15, 2022 at 10:47 AM Benjamin Kaduk <ka...@mit.edu
<mailto:ka...@mit.edu>> wrote:
On Fri, Jul 15, 2022 at 10:30:55AM -0700, Rob Sayre wrote:
> On Fri, Jul 8, 2022 at 7:19 AM Cullen Jennings via Datatracker <
> nore...@ietf.org <mailto:nore...@ietf.org>> wrote:
>
>
> > I see no evidence of any
> > discussion of how that will work out for things that use HTTP
but are not
> > browsers.
> >
>
> There just aren't that many implementations on the client side.
Not only do
> you have to implement all of the HTTP versions and TLS, but you
have to
> maintain all of the PKI stuff as well. Obviously, people do it,
but they
> are not the ones that need to read this document.
>
> If the TLS library is not one also used by the OS and a browser (NSS,
> SecureTransport, etc), it's probably OpenSSL. I don't think this
is an
> oversight in the document.
I think we need to be really careful with what we're considering as the
relevant population of clients when making statements like this,
Sorry, I tried to leave a caveat in there for exactly this concern, but
that seems to have failed.
Mbed TLS (Apache licensed, just like current OpenSSL) is much more
appropriate in those environments,
I don't think people that write programs like that will get a lot out of
this document. I think they're not the audience (they will drop TLS 1.2
or support TLS 1.1 if they want/need to).
And, surprisingly enough, that's already mentioned in the applicability
statement section of this document:
This document does not discuss the use of TLS in constrained-node
networks [RFC7228]. For recommendations regarding the profiling of
TLS and DTLS for small devices with severe constraints on power,
memory, and processing resources, the reader is referred to [RFC7925]
and [I-D.ietf-uta-tls13-iot-profile].
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
