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

From: Ralph Holz <[email-masked]>
Date: Mon, 01 Sep 2014 16:58:13 +0200

Dear list,

I would like to notify the list of a feature in the draft for Best
Practices "Recommendations for Secure Use of TLS and DTLS"

	http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02

=> "Implementations MUST NOT negotiate the NULL cipher suites"

This may lead to implementations dropping NULL (or making it hard to
enable).

There used to be one reasonable use case for NULL that I am personally
aware of: grid traffic between large computing centres. Our group did
see such high-speed, high-volume traffic on our network monitors when we
did SSL/TLS/X.509 analyses - that was 3 years ago.

My contacts at grid centres tell me that NULL encryption was useful then
as the data was public anyway and good integrity was all that was
needed. I am told by one centre at least there is no real need for NULL
any more. In fact, the agreement seems to be that that cipher should be
eliminated now.

My personal take as one of the authors of the BCP is that the UTA WG
should process UNLESS someone has a use case that is relevant on the
same scale, or thinks the above statement does not hold in general.

In that case, please bring your use case to the attention of the UTA or
directly to the authors (i.e. Yaron Sheffer, [email-masked], or
me). We would like to keep any discussion focused.

Thanks,
Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 2 Sep 2014 15:15:10 +0000

IMHO there is a need for integrity-only protection. Monitoring traffic inside your administrative boundary is one obvious example. 

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Ralph Holz [mailto:[email-masked]]
Sent: Monday, September 01, 2014 10:58 AM
To: [email-masked] <[email-masked]>
Subject: [TLS] NULL cipher to become a MUST NOT in UTA BCP

Dear list,

Thanks,
Ralph

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Sep 2014 15:23:08 +0000

> same scale, or thinks the above statement does not hold in general.

Postfix supports authenticated NULL ciphers for communication
between an MTA and local (127.0.0.1 or ::1) LMTP server.  Encrypting
local IPC is just a waste of CPU.  Yes, this is a specialized use-case.

This can also be useful for access-controlled hand-off between
reverse HTTP proxies, and web applications that support client
certificates.  These are sometimes used to implement GSSAPI SPNEGO
support in front of application that don't support GSSAPI.  The
application is configured to listen on 127.0.0.1, but is then
vulnerable to impersonation attacks from anything running on the
host.  With authenticated NULL ciphers, the connection can be
restricted to just the front-end reverse proxy.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Sep 2014 08:58:24 -0700

> IMHO there is a need for integrity-only protection. Monitoring traffic inside your administrative boundary is one obvious example. 

That's not at all an "obvious" example for TLS. What could TLS integrity-only protection buy you in that environment? It is only of value if you can act when the integrity is broken, such as modified packets. And yet there are essentially no systems where there is an administrative interface for TLS that says what to do when the integrity is broken. And yet there are *plenty* of examples of how to do this with integrity-only IPsec.

I support NULL encryption being a MUST NOT as long as IPsec supports null encryption for the use cases that people want to force on TLS.

--Paul Hoffman

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Sep 2014 12:05:30 -0400

> Encrypting local IPC is just a  waste of CPU.

Not always.  Imagine a component that had a root-priv escalation incident after the system was booted.  PFS for local IPC would keep that communication secure until the adversary managed to break one of the communicating processes. We believe that would take much longer than just the initial RSE.
 
--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked] Twitter: RichSalz

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Sep 2014 16:23:22 +0000

On Tue, Sep 02, 2014 at 12:05:30PM -0400, Salz, Rich wrote:
> Not always.  Imagine a component that had a root-priv escalation
> incident after the system was booted.  PFS for local IPC would keep
> that communication secure until the adversary managed to break one
> of the communicating processes. We believe that would take much
> longer than just the initial RSE.

Root can generally read the data before it is encrypted (debug the
sending or receiving process for example).  Yes, "tcpdump lo" is
easier.  So while my statement could gain a qualifier that hedges
it somewhat, it is essentially correct as is.  FWIW, in the case
of local IPC with MTA to MailStore LMTP, the connections tend to
be rather short-lived.

-- 
	Viktor.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 2 Sep 2014 14:03:24 -0400

On Sep 2, 2014, at 11:58 , Paul Hoffman <[email-masked]> wrote:
> That's not at all an "obvious" example for TLS.

I knew I'd bait somebody at least. :-)

> What could TLS integrity-only protection buy you in that environment?

