attachment
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Smith,<div class=""><br class=""></div><div class="">I'll see what I can do...</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 30, 2018, at 11:59 AM, Kennedy, Smith (Wireless & Standards Architect) <<a href="mailto:smith.kennedy@hp.com" class="">smith.kennedy@hp.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Ira and Mike,<div class=""><br class=""></div><div class="">Thanks for your replies! </div><div class=""><br class=""></div><div class="">Mike, I don't know if you can include a summary of this in your "IPP and TLS 1.3" slide set you were preparing for the vF2F?</div><div class=""><br class=""><div class="">
<div dir="auto" style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Smith<br class=""><br class="">/**<br class=""> Smith Kennedy<br class=""> Wireless & Standards Architect - IPG-PPS<br class=""> Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF<br class=""> Chair, IEEE ISTO Printer Working Group<br class=""> HP Inc.<br class="">*/<br class=""><br class=""><br class=""></div></div>
</div>
<div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 29, 2018, at 7:55 PM, Michael Sweet <<a href="mailto:msweet@apple.com" class="">msweet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Smith,<div class=""><br class=""></div><div class="">I agree with Ira - TLS version numbers, errors, etc. belong at the TLS level and not in IPP.</div><div class=""><br class=""></div><div class="">I've included a few specific comments inline below...</div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 27, 2018, at 4:25 PM, Kennedy, Smith (Wireless & Standards Architect) <<a href="mailto:smith.kennedy@hp.com" class="">smith.kennedy@hp.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">...</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">None of these seem to cover a lower-level protocol negotiation level failure. Do we need to add a new one for TLS version negotiation failure?</div></div></div></blockquote><div class=""><br class=""></div>I don't think so. If the Client and Printer cannot negotiate a common supported version of TLS, the connection will fail and the Printer won't have the opportunity to tell the Client why in an IPP response since the request will not have been received.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""> The Client can learn the Printer's maximum TLS version via the "TLS" DNS-SD TXT record key (5100.14 section 4.2.3.4). The "uri-security-supported" attribute simply uses 'tls' but lists no version (which troubles me because DNS-SD shouldn't be more descriptive than IPP).</div></div></div></blockquote><div class=""><br class=""></div></div>While the TLS key does provide slightly more information, I don't think this is critical since a) most/all? clients look for _ipps advertisements these days to determine TLS support and b) Clients do not trust such information for downgrading to a lower version of TLS thanks to the SSL3 and TLS/1.0 downgrade attacks.</div><div class=""><br class=""></div><div class="">At best the information might allow a Client to hide printers that (for example) only support TLS/1.0, or treat such printers as insecure after a suitably ominous warning to the user...</div><div class=""><br class=""><div class="">
<div style="caret-color: rgb(0, 0, 0); font-family: Menlo; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">_________________________________________________________<br class="">Michael Sweet, Senior Printing System Engineer</div>
</div>
<br class=""></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""><div class="">
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Menlo; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">_________________________________________________________<br class="">Michael Sweet, Senior Printing System Engineer</div>
</div>
<br class=""></div></body></html>