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

Ralph Holz <holz@net.in.tum.de> Wed, 03 September 2014 20:55 UTC

Return-Path: <holz@net.in.tum.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D381A710D for <tls@ietfa.amsl.com>; Wed, 3 Sep 2014 13:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hezJaZ1wzCF for <tls@ietfa.amsl.com>; Wed, 3 Sep 2014 13:55:24 -0700 (PDT)
Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46CCA1A70FD for <tls@ietf.org>; Wed, 3 Sep 2014 13:54:37 -0700 (PDT)
Received: by smtp.serverkommune.de (Postfix, from userid 5001) id DC22B80886; Wed, 3 Sep 2014 22:54:35 +0200 (CEST)
Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 59C8280869; Wed, 3 Sep 2014 22:54:34 +0200 (CEST)
Message-ID: <5407800A.20100@net.in.tum.de>
Date: Wed, 03 Sep 2014 22:54:34 +0200
From: Ralph Holz <holz@net.in.tum.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>, Nico Williams <nico@cryptonector.com>
References: <54048985.1020005@net.in.tum.de> <CAMeZVwtQ09B6Ero2C=75m5JdAYnEAENNcESd_gg_Ro2UhA9dyA@mail.gmail.com> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> <540770DF.105@net.in.tum.de> <CAK3OfOgY8vX-_CwDqKcEYq5v+OHG-FfD7tcYv4dXC6JrZJq+yQ@mail.gmail.com> <540776FC.7030409@net.in.tum.de> <CAK3OfOhvTS=wnH5yGnuFk0w_RH+op+Hg5iEKW2DrxuAu-Hoeqw@mail.gmail.com> <54077AE4.7050209@net.in.tum.de> <CAK3OfOjixXKnVCSnd0w6NQ0Y+fxJ9rM5auukWFQkRZ4Z6pHqYg@mail.gmail.com> <1DAFD0E6-37A6-4FEB-AC54-D4E80721D92A@ll.mit.edu>
In-Reply-To: <1DAFD0E6-37A6-4FEB-AC54-D4E80721D92A@ll.mit.edu>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.1 at ex6
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2_kTXgpd7rTtVPiKflpeZ6DBdPA
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Sep 2014 20:55:25 -0000

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


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