Traffic visibility for those who are responsible for monitoring, and integrity protection who want tamper detection but don't require (or aren't allowed to have) confidentiality.

> It is only of value if you can act when the integrity is broken, such as modified packets.

Of corse. AFAIK, TLS would just reject modified packets, won't it? 

> And yet there are essentially no systems where there is an administrative interface for TLS that says what to do when the integrity is broken. And yet there are *plenty* of examples of how to do this with integrity-only IPsec.

My personal opinion is that VPN should be built upon IPsec, not TLS. Unfortunately, the market does not seem to agree. I see (in my environment) the need to (sometimes) run a VPN across the corporate boundary. One implication is - IT on both sides want to examine the traffic, at the same time ensuring nothing is injected into the stream. 

> I support NULL encryption being a MUST NOT as long as IPsec supports null encryption for the use cases that people want to force on TLS.

I am all for IPsec. Unfortunately, most of the VPNs we're dealing with now are TLS-based (and my dislike cannot alter this fact).

Besides, I don't think it is wise to limit usability of a tool because there may be another tool that could do it.

---

From: Ralph Holz <[email-masked]>
Date: Tue, 02 Sep 2014 21:45:51 +0200

Hi,

> Traffic visibility for those who are responsible for monitoring, and
> integrity protection who want tamper detection but don't require (or
> aren't allowed to have) confidentiality.

Is this a real use case? I.e., do you really know
companies/organisations that do this?

> My personal opinion is that VPN should be built upon IPsec, not TLS.
> Unfortunately, the market does not seem to agree. I see (in my
> environment) the need to (sometimes) run a VPN across the corporate
> boundary. One implication is - IT on both sides want to examine the
> traffic, at the same time ensuring nothing is injected into the
> stream.

Why can't they simply monitor on the two gateways?

Or are you suggesting a setup where an organisation fowards internal
traffic via a tunnel, only integrity-protected? Why that?

> I am all for IPsec. Unfortunately, most of the VPNs we're dealing
> with now are TLS-based (and my dislike cannot alter this fact).

I'd disagree with that, but that's another topic. :)

Ralph

---

From: Ralph Holz <[email-masked]>
Date: Tue, 02 Sep 2014 21:47:08 +0200

Hi,

> restricted to just the front-end reverse proxy.

Both seem to be real corner cases - wouldn't they be covered just as
well with encryption prescribed?

Ralph

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Sep 2014 19:51:48 +0000

> well with encryption prescribed?

Yes, these are "corner cases".  A sufficiently broadly applicable
tool has a lot of corners.

While I agree that NULL ciphers should not be enabled *by default*,
making NULL ciphers a "MUST NOT" seems rather too strong.  Why burn
limited CPU cycles doing nothing useful (encrypting local IPC).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Sep 2014 20:02:00 +0000

> limited CPU cycles doing nothing useful (encrypting local IPC).

I forgot to mention one thing.  In Postfix for any given destination
either *no* NULL ciphers are enabled, or *only* NULL ciphers are
enabled.  I have no objection to language that prohibits NULL ciphers
when any non-NULL ciphers are enabled.

-- 
	Viktor.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 2 Sep 2014 14:01:22 -0700

]-----Original Message-----
]From: TLS [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
]Sent: Tuesday, September 02, 2014 12:52 PM
]To: [email-masked]
]Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP
]
]On Tue, Sep 02, 2014 at 09:47:08PM +0200, Ralph Holz wrote:
]
]> > Postfix supports authenticated NULL ciphers for communication
]> > between an MTA and local (127.0.0.1 or ::1) LMTP server.  Encrypting
]> > local IPC is just a waste of CPU.  Yes, this is a specialized use-
]case.
]> >
]> > This can also be useful for access-controlled hand-off between
]> > reverse HTTP proxies, and web applications that support client
]> > certificates.  These are sometimes used to implement GSSAPI SPNEGO
]> > support in front of application that don't support GSSAPI.  The
]> > application is configured to listen on 127.0.0.1, but is then
]> > vulnerable to impersonation attacks from anything running on the
]> > host.  With authenticated NULL ciphers, the connection can be
]> > restricted to just the front-end reverse proxy.
]>
]> Both seem to be real corner cases - wouldn't they be covered just as
]> well with encryption prescribed?
]
]Yes, these are "corner cases".  A sufficiently broadly applicable tool
]has a lot of corners.
]
]While I agree that NULL ciphers should not be enabled *by default*,
]making NULL ciphers a "MUST NOT" seems rather too strong.  Why burn
]limited CPU cycles doing nothing useful (encrypting local IPC).

