Subject: [Gen-art] Gen-ART Review of draft-ietf-6lo-dispatch-iana-registry-06

From: Russ Housley <[email-masked]>
Date: Wed, 23 Nov 2016 11:57:17 -0500

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-6lo-dispatch-iana-registry-06
Reviewer: Russ Housley
Review Date: 2016-11-23
IETF LC End Date: 2016-12-08
IESG Telechat date: unknown

Summary: Almost Ready

Major Concerns: None

Minor Concerns

In Section 3, it says:

   ... The values are from 0 to 255.  Values 0 and 255 are reserved
   for future use.  These values are assigned by IANA. ...

The use of "these values" is ambiguous.  I think that you mean the
values from 1 to 254, but based on the placement of this sentence, it
could mean 0 and 255.  Please reword to be very clear.

In Section 3.1, it says:

   ... The closer to the end of the packet are the EET's, the
   higher chance there is that a legacy node will recognize and
   successfully process some dispatch type [RFC4944] before the EET and
   then ignore the EET instead of dropping the entire packet.

I cannot figure out the first part of the sentence.  After reading it 
several times, I think the sentence it trying to say that placing an
EET toward the front of the packet has a greater probability of
causing the packet to be dropped than placing the same EET later in
the packet.  Please reword.

In Section 4, it says:

   [RFC5226] section 4.1 also indicates that "Specification Required"
   implies a Designated Expert review of the public specification
   requesting registration of the ESC Extension Type values.

s/implies/calls for/

Nits

The first paragraph of the Introduction has two sentences that begin
with "However".  I think some minor rewording would make the intent
more clear to all readers.

The Introduction says:

   ...  However, in recent years with 6lowpan deployments,
   implementations and standards organizations have started using the
   ESC extension bytes and co-ordination between the respective
   organizations and IETF/IANA is needed.

First: s/co-ordination/coordination/

Second: I am glad that we are seeing deployment.  That said, deployment
itself is not a reason for coordination.  Rather, it seems that the
experience has highlighted the need for an updated IANA registration
policy.

In Section 3:
s/Extended Dispatch Payload(EDP)/Extended Dispatch Payload(EDP)/

In Section 4:
s/IANA section/IANA Considerations section/

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 Nov 2016 15:30:30 -0500

Document: draft-ietf-straw-b2bua-rtcp-15
Reviewer: Russ Housley
Review Date: 2016-11-25
IETF LC End Date: 2016-10-10
IESG Telechat date: 2016-12-01

Summary: Almost Ready

Major Concerns

I wonder if this ought to be a standards-track document.
I recognize that the STRAW WG charter calls for a standards-track
document, but it only contains a handfull of MUST statements that are
not repeats from another RFC.  Maybe this document should become a
Best Current Practice (BCP) instead of a standards-track document.

Minor Concerns

In Section 3.1, it says:

   ...  However, certain SDP attributes may
   lead to call failures when forwarded by a media relay.  Such
   attributes SHOULD NOT be forwarded.  One notable example is the
   'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly
   state the port they're willing to use for RTCP.  ...

This SHOULD NOT statement is vague.  One example of an attribute that
should not be forwarded is given, and the previous sentence provides
some specific attributes that should be forwarded.  While I see why it
is difficult to not be vague, some better advice to the implementer
could be very helpful

---

From: Russ Housley <[email-masked]>
Date: Sun, 27 Nov 2016 14:54:42 -0500

Document: draft-ietf-kitten-pkinit-freshness-07
Reviewer: Russ Housley
Review Date: 2016-11-27
IETF LC End Date: 2016-11-03
IESG Telechat date: 2016-12-01

Summary: Almost Ready

Major Concerns

I understand that freshness tokens provide corroboration that the
client had access to the private key at the time that the AS-REQ
was constructed.  I also understand that the freshness tokens do not
have to be single use tokens for specific AS exchanges.  However,
some guidance on the minimum size of the freshness token seems to be
appropriate.  If the freshness token is too small, then the client
could be generate signatures using all of the possible token values
at when it does have access to the private key, offering the one that
matches the freshness token during the exchange with the KDC.  Please
specify a minimum size for the freshness token.

Please add a discussion of the minimum freshness token size to
Section 7 (Security Considerations).

Question: Is there a reson to specify a maximum size for the freshness
token?  If an implementor knows that the freshness token will be under
some maximum, then the code can incorporate that information into the
buffer management and easily discard any KRB-ERROR messages that exceed
that maximum.

Minor Concerns

In the Abstract and Section 1 (Introduction), please spell out KDC the
first time the acronym is used.

In Section 2.2 (Generation of KRB_ERROR Message), please give the reader
a heads up that PA_AS_FRESHNESS is defined in this document.  I went
looking for it in RFC 4120; a pointer could have avoided this wild goose
chase.

Nits

In Figure 1, since the client begins the conversation, it would read
better if the Client were on the left side of the figure.

---

From: Michiko Short <[email-masked]>
Date: Mon, 28 Nov 2016 16:59:03 +0000

