[Nut-upsdev] NUT I-D: Unencrypted communication

[Greg Troxel]

David Niklas <deference at null.net> writes:

>> 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?

I don't follow the link from your questions to the text as part of a
(not really standard, Informational) proposed standard.  Roger's text
does not require that the client send STARTTLS, and the server is free
to refuse or not refuse to continue.

Are you suggesting a different rule?

I think really you are discussing reasons for implementation choices
within what is permitted, which isn't about what the protocol spec
should say.
-------------- 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/20220104/cd71a353/attachment.sig>