I disagree, and support the draft as written.  
'MUST NOT' is the appropriate recommendation for NULL ciphers.

Paul

]
]--
]	Viktor.
]
]_______________________________________________
]TLS mailing list
][email-masked]
]https://www.ietf.org/mailman/listinfo/tls

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 00:11:15 +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: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 2 Sep 2014 23:26:33 +0000

Yes I really do know such organizations. You can call it "first hand experience".

Why not "MiTM" - aka "cracked SSL"? My personal take: I prefer my security guarantees - whatever they are - to be end-to-end. Especially integrity/authenticity. And interrupting the flow at the gateway breaks this. There could be other reasons, which I may not know or think of (not working closely with IT). (Also, I hope you didn't miss the "not allowed" part.)

I add that I violently disagree with Paul L., and insist that while NULL ciphers should not be enabled by default - they "must not" be "MUST NOT"-ed.

----- Original Message -----
From: Ralph Holz [mailto:[email-masked]]
Sent: Tuesday, September 02, 2014 03:45 PM
To: [email-masked] <[email-masked]>
Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP

Hi,

Ralph

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Sep 2014 18:44:05 -0500

> Why not "MiTM" - aka "cracked SSL"? My personal take: I prefer my security guarantees - whatever they are - to be end-to-end. Especially integrity/authenticity. And interrupting the flow at the gat…

Trusting proxies is likely something we'll have to live with in some

> I add that I violently disagree with Paul L., and insist that while NULL ciphers should not be enabled by default - they "must not" be "MUST NOT"-ed.

We can't really keep people from pointing a loaded gun at their feet
and pulling the trigger.  We can make them take some extra effort to
_load_ the thing, and that's as far as we ought to go.

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 03 Sep 2014 09:55:06 +0200

> 'MUST NOT' is the appropriate recommendation for NULL ciphers.

Putting such strong wording there is a recipe for the document's advices
to be ignored. A "MUST NOT" in a document like that will not prevent me
from using that ciphersuite if I need it, and most probably neutralize
every other positive advice given by that draft. "MUST NOT" must be
really "must not", not "some people don't have a use case for it".

regards,
Nikos

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 3 Sep 2014 19:34:09 +0900

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

-- 
Yutaka OIWA, Ph.D.                 Leader, System Life-cycle Research Group
                               Research Institute for Secure Systems (RISEC)
     National Institute of Advanced Industrial Science and Technology (AIST)
                       Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 3 Sep 2014 12:10:47 -0400

> "These are minimum recommendations for the general use of TLS."
                     ^^^^^^^^
Exactly.

> NULL ciphers are clearly "MUST NOT" with no doubt.

"Clearly" and "with no doubt"? With respect, this doesn't seem to be your field of expertise.

> hindrance for making a BCP document for general use cases.

There can be no generic "secure" (or "insecure") - only "secure regarding ...". 

One implication is that unless threat to data confidentiality is a concern, trying to make the data-in-transit confidential would be a waste of resources and time. Not to mention that some admin domains restrict the right to keep the data confidential. 

Others made it clear that (a) it should be stated that NULL cipher SHOULD NOT be enabled (by default, at least), but (b) it must not be listed "MUST NOT". People would simply disregard (and justly so!) a document that places such silly and unrealistic demands.

I'm skipping the rest, as it doesn't seem that it needs an answer.

---

From: Ralph Holz <[email-masked]>
Date: Wed, 03 Sep 2014 19:29:58 +0200

Good day,

Please do not forget that the MUST NOT concerns a recommendation what to
negotiate - it was only my impression that the current wording may lead
implementers to drop it entirely.

I have had some very good feedback on this list. In addition, I have
been in touch with people who run Grid centres and solicited their
opinion (they do have setups with NULL).

My impression from all this is that the wording in the BCP should be
slightly altered, to:

"Deployments of TLS to secure application-layer protocols MUST NOT
negotiate the NULL cipher. Note: TLS implementations MAY retain code for
the NULL cipher for other specialised purposes like testing, etc."

That will make it clear that implementers are free to retain NULL (and
they will), but that the purpose of the BCP is to propose secure TLS
configurations to protect application-layer protocols, and for those no
deployment should ever negotiate NULL. This is particularly interesting
if TLS 1.3 is going to drop NULL, too.

The above is what I have suggested to the lead author, and it's what I
am going to vote for.

Ralph

On 09/03/2014 06:10 PM, Blumenthal, Uri - 0558 - MITLL wrote:
>> The document title is "Recommendations for Secure Use of TLS and
>> DTLS", clearly applicable for the "Secure Uses".  It also says 
> ^^^^^^^^ Exactly.
>> 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.
> 
> One implication is that unless threat to data confidentiality is a
> concern, trying to make the data-in-transit confidential would be a
> waste of resources and time. Not to mention that some admin domains
> restrict the right to keep the data confidential.
> 
> Others made it clear that (a) it should be stated that NULL cipher
> SHOULD NOT be enabled (by default, at least), but (b) it must not be
> listed "MUST NOT". People would simply disregard (and justly so!) a
> document that places such silly and unrealistic demands.
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 17:49:58 +0000

On Wed, Sep 03, 2014 at 07:29:58PM +0200, Ralph Holz wrote:

> deployment should ever negotiate NULL.

This is still too strong.  Local MTA to Mail-Store LMTP is an
application protocol.  It is a fine use-case for NULL ciphers.

What is much more reasonable is that initiators (clients) should
refuse to negotiate (should suppress any configured) NULL cipher
suites when any non NULL cipher suite is enabled.  This prevents
accidents, without breaking carefully considered NULL to NULL
deployments.

-- 
	Viktor.

---

From: Ralph Holz <[email-masked]>
Date: Wed, 03 Sep 2014 20:00:43 +0200

> application protocol.  It is a fine use-case for NULL ciphers.

I hear you (and the others), but balancing the purpose of the BCP with
such requirements as you mention leads me to believe we should favour
the solution I proposed. I added one more thing, though:

"Note: TLS implementations MAY retain code for the NULL cipher to allow
specialised purposes like debugging, custom solutions, etc."

That "custom solution" - to me - seems to address what you describe. I
see no other way to balance the requirements.

If the vote were black/white between dropping and keeping, I'd favour
dropping, by the way. I'd rather protect the many.

Ralph

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Wed, 3 Sep 2014 14:46:51 -0400

On Sep 3, 2014, at 14:00 , Ralph Holz <[email-masked]> wrote:
> specialised purposes like debugging, custom solutions, etc.”

Guys, 

Per RFC2119, certain words have certain meanings. :-)