The size issue a is big one for this late in the process as it never came up before. We would have to bring it up to the WG for discussion. Is this required? 

Happy to submit an updated version with the client & KDC flipped, first reference of KDC in abstract spelled out, and 2.1 PA_AS_FRESHNESS referencing 4. Just tell me when I can make the updates.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Sunday, November 27, 2016 11:55 AM
To: [email-masked]
Cc: IETF Gen-ART <[email-masked]>
Subject: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

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 wait for direction from your document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Summary: Almost Ready

Major Concerns

I understand that freshness tokens provide corroboration that the client had access to the private key at the time that the AS-REQ was constructed.  I also understand that the freshness tokens do not have to be single use tokens for specific AS exchanges.  However, some guidance on the minimum size of the freshness token seems to be appropriate.  If the freshness token is too small, then the client could be generate signatures using all of the possible token values at when it does have access to the private key, offering the one that matches the freshness token during the exchange with the KDC.  Please specify a minimum size for the freshness token.

Please add a discussion of the minimum freshness token size to Section 7 (Security Considerations).

Question: Is there a reson to specify a maximum size for the freshness token?  If an implementor knows that the freshness token will be under some maximum, then the code can incorporate that information into the buffer management and easily discard any KRB-ERROR messages that exceed that maximum.

Minor Concerns

In the Abstract and Section 1 (Introduction), please spell out KDC the first time the acronym is used.

In Section 2.2 (Generation of KRB_ERROR Message), please give the reader a heads up that PA_AS_FRESHNESS is defined in this document.  I went looking for it in RFC 4120; a pointer could have avoided this wild goose chase.

Nits

In Figure 1, since the client begins the conversation, it would read better if the Client were on the left side of the figure.

---

From: "Paul Miller (NT)" <[email-masked]>
Date: Mon, 28 Nov 2016 21:53:35 +0000

Minimum length is a problematic topic due to the fact that we intentionally did not specify the format of the freshness token.  Since the structure of the freshness token is left up to the KDC, there is no good way to determine a minimum size.  If the freshness token is a nonce then the size is determined by the birthday problem.  If it is based on symmetric cryptography, then there are different length considerations.  If it is based on asymmetric crypto then there is a third set of size considerations.

A maximum size makes sense as a way to avoid processing messages that are clearly bad.  Is there an accepted value for a worst case CMS signature?

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Sunday, November 27, 2016 11:55 AM
To: [email-masked]
Cc: IETF Gen-ART <[email-masked]>
Subject: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

Summary: Almost Ready

Major Concerns

Minor Concerns

Nits

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 29 Nov 2016 12:43:05 +0100

On Fri, 25 Nov 2016 15:30:30 -0500

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

Hi Russ,

thanks for this new review!

> Best Current Practice (BCP) instead of a standards-track document.

We actually discussed this in your previous review as well. I can't
find the final points or decision on this in that discussion, but I
explained there how the WG came to the conclusion it was ok for this to
be standards track. You can find the related WG discussion here:

    https://www.ietf.org/mail-archive/web/straw/current/msg00579.html 

which lead to no objection to keep the document's scope as it is. Not
sure how we should proceed on this at this point: I still believe a
standards-track document is more appropriate.

> is difficult to not be vague, some better advice to the implementer

This point was also addressed in your original review, and I tried to
fix it and make it clearer with this text change here:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-15.txt

Do you believe it's still ambiguous as it is? Do you have any
suggestion on how to improve the text and fix this? Maybe mentioning a
couple of attributes we talk about subsequently with something like
"Other examples are attributes like X and Y, for reasons that will
become clearer in latter sections"?

Thanks!
Lorenzo

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Nov 2016 15:25:45 -0600

Hi Russ, please see inline:

Thanks!

Ben.

> Best Current Practice (BCP) instead of a standards-track document.

You may recall you and I had a private email discussion back in October, 
after your LC review concerning the PS status. We discussed that the 
working group had also informational or BCP, but decided to stick with 
PS. (This came up in my AD evaluation as well.) Unless you strongly 
object, I am inclined to let them stick with PS.

> is difficult to not be vague, some better advice to the implementer

While the authors attempted to clarify this, the current draft still got 
similar comments from Alissa and Alia in the IESG review. They've both 
proposed clarifying text--hopefully the combination will fix this.

---

From: Michiko Short <[email-masked]>
Date: Wed, 30 Nov 2016 23:20:23 +0000

Russ, is there an accepted value for a worst case CMS signature?

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Sunday, November 27, 2016 11:55 AM
To: [email-masked]
Cc: IETF Gen-ART <[email-masked]>
Subject: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

Summary: Almost Ready

Major Concerns

Minor Concerns

Nits

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 30 Nov 2016 20:59:12 -0600

> Minimum length is a problematic topic due to the fact that we intentionally did not specify the format of the freshness token.  Since the structure of the freshness token is left up to the KDC, the…

We could still mention in the security considerations that depending on the
construction of the token, the token should have some minimum size; essentially,
your text from above.

-Ben