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

[Matt Miller <[e-mail]>]

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

I look forward to the updated revision!


- m&m

Matt Miller
Cisco Systems, Inc.

On 2016-8-5 08:56, Michael Sweet wrote:
> Matt,
> 
> Thanks for a thorough review! Responses inline below...
> 
>> On Aug 3, 2016, at 9:14 PM, Matt Miller <[e-mail]> wrote:
>> ...
>> 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?
> 
> 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.
> 
>> ...
>> 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.
> 
> This has been added, per comments from several people... :)
> 
>> * 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:
> 
> 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
> 
>> ...
>> * 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".
> 
> Works for me, changed.
> 
>> 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".
> 
> Already changed... :)
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
> 
>