In particular, “MUST NOT” means not that “don’t do that unless you can claim an exception”. It means “don’t do that as it is absolutely prohibited by this spec, no exception”.

What you probably want to specify here is “SHOULD NOT”.

Before replying - please check with RFC 2119. It’s three pages long, so wouldn’t take much of your time.

(P.S. I wish people got really familiar with the standard terminology before trying to write/edit a standard.)

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 18:52:44 +0000

> specialised purposes like debugging, custom solutions, etc."

I can probably live with that.

> dropping, by the way. I'd rather protect the many.

While probably not an issue in this case, we need to be careful
when trying to "raise the bar" to "protect the many".  If the bar
is raised too high, the obvious operator solution is to switch to
cleartext, no security impediments there. :-(

Don't let the perfect be the enemy of the good. Ciao.

-- 
	Viktor.

---

From: Geoffrey Keating <[email-masked]>
Date: 03 Sep 2014 12:35:03 -0700

> "Clearly" and "with no doubt"? With respect, this doesn't seem to be

This is my field of expertise, and I agree that for the purpose of
secure and general use cases, NULL ciphers are both clearly and
without a doubt "MUST NOT".

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Wed, 3 Sep 2014 15:35:07 -0400

On Sep 3, 2014, at 15:23 , Ralph Holz <[email-masked]> wrote:
> MUST NOT is correct. Nowhere does RFC2119 say that the term deployment equals implementation in code.

Misunderstanding of the RFC, IMHO.

> You are welcome to bring up your strong feelings in UTA.

I’m doing that.

1. Draft is poorly written because terms like “completely insecure” without context of threats are completely meaningless (page 6, bottom).

2. Giving recommendations for “secure use” without defining what the goals are is again meaningless.

But if you insist on making this document irrelevant - it’s your right to do so.

> On 3 September 2014 20:46:51 CEST, "Blumenthal, Uri - 0668 - MITLL" <[email-masked]> wrote:
>  such
> requirements as you mention leads me to believe we should favour
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Ralph Holz <[email-masked]>
Date: Wed, 03 Sep 2014 21:41:11 +0200

Good day,

MUST NOT is correct. Nowhere does RFC2119 say that the term deployment
equals implementation in code.

You are welcome to bring up your points in UTA.

Ralph

On 3 September 2014 20:46:51 CEST, "Blumenthal, Uri - 0668 - MITLL"
<[email-masked]> wrote:
>In particular, “MUST NOT” means not that “don’t do that unless you can
>claim an exception”. It means “don’t do that as it is absolutely
>prohibited by this spec, no exception”.
>

---

From: Ralph Holz <[email-masked]>
Date: Wed, 03 Sep 2014 21:49:51 +0200

Good day,

>> MUST NOT is correct. Nowhere does RFC2119 say that the term
>> deployment equals implementation in code.
> 

You will need to give evidence if you want others to follow your argument.

>> You are welcome to bring up your strong feelings in UTA.

If you want to, you need to write to the UTA list. Quite possibly,
you'll also have to elaborate more than the simple two items you gave here.

Ralph

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 15:07:17 -0500

> You will need to give evidence if you want others to follow your argument.

Ralph,

Uri is quite right.  You really should read RFC2119.  Here's the money quote:

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

There is absolutely no hedging there.  There is no more evidence to
post, really.  What more could you need?  "absolute prohibition" is as
clear as it gets.

Nico
--

---

From: Ralph Holz <[email-masked]>
Date: Wed, 03 Sep 2014 22:15:56 +0200

Hi Nico,

> post, really.  What more could you need?  "absolute prohibition" is as

Yes, I understand that, and apologies if that came out wrong. But the
meaning of MUST NOT is not what I asked for - rather, the difference
between "deployment" and "implementation". The reworded version in the
BCP would say that "deployments" MUST NOT negotiate the cipher. E.g.,
the cipher string in your Apache must not contain NULL.

The note following it then clarifies that the actual code (e.g. in the
openssl library) is free to contain the cipher.

If there is agreement that deployment = implementation, we'll need other
words to express this.

Hope that clears it up.

Ralph

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 15:24:48 -0500

> the cipher string in your Apache must not contain NULL.

This needs to apply to implementors.  It's hard to tell sysadmins to
not do certain things.  You need to tell implementors what to allow
for local policy.

Nico
--

---

From: Ralph Holz <[email-masked]>
Date: Wed, 03 Sep 2014 22:32:36 +0200

Hi,

> not do certain things.  You need to tell implementors what to allow

Is your argument thus that the BCP can only choose from two options?

* Drop NULL in code
* Retain NULL in code

I don't think this is the case:

"This document provides recommendations for improving the security of
both software implementations and deployed services that use TLS and
DTLS." (from the BCP)

While you may be right with what you say about sysadmins, I think the
suggested wording provides the right guidance for both deployment and
implementation.

Ralph

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 15:34:33 -0500

> Is your argument thus that the BCP can only choose from two options?

No.  I'm supporting Viktor's position.

Nico
--

---

From: Ralph Holz <[email-masked]>
Date: Wed, 03 Sep 2014 22:38:59 +0200

> No.  I'm supporting Viktor's position.

Sorry, can't follow. Viktor said he could live with the new wording?
Does this mean you agree with it?

Ralph

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Wed, 3 Sep 2014 16:46:27 -0400

> No.  I'm supporting Viktor's position.

If the implementors are told “MUST NOT” and comply with it - there would be no code to support NULL cipher, because if they leave the code in - they wouldn’t be compliant with the standard any more. It would be pointless to add “…implementations MAY retain…”, as the two statements directly contradict each other. Do you not see this contradiction?  (Treat this as a “legal" document, not a publication or an article.)

Again, if what you mean to state is “Don’t do this. But as an exception, in some (undesirable) cases you may.”, then “SHOULD NOT” is what the BCP should say.

Viktor said (Sep 2, 2014):

While I agree that NULL ciphers should not be enabled *by default*,
making NULL ciphers a "MUST NOT" seems rather too strong.

Also, I’d pay heed to what Nikos said:

---

From: Ralph Holz <[email-masked]>
Date: Wed, 03 Sep 2014 22:54:34 +0200

Hi Uri,

I still think there is a difference between a deployment and an actual
library, and re-reading the definition of BCP, I would arrive at the
conclusion it's possible to word it like I did.

But I recognise your position, and I will forward this.

Ralph

> If the implementors are told “MUST NOT” and comply with it - there
> would be no code to support NULL cipher, because if they leave the
> code in - they wouldn’t be compliant with the standard any more. It
> would be pointless to add “…implementations MAY retain…”, as the two
> statements directly contradict each other. Do you not see this
> contradiction?  (Treat this as a “legal" document, not a publication
> or an article.)
> 
> Again, if what you mean to state is “Don’t do this. But as an
> exception, in some (undesirable) cases you may.”, then “SHOULD NOT”
> is what the BCP should say.
> 
> Putting such strong wording there is a recipe for the document's
> advices to be ignored. A "MUST NOT" in a document like that will not
> prevent me from using that ciphersuite if I need it, and most
> probably neutralize every other positive advice given by that draft.
> "MUST NOT" must be really "must not", not "some people don't have a
> use case for it".
>

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 3 Sep 2014 21:37:02 +0000

>conclusion it's possible to word it like I did.

Based on my experience with IETF and its practices (which included writing
RFC’s and getting them through the process :), I disagree.

>But I recognise your position, and I will forward this.

Thank you!

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 4 Sep 2014 13:39:15 +0900

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

The possible problem is that it lacks the definition of
"general use cases", but at least for
over-Internet general communications like https or STARTTLS,
it's MUST-NOT, not even SHOULD-NOT.

All exceptional cases proposed on this topic
seems to be, in my opinion, better treated as a
"special use cases" not the target of this document.
We may clarify its applicable scopes, of course.

If the document were belonging to TLS WG,
it were on the standards track,
and looked like RFC 6176 (applicable for all use cases),
I could agree that it shall be "SHOULD NOT".
But it's UTA BCP document, and it's very important to
say "MUST NOT for general applications" here.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Sep 2014 05:46:42 +0000

On Thu, Sep 04, 2014 at 01:39:15PM +0900, Yutaka OIWA wrote:

> > What you probably want to specify here is ?SHOULD NOT?.
> 

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.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 4 Sep 2014 10:31:34 +0200

Yutaka OIWA <[email-masked]>:

> I could agree that it shall be "SHOULD NOT".

It certainly can't matter which Working Group the document came from. Also,
I don't think that issuing a BCP instead of a Proposed Standard means you
can use "MUST NOT" willy-nilly.

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

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 4 Sep 2014 18:10:22 +0900

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.

2014-09-04 17:31 GMT+09:00 Bodo Moeller <[email-masked]>:
> 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
> "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.
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Sep 2014 10:40:12 -0500

On Thu, Sep 4, 2014 at 3:31 AM, Bodo Moeller <[email-masked]> wrote:
> [...]

+1.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 4 Sep 2014 15:43:33 +0000

On 9/4/14, 5:10 , "Yutaka OIWA" <[email-masked]> wrote:

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

I’m afraid this goal has not been achieved.

>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

The problem is you have not defined what “use cases” your document
applies, and what cases it does not.

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

Again, the problem is the document does not define this subclass. It does
some hand-waving about “generic”, “good for majority”, etc. IMHO this is
absolutely not acceptable.

>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

YES!!  “Not too well defined” is “stating it too mildly”.

In fact, the way these things are currently specified in this draft - I’m
strongly against its publication/advancement. At least until they are
rectified.

>>doesn't

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 4 Sep 2014 15:57:55 +0000

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: (781) 981-1638

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Sep 2014 11:09:22 -0500

> this document’s recommendations DO apply.

Or make the advice useful enough for all cases.  For example, Viktor's
proposal as to when NULL ciphers should be allowed is quite sensible.

Nico
--

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 4 Sep 2014 16:23:14 +0000

On 9/4/14, 12:09 , "Nico Williams" <[email-masked]> wrote:

>On Thu, Sep 4, 2014 at 10:57 AM <[email-masked]> wrote:
>> YES to what Viktor said.
>>

Yes. But the tone of the discussion that’s been going on so far makes me
fairly certain that it is impossible to get the authors to agree to make
this document useful for all cases.

Which is why I hope instead that the WG can convince them to define what
[sub]classes or what *specific* use cases their recommendations do apply.

IMHO, in any case (no pun intended :) it is {much better & much safer &
technically more appropriate} to define what conditions something applies
to/can be used in, rather than trying to define all the exceptions.

---

From: Ralph Holz <[email-masked]>
Date: Thu, 04 Sep 2014 19:42:52 +0200

> this document useful for all cases.

I think that would be a most unfruitful endeavour as the resulting
document would benefit no-one. There is always a use case that requires
the lowest possible security settings.

> [sub]classes or what *specific* use cases their recommendations do apply.

I would support such a clarification and will talk to the other authors.

Ralph

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 4 Sep 2014 17:49:55 +0000

>the lowest possible security settings.

The problem is not “lowest security settings”, but lack of stringent
definition what EACH (not just the lowest) described setting is good for,
what it protects against, and when it should AND SHOULD NOT be used. This
is exactly what the current draft is missing.

>I would support such a clarification and will talk to the other authors.

Needless to say, I would support it too.

P.S. I wouldn’t call it “clarification” - you cannot clarify what hasn’t
been defined at all yet. :-)

---

From: Ralph Holz <[email-masked]>
Date: Thu, 04 Sep 2014 19:53:09 +0200

Hi,

> is exactly what the current draft is missing.

Do you mean a general discussion in a new half-page/one-page section by
that?

Ralph

---

From: Barry Leiba <[email-masked]>
Date: Thu, 4 Sep 2014 21:20:36 +0300

(1) Why are these messages not on the UTA list?  I strongly suggest
that they be repeated there.

(2) Uri, why did you specifically send this to me?

Barry

On Thu, Sep 4, 2014 at 7:09 PM, Nico Williams <[email-masked]> wrote:
>> 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.
>

---

From: Bill Frantz <[email-masked]>
Date: Thu, 4 Sep 2014 21:06:29 -0700

>not do certain things.  You need to tell implementors what to allow

I really like Victor's suggestion that implementations MUST NOT 
present both encryption and NULL cypher suites on a connection. 
They could either refuse to start up when configured with both, 
or they could silently remove the NULL cypher suites.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said 
users haven't
www.pwpconsult.com | learned anything about security?" -- Bruce Schneier

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 05 Sep 2014 09:07:30 -0400

On 09/05/2014 12:06 AM, Bill Frantz wrote:
> I really like Victor's suggestion that implementations MUST NOT present
> both encryption and NULL cypher suites on a connection. 

I like this suggestion as well, and think it does fit as a MUST NOT here
-- none of the edge use cases for NULL ciphersuites that i've heard
mentioned would run afoul of it.

> They could
> either refuse to start up when configured with both, or they could
> silently remove the NULL cypher suites.

Or *not-so-silently* remove the NULL cipher suites -- warnings that
point to a rationale for refusing misconfiguration are helpful to the
sysadmin :)

