<html><head></head><body>To throw my $.02 in here, *NOTHING* should be "removed for security purposes"!<br><br>It should *ALWAYS* be the choice of the person doing the deployment what to use - no some anonymous derp who has no clue about any specifics of the deployment! Not everything has the same exposure, and support of more "legacy" gear must be maintained, even if it means a deliberqte recompile with the old stuff enabled!<br><br>- Tim<br><br><div class="gmail_quote">On January 3, 2022 9:08:45 PM CST, David Niklas <deference@null.net> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre dir="auto" class="k9mail">On Mon, 3 Jan 2022 19:10:09 +0100 (CET)<br>Roger Price <roger@rogerprice.org> wrote:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">On Mon, 3 Jan 2022, Greg Troxel wrote:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">On 1/3/22 14:17, Roger Price wrote: <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> I propose adding the following sentence to section 4.2.12:<br><br> If the client does not send command STARTTLS to the Attachment<br> Daemon communication continues unencrypted. <br></blockquote><br></blockquote>Should the Attachment Daemon upsd be able to defend itself against<br>unencrypted access from misconfigured or possibly hostile clients? <br></blockquote><br> That's an implementation question, really, but it seems obvious that<br> it should be conforming for an implementation to refuse to interact in<br> cleartext. And also to choose to allow cleartext on localhost and not<br> with other addresses. <br></blockquote><br>I'll change the additional sentence to<br><br> If the client does not send command STARTTLS to the Attachment Daemon<br> communication continues unencrypted, however an Attachment Daemon may<br>refuse unencrypted communication.<br><br>How the AD does this is an implementation matter and outside the scope<br>of the RFC.<br><br>Roger<br></blockquote><br>What if the client doesn't ask for TLS because the UPS (server) only<br>supports an old TLS version that was removed in the client for security<br>purposes? Or what if the certificate/certificate chain was compromised<br>and so the client doesn't have a TLS cert/cert chain for the UPS?<br><br>Just my thoughts,<br>David<hr>Nut-upsdev mailing list<br>Nut-upsdev@alioth-lists.debian.net<br><a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br></pre></blockquote></div><div style='white-space: pre-wrap'><div class='k9mail-signature'>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</div></div></body></html>