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

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>

On March 27, 2022 6:57:23 PM GMT+03:00, Greg Troxel <gdt at lexort.com>
wrote:
>
>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.
Right.

>
>> 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.
WFM

>
>This is really about the defined protocol and not really about any
>particular implementation :-)
>
>Certainly pointing to the normal RFCs is good.
Right again

>
> I would hesitate to
>do anything other than pointing to other RFCs that address this issue.
>Again nut is not really special.
Once again, I agree

>
>I am guessing their concern was lack of clarity about client certs and
>the path to authorization.
I'd need more details from the IES. I do not really understand why is he
inferring differences between nut and other applications relying on SSL