[IPP] IPP attribute for TLS version support, and status code to indicate TLS negotiation failure?

[IPP] IPP attribute for TLS version support, and status code to indicate TLS negotiation failure?

Kennedy, Smith (Wireless & Standards Architect) smith.kennedy at hp.com
Mon Jul 30 15:59:07 UTC 2018

Hi Ira and Mike,

Thanks for your replies! 

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?


    Smith Kennedy
    Wireless & Standards Architect - IPG-PPS
    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF
    Chair, IEEE ISTO Printer Working Group
    HP Inc.

> On Jul 29, 2018, at 7:55 PM, Michael Sweet <msweet at apple.com> wrote:
> Smith,
> I agree with Ira - TLS version numbers, errors, etc. belong at the TLS level and not in IPP.
> I've included a few specific comments inline below...
>> On Jul 27, 2018, at 4:25 PM, Kennedy, Smith (Wireless & Standards Architect) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>> ...
>> 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?
> 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.
>> The Client can learn the Printer's maximum TLS version via the "TLS" DNS-SD TXT record key (5100.14 section 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).
> 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.
> 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...
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180730/28e84fd0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180730/28e84fd0/attachment.p7s>

More information about the ipp mailing list