Subject: [Gen-art] Telechat Review of draft-sweet-rfc2910bis-08

From: Matt Miller <[email-masked]>
Date: Wed, 3 Aug 2016 19:14:22 -0600

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >.

Document: draft-sweet-rfc2910bis-08
Reviewer: Matthew A. Miller
Review Date: 2016-08-03
IETF LC End Date: 2016-07-11
IESG Telechat date: 2016-08-04

Summary:

Almost ready.  My one major issue is with the digest authentication
requirements, and really needs to be addressed in a way that
accounts for current security best practices.

I admit that I did not read the RFCs this document obsoletes.

I did not validate the correctness of any of the examples in
Appendix A.

Major issues:

* In Section 8.1.1. "Digest Authentication", support for MD5 and
  MD5-sess is a MUST, which contradicts the NOT RECOMMENDED in
  RFC 7616.  I this is likely because of the giant number of existing
  implementations, but it's a bad idea to continue the practice given
  how compromised MD5-based schemes are.  Maybe the following helps
  find something acceptable?

   IPP Clients and Printers SHOULD support Digest Authentication
   [RFC7616].  For compatibility with existing implementations,
   Clients and Printers SHOULD implement and support MD5 and MD5-sess.
   However, MD5 and MD5-sess are NOT RECOMMNEDED for newer
   implementations.  Use of the Message Integrity feature
   (qop="auth-int") is OPTIONAL.

Minor issues:

* The "meta-data" states this document obsoletes 2910 and 3382,
  but the Abstract does not explicitly say this.  There is the
  editor's note, but it is helpful to put at least a mention in
  the Abstract.

* In Section 3.2. "Syntax of Encoding", the ABNF in Figure 10 does
  not parse in the tools I tried, because of the duplicate
  reference.  The following seems to me to accomplish the intent
  while still parsing:

   delimiter-tag = begin-attribute-group-tag  / ; see section 3.5.1
             end-of-attributes-tag /
             future-delimiter-tag
   future-delimiter-tag = %x06-0F               ; see section 3.5.1
   begin-attribute-group-tag = %x00 / operation-attributes-tag /
      job-attributes-tag / printer-attributes-tag /
      unsupported-attributes-tag /  %x06-0F
   operation-attributes-tag =  %x01                ; tag of 1
   job-attributes-tag      =  %x02                 ; tag of 2
   printer-attributes-tag =  %x04                  ; tag of 4
   unsupported-attributes-tag =  %x05              ; tag of 5

* Section 3.3. "Attribute-group", the last row in Table 1 indicates
  the document content is "in a special position as described above",
  which appears to be Section 3.1.1.  It seems better to be more
  explicit and say "in a special position as described in Section
  3.1.1".

Nits/editorial comments:

* idnits complains that this document is attempting to reference
  "rfc2910bis" (this document) without declaring the reference.
  These are all in the IANA Considerations, so it seems enough to
  me to change them to "this document".

Non-nits comments:

* idnits is complaining about "weird spacing" in a number of places,
  but they are clearly part of a table (which is the sole content of
  the containing section/appendix), and I think can be safely
  ignored.

* idnits is complaining about a downref to RFC2818, but it's
  already on the Downref Registry.

-- 
- m&m

Matt Miller
Cisco Systems, Inc.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 4 Aug 2016 09:01:09 +0200

Thanks for your review, Matt!

I agree with the MD5 issue that you raise below. Stephen Farrell has raised this issue in his Discuss, and otherwise I would have. Your suggested text may be a way to fix Stephens Discuss, however. So authors please take note.

The other issues from your review should be handled by the authors, and I agree with those issues as well.

Thanks again for your review.

Jari

On 04 Aug 2016, at 03:14, Matt Miller <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Michael Sweet <[email-masked]>
Date: Fri, 05 Aug 2016 10:56:25 -0400

Matt,

Thanks for a thorough review! Responses inline below...

> On Aug 3, 2016, at 9:14 PM, Matt Miller <[email-masked]> wrote:
> ...
> Major issues:
> 

The updated text we seem to have settled on is:

   8.1.1.  Digest Authentication

   IPP Clients and Printers SHOULD support Digest Authentication
   [RFC7616].  Use of the Message Integrity feature (qop="auth-int") is
   OPTIONAL.

   Note: Previous versions of this document required support for the MD5
   algorithms, however [RFC7616] makes SHA2-256 mandatory to implement
   and deprecates MD5, allowing its use for backwards compatibility
   reasons.  IPP implementations that support Digest Authentication MUST
   support SHA2-256 and SHOULD support MD5 for backwards-compatibility.

   Note: The reason that IPP Clients and Printers SHOULD (rather than
   MUST) support Digest Authentication is that there is a certain class
   of output devices where it does not make sense.  Specifically, a low-
   end device with limited ROM space and low paper throughput may not
   need Client Authentication.  This class of device typically requires
   firmware designers to make trade-offs between protocols and
   functionality to arrive at the lowest-cost solution possible.
   Factored into the designer's decisions is not just the size of the
   code, but also the testing, maintenance, usefulness, and time-to-
   market impact for each feature delivered to the customer.  Forcing
   such low-end devices to provide security in order to claim IPP/1.1
   conformance would not make business sense.  Print devices that have
   high-volume throughput and have available ROM space will typically
   provide support for Client Authentication that safeguards the device
   from unauthorized access because these devices are prone to a high
   loss of consumables and paper if unauthorized access occurs.

> ...

This has been added, per comments from several people... :)

>  reference.  The following seems to me to accomplish the intent

Thanks, I'll incorporate this change but probably use future-delimiter-tag in the begin-attribute-group-tag rule since the future delimiters are all group tags:

delimiter-tag = begin-attribute-group-tag /   ; see section 3.5.1
          end-of-attributes-tag
begin-attribute-group-tag = %x00 / operation-attributes-tag /
   job-attributes-tag / printer-attributes-tag /
   unsupported-attributes-tag / future-group-tags
operation-attributes-tag   = %x01             ; tag of 1
job-attributes-tag         = %x02             ; tag of 2
end-of-attributes-tag      = %x03             ; tag of 3
printer-attributes-tag     = %x04             ; tag of 4
unsupported-attributes-tag = %x05             ; tag of 5
future-group-tags          = %x06-0F          ; future extensions

> ...

Works for me, changed.

>  me to change them to "this document".

Already changed... :)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Matt Miller <[email-masked]>
Date: Fri, 5 Aug 2016 11:14:21 -0600

Thanks Michael.  The updated digest text is fine with me.

I look forward to the updated revision!

- m&m

Matt Miller
Cisco Systems, Inc.