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

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

On Mon, 3 Jan 2022 19:10:09 +0100 (CET)
Roger Price <roger at rogerprice.org> wrote:
> 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
What if the client doesn't ask for TLS because the UPS (server) only
supports an old TLS version that was removed in the client for security
purposes? Or what if the certificate/certificate chain was compromised
and so the client doesn't have a TLS cert/cert chain for the UPS?

Just my thoughts,
David