Are there any objections to including Victor's suggestion in the draft?

	--dkg

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 5 Sep 2014 15:30:55 +0200

Daniel Kahn Gillmor <[email-masked]>:

I actually think it would be more appropriate for the UTA BCP to expressly
confine itself to making recommendations for applications that *do* have a
desire for confidentiality, rather than trying to also regulate the wider
area of applications with more esoteric needs.

If NULL encryption cipher suites can't be enabled together with non-NULL
encryption cipher suites, you'd break any server that attempts to allow
NULL encryption for clients that decide they don't need encryption (e.g.,
because they're connecting to localhost) while supporting non-NULL ciphers
for clients that don't offer NULL encryption for whatever reason (e.g.,
because the implementor just doesn't like NULL encryption, which I think is
a position worthy of support).  Same for clients.  I'd rather prefer for
the BCP to avoid this quagmire entirely.

Bodo

---

From: Ralph Holz <[email-masked]>
Date: Fri, 05 Sep 2014 15:33:28 +0200

On 09/05/2014 03:30 PM, Bodo Moeller wrote:
> Daniel Kahn Gillmor <[email-masked] <mailto:[email-masked]>>: 
> 
> I actually think it would be more appropriate for the UTA BCP to
> expressly confine itself to making recommendations for applications that
> *do* have a desire for confidentiality, rather than trying to also
> regulate the wider area of applications with more esoteric needs.

