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/blueroofmusichttp://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>