Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP
Yutaka OIWA <y.oiwa@aist.go.jp> Thu, 04 September 2014 04:39 UTC
Return-Path: <y.oiwa@aist.go.jp>
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 70FDF1A029F for <tls@ietfa.amsl.com>; Wed, 3 Sep 2014 21:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.679
X-Spam-Level:
X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 BA4gE4a7DFrm for <tls@ietfa.amsl.com>; Wed, 3 Sep 2014 21:39:36 -0700 (PDT)
Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8461A0296 for <tls@ietf.org>; Wed, 3 Sep 2014 21:39:36 -0700 (PDT)
Received: from mail-vc0-f181.google.com ([209.85.220.181]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKVAftCBoah7Sp/gQ1Uvplu8JR9mSTg9Bg@postini.com; Wed, 03 Sep 2014 21:39:36 PDT
Received: by mail-vc0-f181.google.com with SMTP id ij19so10084777vcb.12 for <tls@ietf.org>; Wed, 03 Sep 2014 21:39:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CX7wSBPj1HlRYjeM8gKaS+cA+N90TlrG9S6C24RVrEk=; b=NzgcQoRUNW5rUjpYeNIvA+6SyADCKssPiWCNZfVvle3PIRKizrvlaNXh4Fboi8EA57 nmneeK8BJNt1HMyj2pJn/It2SWI0ICJ43+AsNc+grpudxMSuoFkg3FU0Sq0KWiYDb51O ZuKR8OyYB9lbIpy4DDd/7P2DAijSuhQvSWFWo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=CX7wSBPj1HlRYjeM8gKaS+cA+N90TlrG9S6C24RVrEk=; b=HWCQQPYeU9nqv2ZuJI28vcaeyXgAfqHMhXy24dCp8TLIpp+zj1i8UvSijyE06UL3yU kzUGozvtvTaz8+DVDGalptM6xjt1HHFJeSFxbsqk7tabxoBsCCEheiGra2aUUOOFJ55R GlOqD9hCmetoazaYm3sR1PzhbOQj3ZfcEh6hrjFysYa6/18mbG+sayUoQPCtD8xTXsR9 eUkWpEODmyePfxj7ijrgRVLm6i5+c7HM9ohw0LbuUWgk9SsooLQVlQLFR0HWPjzzg8DA OrGeetNEKd52rywQmYVbcew9/ds+B7vdoy9Xb/5LY2y7pip9u2rlVLW1GO7WRpeDL8e5 YMgA==
X-Gm-Message-State: ALoCoQmor6wEidwQeWl2WgYHufPVeaFMH+W8WnCWOAuQP4ZxEGvTj7C7ddWNEsF2/vi4E00E0G1dYOBAgZVRPxi0WNTYDdyJiKi5B74iG+430rOyCtJBnGCyQPYuYkTTnZgDgLcdZqND
X-Received: by 10.52.249.66 with SMTP id ys2mr1163216vdc.41.1409805575552; Wed, 03 Sep 2014 21:39:35 -0700 (PDT)
X-Received: by 10.52.249.66 with SMTP id ys2mr1163208vdc.41.1409805575435; Wed, 03 Sep 2014 21:39:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.134.70 with HTTP; Wed, 3 Sep 2014 21:39:15 -0700 (PDT)
In-Reply-To: <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> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu>
From: Yutaka OIWA <y.oiwa@aist.go.jp>
Date: Thu, 04 Sep 2014 13:39:15 +0900
Message-ID: <CAMeZVwu1xaAmxUBp5zO1YXCEUSnr=6FiKr8A_WfVUAzLZBb8mA@mail.gmail.com>
To: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DI1NafLl0c0KoOPQHUsmaONgCUA
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: Thu, 04 Sep 2014 04:39:38 -0000
> 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. 2014-09-04 3:46 GMT+09:00 Blumenthal, Uri - 0668 - MITLL <uri@ll.mit.edu>: > 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.) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- 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: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5]
- [TLS] NULL cipher to become a MUST NOT in UTA BCP Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Viktor Dukhovni
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Paul Hoffman
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Salz, Rich
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Viktor Dukhovni
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Viktor Dukhovni
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Viktor Dukhovni
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Paul Lambert
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Bodo Moeller
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Nico Williams
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Nikos Mavrogiannopoulos
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Yutaka OIWA
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Viktor Dukhovni
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Viktor Dukhovni
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Geoffrey Keating
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Nico Williams
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Nico Williams
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Nico Williams
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Yutaka OIWA
- [TLS] uta-tls-bcp-02 thoughts (was: NULL cipher t… Viktor Dukhovni
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Bodo Moeller
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Yutaka OIWA
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Nico Williams
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] uta-tls-bcp-02 thoughts (was: NULL ciph… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] uta-tls-bcp-02 thoughts (was: NULL ciph… Nico Williams
- Re: [TLS] uta-tls-bcp-02 thoughts (was: NULL ciph… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] uta-tls-bcp-02 thoughts Ralph Holz
- Re: [TLS] uta-tls-bcp-02 thoughts Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] uta-tls-bcp-02 thoughts Ralph Holz
- Re: [TLS] uta-tls-bcp-02 thoughts (was: NULL ciph… Barry Leiba
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Bill Frantz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Daniel Kahn Gillmor
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Bodo Moeller
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Manuel Pégourié-Gonnard
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Viktor Dukhovni
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Manuel Pégourié-Gonnard
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ilari Liusvaara
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Nico Williams
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Ralph Holz
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Bodo Moeller
- Re: [TLS] NULL cipher to become a MUST NOT in UTA… Viktor Dukhovni