Subject: Re: [Uta] [TLS] NULL cipher to become a MUST NOT in UTA BCP

From: Bodo Moeller <[email-masked]>
Date: Tue, 2 Sep 2014 23:30:37 +0200

Also note ​that the current plan for TLS 1.3 is to get rid of NULL
encryption entirely anyway (
http://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-02.txt), apart from
the initial TLS_NULL_WITH_NULL_NULL cipher suite, which exists only for
formal reasons and can't be negotiated.  (I don't know why TLS even has a
code point allocated for it.)  Nostalgia seems misplaced here.

In any case, these are supposed to be recommendations for secure use of TLS
and DTLS.  For insecure use, you're still free to do whatever you like.  If
protocol implementations meant for secure use don't make that easy, that's
a feature and not a bug.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 00:14:48 +0200

Sorry, it turns out that this discussion thread on the UTA I-D had
originally taken place in the TLS mailing list, and yet I managed to reply
to the UTA mailing list.

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 03 Sep 2014 13:23:58 +0100

On 3 September 2014 11:34:09 BST, Yutaka OIWA <[email-masked]> wrote:
>The document title is
>"Recommendations for Secure Use of TLS and DTLS",
>clearly applicable for the "Secure Uses".  It also says
>"These are minimum recommendations for the general use of TLS."
>
>For the purposes of such secure and general use cases,
>NULL ciphers are clearly "MUST NOT" with no doubt.
>
>If you have any "insecure", special (non-general) use cases of TLS,
>the document do not forbid you to use it,
>because the document is simply not applicable.
>However, such special use cases shall not make any
>hindrance for making a BCP document for general use cases.
>
>If you worry for implementors to drop codes for special use cases,
>you should say it loud to implementors, not to this document.
>Also, if you worry for making it hard to use, it is the
>fair cost for non-generic but supported use cases.
>Security libraries easily configurable for insecure setting
>is a huge security concern for general applications.
>
>One possible solution is to add a short note about
>such special uses, saying "it's out of this document's scope,
>but you should really take care of its security setting and
>consequences by yourself."

+1.

"MUST NOT transmit cleartext in TLS" in a BCP for general use on the internet is quite obviously the correct path. Any suggestion to the contrary is, with respect, indefensible.

That does not preclude very exceptional internal configurations which really do not require confidentiality: that isn't a general internet TLS profile at all, but one that obviously will require very special attention from all participants, who are free to agree whatever they'd like, BCPs be damned.

It's still not a good idea (or best current practice) to ever neglect to encrypt data where an attacker wanting it could conceivably be, however (including even internal networks, as Google, Yahoo and others have learned this year), and I'd continue to support and advocate NULL ciphersuites' complete removal from TLS 1.3 - and from all existing implementations of TLS in general use in the wild where it remains.

Wanting authenticated cleartext on any network (or local socket) is in my view such a very extraordinary, unusual and/or potentially dangerous scenario that I'd actually go as far as to suggest that anyone who REALLY honestly actually needs to use it ever should actually need to explicitly patch it back in - so that all involved know thereby that, truly, here be insatiably hungry, data-eating dragons. Actually using NULL is likely to be a decision they may later regret: we owe it to them to tell them so. (They would probably be much better served, if it's really that important to them, by not using TLS but something even more efficient, say Poly1305; or perhaps even simpler, non-cryptographic, access control mechanisms if a security boundary isn't actually being crossed.)

- --
/akr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Sep 2014 13:57:47 +0000

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.

[ Repost from tls list earlier today.  My cycles for UTA are very
  limited, please pardon my jumping in here out of context.  Generally
  speaking my inclination about improving security is to create
  and promote stronger options, without necessarily disabling weaker
  options.  Even weaker options can be better than having to resort
  to cleartext because the minimum standard required to get any
  security is too strong or not sufficiently interoperable. ]

I'd like to respond to the UTA draft more broadly.

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.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 4 Sep 2014 16:11:04 +0200

>
> [...]
> > However, I think a major problem in this case it that
> > draft-ietf-uta-tls-bcp-02 isn't actually clear about its intended scope:
> > what does "secure use" actually mean? As pointed out before, the document
> > uses the term "completely insecure" in a very fuzzy (and wrong) way --
> > authentication and integrity assurance without confidentiality isn't
> > "completely" insecure: it obviously won't give you confidentiality, but
> > still achieves other security notions.
> >
> > "Securing application-layer protocols" versus "specialized purposes"
> doesn't
> > appear to be a very useful distinction for standardization purposes
> > (*everything* that runs on top of TLS is an "application-layer
> protocol", as
> > far as TLS is concerned anyway), so I essentially agree to Uri -- this
> looks
> > like an attempt of ending up somewhere in between "MUST NOT" and "SHOULD
> > NOT", and is not really acceptable. Also, those using integrity-only
> cipher
> > suites clearly *do* want to secure their application-layer protocols,
> which
> > takes us back to the problem about fuzzy "security" terminology in this
> I-D.
> >
> > So shouldn't the BCP document clarify its scope by being explicit that
> the
> > recommendations only apply if your security goals do include
> > confidentiality?  In TLS 1.2, confidentiality very clearly is
> > *intentionally* optional.  If you create recommendations for its use and
> > change this underlying assumption, you should be very clear about the
> scope
> > of your recommendations.
> >
> > Bodo
>

2014-09-04 11:10 GMT+02:00 Yutaka OIWA <[email-masked]>:

> Dear Bodo,
>
> I agree, the most important point in my previous mail is
> whether the document is applicable for all use cases.
> Tracks and WG are not definitive regarding this.
> Sorry for any uncleanness.
> # The intention of me to include these words was
> # just to guess the document's intentions.
>
> So, the most important point I think is that
> we have a fairly broad range of "general use cases"
> which need a common strong BCP for TLS configurations.
> Current TLS 1.2 specification is too relaxed about this
> (intentionally, to support other use cases as well).
>
> In other words, the UTA draft is actually defining a
> secure restricted subset of TLS 1.2 (and 1.3+) for
> some subclass of use cases, and intend to force
> such restriction to "such use cases" on the Internet,
> using a "MUST-NOT" requirement term.
>
> I think it's quite important to clarify in which class of
> use cases UTA is intended to apply such a restriction.
> Currently "general use cases" is not well-defined and
> may misguide readers (including implementors) that
> NULL ciphers are forbidden in ALL use cases of TLS 1.2.

I agree, and I think what you're saying here is completely in line with
what I said before -- quoted above again just because I'm sending this
reply to the UTA mailing list rather than the TLS mailing list.

Bodo