Nut upsuser - Mar 2022 - I-D: ISE request for more detail on command STARTTLS

The IETF Independent Submissions Editor (ISE) has asked for more detail on the 
command STARTTLS, in particular the use of certificates.

I propose saying that NUT 2.8.0 supports the encryption of communications 
between Attachment Daemon upsd and Management Daemon upsmon using TLS 1.3 
[RFC8446] with X.509 v3 certificates as defined by RFC5280 + updates.

I also propose adding a note that in the closely restrained world of UPS 
management, it may be possible to obtain better security using self-signed 
certificates.

Aa always with RFC work, comments are welcome.  Roger

Roger Price <roger at rogerprice.org> writes:
> The IETF Independent Submissions Editor (ISE) has asked for more
> detail on the command STARTTLS, in particular the use of certificates.
That's interesting, given how the overall state of PKI is not
particularly about NUT.
> I propose saying that NUT 2.8.0 supports the encryption of
> communications between Attachment Daemon upsd and Management Daemon
> upsmon using TLS 1.3 [RFC8446] with X.509 v3 certificates as defined
> by RFC5280 + updates.
This is really about the defined protocol and not really about any
particular implementation :-)

Certainly pointing to the normal RFCs is good.

I see two separate issues:

  Everybody knows that the current situation where there are 100 or so
  standard trust anchors isn't really safe, because the compromise of
  any of them could lead to a bad certificate being accepted.  But NUT
  isn't special.  This is really about the server certificate.  So I
  wonder if this is about the server cert, and what the SMTP spec says,
  and HTTPS, and thinking about why NUT is different.

  Sometimes people use client certs for auth.   I'm totally unclear
  (because I only run nut over localhost, and I haven't really read the
  details) on whether the protocol spec talks about client certs for
  authentication and hence authorization.
> I also propose adding a note that in the closely restrained world of
> UPS management, it may be possible to obtain better security using
> self-signed certificates.
There is also pinning.  And self-signed is not really the fix as much as
deconfiguring the trust anchors for the N-1 CAs one is not using,
although with a self-CA that means disabling all N.  I would hesitate to
do anything other than pointing to other RFCs that address this issue.
Again nut is not really special.

I am guessing their concern was lack of clarity about client certs and
the path to authorization.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220327/00b9501e/attachment.sig>