Subject: [Uta] nullL ciphers revisited / draft-ietf-uta-tls-bcp-08

From: Tapio Sokura <[email-masked]>
Date: Sun, 21 Dec 2014 05:23:53 +0200

Hello,

I went through some discussions on null ciphers and didn't see this, my
apologies if this view has already been covered: There are cases where
you either can't (due to legal reasons) or don't want to (performance
reasons) encrypt, but would still like to have integrity protection and
be certain you are talking to the right party.

One example of a legal reason is amateur radio, which by definition in
most jurisdictions requires plaintext communications, but allows
integrity protection and authentication. Granted this is a tiny minority
of TLS users and use, but I don't really see much harm in keeping null
ciphers in play. Turning the knobs by default to positions that don't
allow null is fine, but the users should be able to turn those knobs
into other positions if they want to.

So the draft-ietf-uta-tls-bcp-08 section 4.1 first MUST NOT would in my
view be better as SHOULD NOT, with a rationale acknowledging those cases
where you don't want or can't have confidentiality. If you want to keep
the MUST NOT wording, at least add a few words to the rationale section
explaining the above exceptions. This way those software authors that
read the BCP might make an informed choice and let the users turn on
null ciphers themselves if they want to.

  Tapio

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 21 Dec 2014 18:14:27 -0500

>where you don't want or can't have confidentiality.

No, the fact that there are places where you can't/won't do data privacy should not weaken the case that doing this is, in fact, a best practice.

Not everyone and everything can do best practices.  If they could, they would be common, not best.

---

From: Ralph Holz <[email-masked]>
Date: Mon, 22 Dec 2014 11:51:11 +1100

Hi,

+1 to Rich's answer. @Tapio, we've discussed this extensively between
members of the TLS WG and UTA WG, to the considerable chagrin of some, and
managed to reach a compromise everyone could live with.

The current version is very carefully worded to allow operators to deviate
from the BCP in cases as you describe, while making it clear that they are
not following a best practice anymore and are on their own. We cannot list
all potential corner cases where deviating may be sensible, and I think we
should maintain that a Best Practice includes forbidding NULL.

BTW, with other IETF efforts to forbid RC4 on the grounds that it is
insecure, it seems curious that one would allow NULL in a Best Practice.

Ralph

On 22 December 2014 at 10:14, Salz, Rich <[email-masked]> wrote:

> No, the fact that there are places where you can't/won't do data privacy
> should not weaken the case that doing this is, in fact, a best practice.
>

---

From: Tapio Sokura <[email-masked]>
Date: Mon, 22 Dec 2014 03:32:24 +0200

Hi,

Thanks for the replies guys, I understand your viewpoint. I'm just
worried that in the future the knobs for corner cases like deliberately
turning on NULL won't be in the software/specs at all. If you are in a
scenario where you can't encrypt and NULL ciphers can't be used because
the software/specs don't support it, then you can't use TLS at all, not
even for providing integrity and authentication.

I did notice the wordings that limit the applicability of the BCP in
these kinds of cases. Anyway there's a difference between intentionally
running no crypto and running a so-so crypto like RC4 with TLS; if you
intentionally run crypto to provide confidentiality you might as well
run the best you can.

  Tapio

On 22.12.2014 2:51, Ralph Holz wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 22 Dec 2014 04:15:06 +0100

> intentionally run crypto to provide confidentiality you might as well

I don't understand the argument here. These are very specific corner
cases. In these you'd probably use older versions of the protocol
that support NULL ciphers on both ends.

For example, in the HPC community it's quite common for large file
transfers to use SSH with a NULL cipher (since data confidentiality
is mostly not an issue - depending on the project and so on). PSC
maintains a patched version of SSH/SCP for exactly that purpose:
http://www.psc.edu/index.php/hpn-ssh

That being said - a couple of months ago I benchmarked their MT-CTR
patches against upstream OpenSSH, their performance was worse than
upstreams without these specific patches. Which reminds me, I should
write them a mail about that.

Aaron