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

[Benjamin Kaduk <[e-mail]>]

On Thu, May 18, 2017 at 02:35:24AM +0000, Daniel Migault wrote:
> 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.

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.

> Nits:
> 
> Section 5.2
> 
> 
> 
> to the has function
> 
> section 5.4:
> 
> 
> TGT needs to be defined.

Fixed.

> 
> """
> 
> 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.

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 explanations. Then, do we have recommendation for the deprecation, such as specific message, logs...?

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.


> 
> Section 7.
> 
> 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:
> 
> 
>   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.)

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


Thanks for all the comments!

-Ben