Re: [TLS] uta-tls-bcp-02 thoughts (was: NULL cipher to become a MUST NOT in UTA BCP)

["Blumenthal, Uri - 0558 - MITLL" <[e-mail]>]

YES to what Viktor said.

And I think this draft shows systemic problems. Instead of trying (and
IMHO failing) to define configurations for some questionable “broad,
generic” etc., it would be FAR better to define SPECIFIC cases where your
this document’s recommendations DO apply.

IMHO this document will NOT be useful otherwise, and SHOULD NOT be
published without such a change.
-- 
Regards,
Uri Blumenthal                               Voice: [phone]




On 9/4/14, 1:46 , "Viktor Dukhovni" <[e-mail]> wrote:

>On Thu, Sep 04, 2014 at 01:39:15PM +0900, Yutaka OIWA wrote:
>
>> > What you probably want to specify here is ?SHOULD NOT?.
>> 
>> In my opinion, it shall absolutely be "MUST NOT" for
>> "generic use cases" for which the document is applicable.
>> 
>> But it's UTA BCP document, and it's very important to
>> say "MUST NOT for general applications" here.
>
>I'd like to respond to the UTA draft more broadly, please feel free
>to forward or not to the UTA list (sorry, no cycles to actively
>engage in yet another IETF list).
>
>I am perplexed by the following from the draft's introduction:
>
>   The recommendations herein take into consideration the security of
>   various mechanisms, their technical maturity and interoperability,
>   and their prevalence in implementations at the time of writing.
>   These recommendations apply to both TLS and DTLS.  TLS 1.3, when it
>   is standardized and deployed in the field, should resolve the current
>   vulnerabilities while providing significantly better functionality,
>   and will very likely obsolete this document.
>
>If the document provides only "general application" guidance, that
>does not cover all TLS use-cases, then likely TLS 1.3 will include
>features that fall outside the general use-cases, and thus the
>document would continue to provide relevant general-case guidelines
>even with TLS 1.3 widely deployed.
>
>The introduction then goes on to state:
>
>   These are minimum recommendations for the general use of TLS.
>   Individual specifications may have stricter requirements related to
>   one or more aspects of the protocol, based on their particular
>   circumstances.  When that is the case, implementers MUST adhere to
>   those stricter requirements.
>
>What about specifications that might call for less strict requirements?
>
>In section 3.5 I am puzzled by the following text:
>
>   If TLS session resumption is used, care ought to be taken to do so
>   safely.  In particular, the resumption information (either session
>   IDs [RFC5246] or session tickets [RFC5077]) MUST be authenticated and
>   encrypted to prevent modification or eavesdropping by an attacker.
>
>I am entirely unaware of the practice of encryption and authentication
>of session IDs.  What is this about?  Even session tickets are not
>"authenticated", rather they might be vended by a server as part
>of an authenticated session.  Returning to session IDs, these are just
>server-side nonces, what does it mean that they should be authenticated,
>and are they in fact (with TLS <= 1.2) even encrypted?
>
>The recommendations for session ticket key rotation are I think
>too meek.  They seem to be predicated on the notion that such
>rotation is some sort of externally managed task, automated via
>something akin to a cron job, where weekly rotation is about the
>right granularity.  I'd like to suggest that session ticket key
>rotation SHOULD be a fully automated intrinsic component of the
>server application and server keys should not last much longer than
>sessions, a matter of minutes or hours not days.  Key rotation
>should happen transparently while the application is running,
>without requiring restarts, and ideally without ever explicitly
>writing keys to persistent storage.  Yes, this would be an aspirational
>part of the BCP, as few applications have this capability at present.
>
>For section 4.1, in light of the scope of section 4, the simplest
>solution is to suppress NULL cipher suites when any non-NULL cipher
>suites are configured.  This avoids accidents, without prohibiting
>deliberate NULL-only configurations.
>
>For SMTP, RC4-SHA and RC4-MD5 is the only cipher suites that
>interoperate with Exchange 2003 servers, which are still handling
>mail for a small, but non-negligible number of domains.  In fact
>these same servers only work if RC4 is among the first 64 cipher
>suites sent by the client, but with TLS 1.2, and all its new cipher
>suites that's often not the case.  Are we really better off
>prohibiting RC4?  Would it not suffice for servers to stop preferring
>RC4 (as was common with many HTTPS servers), and then stronger
>choices are automatically selected except with sites that only
>support RC4?
>
>It would be more helpful (and more interoperable) to specify a
>short list of "must implement" cipher suites, which SHOULD be
>preferred over the legacy ones, than to try to prohibit weaker
>cipher suites that are required for interoperability with older
>systems.  Thus also MUST NOT or SHOULD NOT with EXPORT and 3DES
>cipher suites is less useful than promoting more secure alternatives.
>
>The draft in fact recommends four best practice cipher suites which
>should be preferred over the NOT RECOMMENDED weaker options.
>
>In section 6.1, the draft refers hostname verification to 6125,
>but 6125 contains little useful guidance for application protocols
>in which the server hostname is obtained indirectly via typically
>unauthenticated DNS SRV or MX records.  In such protocols, the
>server name is not a viable reference identity.  Some mention of
>the issue may be appropriate.
>
>    
>http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-12#section-1.3.2
>
>-- 
>	Viktor.
>
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls