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

Ira McDonald blueroofmusic at gmail.com
Sat Jul 28 15:01:12 UTC 2018


Hi Smith,

Explicitly exposing TLS versions, Kerberos versions, HTTP versions, etc. at
the application
IPP layer is exactly what IETF has actively avoided in SMTP and many other
protocols.
It's a slippery slope, IMO.

In TLS/1.3 itself, the TLS WG only made RECOMMENDED the return of specific
Alert
codes in handshake or data transfer phase failures and made the Alert
message entirely
optional, *not* localized (or language-tagged), and not necessarily mapped
one-to-one
to the Alert code.

Exposing lower-layer failures (and configuration) in IPP attributes sounds
wrong to me.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434


On Fri, Jul 27, 2018 at 9:56 PM, Kennedy, Smith (Wireless & Standards
Architect) <smith.kennedy at hp.com> wrote:

> Greetings again,
>
> I posted this without overtly suggest a fix for this:
>
> 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).
>
>
> To bring IPP to parity with IPP + DNS-SD, I think we need to either add
> additional keywords for "uri-security-supported", like 'tls-1.2' and
> 'tls-1.3', or we create a new attribute. Even with this addition, I also
> think a new 'client-error-tls-negotiation-failure' status code should be
> defined.
>
> Have a good weekend,
>
> Smith
>
> /**
>     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 27, 2018, at 2:25 PM, Kennedy, Smith (Wireless & Standards
> Architect) <smith.kennedy at hp.com> wrote:
>
> Greetings,
>
> In my presentation to the Mopria Technical Working Group yesterday, a
> question arose about TLS version negotiation failures, and whether the
> Client would be notified of such failures at the IPP level. I responded
> that there might be a response at the IPP level but that Clients (and
> Printers) need to also be aware of the TLS and HTTP levels. But then I
> remembered that, in the latest draft of the IPP Authentication Methods
> white paper, Mike and I expanded and revised section 3.1.7
> "The 'certificate' IPP Authentication Method" to include the following:
>
>
>    1.
>
>    The Printer SHOULD return the IPP status code listed in Table 3.1 when
>    the corresponding authentication exception occurs. The Client SHOULD
>    respond to the reported status code with the corresponding response
>    listed in Table 3.1.
>
>
> Operation Status Code
>
> Authentication Exception
>
> Recommended Client Response
>
> 'client-error-not-authenticated'
>
> Authentication required but no X.509 certificate supplied
>
> Close the connection; select a certificate (with possible user
> interaction); retry connection with selected certificate
>
> 'client-error-not-authorized'
>
> Access denied for the identity specified by the provided X.509
> certificate; try again
>
> Close the connection; select a different certificate (with possible user
> interaction); retry connection with selected certificate
>
> 'client-error-forbidden'
>
> Access denied for the identity specified by the provided X.509
> certificate; don't try again
>
> Close the connection and present User with error dialog (“Access denied”)
>
> Table 3.1 : IPP 'certificate' Authentication Method Error Condition Status
> Codes
>
> 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?
> 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).
>
> Thoughts?
>
> Smith
>
> /**
>     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.
> */
>
>
>
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
>
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180728/c298652b/attachment.html>


More information about the ipp mailing list