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

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Fri, 27 Jul 2018 20:25:10 +0000

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:
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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Sat, 28 Jul 2018 01:56:26 +0000

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

> On Jul 27, 2018, at 2:25 PM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> 
> Greetings,
>

---

From: Ira McDonald <[email-masked]>
Date: Sat, 28 Jul 2018 11:01:12 -0400

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: [email-masked]
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) <[email-masked]> wrote:

> 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
> 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
>
> Close the connection; select a certificate (with possible user
> interaction); retry connection with selected certificate
>
> Close the connection; select a different certificate (with possible user
> interaction); retry connection with selected certificate
>
> 'client-error-forbidden'
>
> 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

---

From: Michael Sweet <[email-masked]>
Date: Sun, 29 Jul 2018 21:55:48 -0400

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) <[email-masked]> 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 4.2.3.4). The "uri-security-supported" attribute simply uses 'tls' but lists no version (…

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

---

From: "Kennedy, Smith (Wireless & Standards Architect)" <[email-masked]>
Date: Mon, 30 Jul 2018 15:59:07 +0000

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

/**
    Smith Kennedy

> On Jul 29, 2018, at 7:55 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 
>> On Jul 27, 2018, at 4:25 PM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked] <mailto:[email-masked]>> wrote:
>> ...

---

From: Michael Sweet <[email-masked]>
Date: Mon, 30 Jul 2018 17:34:29 -0400

Smith,

I'll see what I can do...

> On Jul 30, 2018, at 11:59 AM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> 
> Hi Ira and Mike,
> 
> Thanks for your replies! 
> 
>> On Jul 29, 2018, at 7:55 PM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Smith,
>>