I agree with Bodo.

Ralph

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Fri, 05 Sep 2014 15:48:05 +0200

On 05/09/2014 15:30, Bodo Moeller wrote:
> a position worthy of support).

I think Viktor's suggestion was that *clients* MUST NOT offer both NULL and
non-NULL ciphersuites (and perhaps that servers SHOULD (or even MUST?) reject
ClientHellos containing a mixture of NULL and non-NULL), but that servers are
free to have both types of suites enabled at the same time.

I don't have an opinion on whether this is an appropriate option for the BCP
document, IMO it depends on how its scope will be defined, but I just wanted to
clarify.

Manuel.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Sep 2014 13:49:48 +0000

> the BCP to avoid this quagmire entirely.

This is why my suggestion was specifically about the initiator
(client):

It leaves room for dual-purpose servers.

-- 
	Viktor.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Fri, 05 Sep 2014 15:57:29 +0200

> local IPC is just a waste of CPU.  Yes, this is a specialized use-case.
I realise encrypting local communications looks like a waste, but I'm curious if
we can make this assertion more quantitative. With a typical workload, do you
have any idea how much more CPU would be used by starting to encrypt these
communications? (Eg with AES-GCM, both with and without hardware support.)

What would be an acceptable performance penalty?

Manuel.

---

From: Ralph Holz <[email-masked]>
Date: Fri, 05 Sep 2014 16:16:54 +0200

