Subject: [Curdle] review of draft-ietf-curdle-des-des-des-die-die-die

From: Daniel Migault <[email-masked]>
Date: Thu, 18 May 2017 02:35:24 +0000

Hi,

The draft seems to me quite ready. Please find some small comments.

  1.  Updates / obsoletes should be mentioned in the header, abstract and intro.

  1.  Status: wouldn't standard track be more appropriated ?

Nits:

Section 5.2

to the has function

section 5.4:

TGT needs to be defined.

"""

It is now believed that all machines that might be broken by disabling RC4 are unsupported, and concerns about breaking them will be reduced.

"""

I see this sentence as reflecting a support team point of view. If an application runs on W2003 and save lifes, I prefer not breaking it.

I believe the issue is that an important aspect of support is addressing vulnerabilities. As patches are not provided for these versions, these systems becomes too vulnerable and authentication with Kerberos may provide limited protection. In such situation, could Kerberos be disabled, and alternate authentication may be used. Kerberos might be the preferred way to perform authentication but what would be the other ways. The typical use case I see is a that new client will not be able to connect the service. I hardly see KDC, Services being updated while client are not updated. I am fine clearly saying that upgrading to newer version is recommended.

OK, reading the name of the draft I expected RC4/3DES to be MUST NOT. If the status is SHOULD NOT, it gives time for the transition. In that case comment above may not require so detailed explanations. Then, do we have recommendation for the deprecation, such as specific message, logs...?

Section 7.

If SHOULD NOT is specified, maybe we should mention that the status is expected to move to MUST NOT.

Nits from the datatracker:

idnits 2.14.01

/tmp/draft-ietf-curdle-des-des-des-die-die-die-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document obsoletes RFC4757, but the
     abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document updates RFC3961, but the
     abstract doesn't seem to mention this, which it should.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

     (Using the creation date from RFC3961, updated by this document, for
     RFC5378 checks: 2004-02-11)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.)

  -- The document date (May 1, 2017) is 16 days in the past.  Is this
     intentional?

  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

     No issues found here.

     Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------

[Ericsson]<http://www.ericsson.com/>

DANIEL MIGAULT
Researcher
Research

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
[email-masked]
www.ericsson.com

[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

Legal entity: Ericsson Canada Inc., registered office in Montreal. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 25 May 2017 23:28:45 -0500

>   1.  Updates / obsoletes should be mentioned in the header, abstract and intro.

Gosh, for all the times I've reminded other people about this, I
feel silly having missed it.

>   1.  Status: wouldn't standard track be more appropriated ?

Yes, that's another long-standing issue I failed to fix when
preparing the more recent updates.  Though, RFC 6649 is actually a
BCP, so maybe that is better than standards-track.  I'll go with bcp
in my working copy, but of course we can revise it as needed.

> TGT needs to be defined.

Fixed.

> I see this sentence as reflecting a support team point of view. If
> an application runs on W2003 and save lifes, I prefer not breaking
> it.
>
> 
> 
> I believe the issue is that an important aspect of support is
> addressing vulnerabilities. As patches are not provided for these
> versions, these systems becomes too vulnerable and authentication
> with Kerberos may provide limited protection. In such situation,
> could Kerberos be disabled, and alternate authentication may be
> used. Kerberos might be the preferred way to perform
> authentication but what would be the other ways. The typical use
> case I see is a that new client will not be able to connect the
> service. I hardly see KDC, Services being updated while client are
> not updated. I am fine clearly saying that upgrading to newer
> version is recommended.

Because of the nature of Kerberos deployments, with many shared
secrets across different parties, it is generally difficult to make
sweeping changes quickly.  So, I do not think the effect of this
document will be a rush for everyone to immediately remove the
affected shared keys; many will continue to exist for a long time.
Probably a good mental model for the desired transition is that new
clients being installed stop using it, and KDCs/servers start
considering turning them off, presumably with various exceptions as
appropriate.  Entirely new realms would hopefully not use them at
all, but existing ones would likely continue to have them enabled
for quite some time.  As a rough guideline, for MIT Kerberos we tend
to think of having to wait ten years before we can assume that some
new feature has sufficiently universal deployment that we should
expect it to "always" be present.

> OK, reading the name of the draft I expected RC4/3DES to be MUST NOT. If the status is SHOULD NOT, it gives time for the transition. In that case comment above may not require so detailed explanati…

I think I initially wanted to do MUST NOT (in the mindset that
adoption of this standard will be gradual, that is still consistent
with the expected rollout procedure), but went with SHOULD NOT for
consistency with RFC 6649.  However, the generation of that document
predates my involvement, so I don't know offhand what went into
getting consensus for the SHOULD NOT.

> If SHOULD NOT is specified, maybe we should mention that the status is expected to move to MUST NOT.

That seems consistent with a BCP designation, in that for now it is
SHOULD NOT, but the next update will make it MUST NOT.  If we target
BCP status, I don't feel a particular need to mention it, but if we
did, I would probably do it at the end of the "Recommendations"
section as:

    Future versions of this document are expected to change these
    recommendations from SHOULD NOT to MUST NOT.

> Nits from the datatracker:

This document does not contain any content from RFC 3961, so I think
this one can be ignored.

Thanks for all the comments!

-Ben