Nut upsdev - Jan 2022 - NUT I-D: Unencrypted communication

Roger Price <roger at rogerprice.org> writes:
> On Mon, 3 Jan 2022, Manuel Wolfshant wrote:
>
>> On 1/3/22 14:17, Roger Price wrote:
>>> I propose adding the following sentence to section 4.2.12:
>>>
>>> ?If the client does not send command STARTTLS to the Attachment
Daemon
>>> ?communication continues unencrypted. 
>>
>> Sounds like a sane decision. Most [ low end ] UPSes do not know
>> anything about encryption. What we can do is to recommend
>> communication between upsd and ups-monitor to be encrypted.
>
> Should the Attachment Daemon upsd be able to defend itself against
> unencrypted access from misconfigured or possibly hostile clients?
That's an implementation question, really, but it seems obvious that it
should be conforming for an implementation to refuse to interact in
cleartext.  And also to choose to allow cleartext on localhost and not
with other addresses.
> Is the presence of a CERTFILE or CERTIDENT declaration in upsd.conf
sufficient?
I would not expect that to belong in the RFC at all, but maybe I'm
confused.
-------------- 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-upsdev/attachments/20220103/f4d921c9/attachment.sig>

On Mon, 3 Jan 2022, Greg Troxel wrote:
>>> On 1/3/22 14:17, Roger Price wrote:
>>>> I propose adding the following sentence to section 4.2.12:
>>>>
>>>> ?If the client does not send command STARTTLS to the Attachment
Daemon
>>>> ?communication continues unencrypted.
>>>
>> Should the Attachment Daemon upsd be able to defend itself against
>> unencrypted access from misconfigured or possibly hostile clients?
>
> That's an implementation question, really, but it seems obvious that it
> should be conforming for an implementation to refuse to interact in
> cleartext.  And also to choose to allow cleartext on localhost and not
> with other addresses.
I'll change the additional sentence to

?If the client does not send command STARTTLS to the Attachment Daemon
?communication continues unencrypted, however an Attachment Daemon may refuse
  unencrypted communication.

How the AD does this is an implementation matter and outside the scope of the 
RFC.

Roger