Hi,

> It leaves room for dual-purpose servers.

I am opposed to such a definition - I think it would a) be too hard to
describe the rationale and why it should apply b) lead to insecure
configurations because there is Yet Another Cornercase We Didn't Think
Of and c) is better caught with a refined purpose statement/statement of
applicability.

Ralph

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 5 Sep 2014 17:18:21 +0300

> communications? (Eg with AES-GCM, both with and without hardware support.)

AES128-GCM with hardware support would use _less_ CPU (without it would use
more) than any current NULL ciphersuite (NULL_SHA1 is the fastest). 

-Ilari

---

From: Nico Williams <[email-masked]>
Date: Fri, 5 Sep 2014 09:30:17 -0500

> more) than any current NULL ciphersuite (NULL_SHA1 is the fastest).

But where are your numbers?  That's what Manuel asked for.

And anyways, "CPU cycles" aren't what matters here.  Throughput and
latency are, as well as overall power.

Nico
--

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Fri, 5 Sep 2014 10:41:57 -0400

> Of and c) is better caught with a refined purpose statement/statement of

I would support such a definition as the preferred way of dealing with this issue, but can accept a refined crystal-clear statement of applicability (*) that crisply defines(**) what specific use case(s) this draft is covering. 

As for “too hard to describe” - you don’t need to dive into rationale of “why the user may want to apply this protection, or disable that one”. Just clearly state in layman’s terms what a given protection - and its lack - would result in. Then there would be no corner cases. It is up to the domain owner to decide what protection is required. You/we cannot (and shouldn't try to) think for all of them.

(*)  I would make clear that this BCP applies _only_ to deployment configuration, and _not_ as an implementation guide.

(**) “Crisply” implies avoiding Watson’s “at least 99%", "almost certainly have”, and other similar “scientific” terms.
--
Regards,
Uri               <[email-masked]>

---

From: Ralph Holz <[email-masked]>
Date: Fri, 05 Sep 2014 17:10:48 +0200

Hi,

>> I am opposed to such a definition - I think it would a) be too hard
>> to describe the rationale and why it should apply b) lead to
>> insecure configurations because there is Yet Another Cornercase We
>> Didn't Think Of and c) is better caught with a refined purpose
>> statement/statement of applicability.

