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

"Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu> Wed, 03 September 2014 18:50 UTC

Return-Path: <prvs=4323ef581d=uri@ll.mit.edu>
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 953BB1A06EE for <tls@ietfa.amsl.com>; Wed, 3 Sep 2014 11:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.867
X-Spam-Level:
X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 bUfnWoMxnYwS for <tls@ietfa.amsl.com>; Wed, 3 Sep 2014 11:50:46 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0E91A04B9 for <tls@ietf.org>; Wed, 3 Sep 2014 11:50:45 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s83Io3R1022762; Wed, 3 Sep 2014 14:50:23 -0400
Content-Type: multipart/signed; boundary="Apple-Mail=_943A533C-5F4D-4829-BE6A-D334C397AD0D"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
In-Reply-To: <5407574B.5060708@net.in.tum.de>
Date: Wed, 03 Sep 2014 14:46:51 -0400
Message-ID: <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu>
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>
To: Ralph Holz <holz@net.in.tum.de>, "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-03_08:2014-09-03,2014-09-03,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409030197
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iOVyjnq6KrDaSRzJu6VWiPFdXjE
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 18:50:48 -0000

On Sep 3, 2014, at 14:00 , Ralph Holz <holz@net.in.tum.de> wrote:
>>> 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 still too strong.  Local MTA to Mail-Store LMTP is an
>> 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.”

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