[...]

> As for “too hard to describe” - you don’t need to dive into rationale
> of “why the user may want to apply this protection, or disable that
> one”. Just clearly state in layman’s terms what a given protection -
> and its lack - would result in. Then there would be no corner cases.

I think such a description can be added as half a section/page. Would
you be willing to contribute it?

Ralph

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 5 Sep 2014 23:27:27 +0200

> It leaves room for dual-purpose servers.

Thanks for the clarification -- so I should have expanded the very terse "Same
for clients": A client content with NULL encryption may want to offer
non-NULL cipher suites in the same ClientHello in case the server doesn't
accept NULL encryption for whatever reason (e.g., because the implementor
doesn't like NULL encryption).

As noted before, I think the BCP doesn't have to deal with issues like
this, and instead should provide recommendations just for applications that
want to achieve confidentiality.

Bodo

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Sep 2014 21:49:09 +0000

> doesn't like NULL encryption).

My thinking is that clients SHOULD NOT offer NULL, unless they
explicitly want NULL and know that it will be excepted.  Clients
that are laissez-faire about whether they get no encryption or not
seem negligent to me.  If they don't need whatever performance or
transparency for troubleshoots they might get from NULL, they should
just always go with non-NULL.

This is not a proof that the mixed case has no compelling scenarios,
just can't think of any as yet.

> want to achieve confidentiality.

That's fine too.  I was mostly trying to non-destructively accommodate
the impulse to do something normative along the lines of the original
proposal.

-- 
	Viktor.