IETF Logo Mail Archive

Re: [Cfrg] [secdir] ISE seeks help with some crypto drafts

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Sun, 10 March 2019 22:30 UTC

Return-Path: <prvs=8972f93211=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA9F1277E2; Sun, 10 Mar 2019 15:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 EdZij2-URTX0; Sun, 10 Mar 2019 15:30:24 -0700 (PDT)
Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id 00A0F124408; Sun, 10 Mar 2019 15:30:23 -0700 (PDT)
Received: from LLE2K16-MBX01.mitll.ad.local (LLE2K16-MBX01.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id x2AMUIKD001502; Sun, 10 Mar 2019 18:30:18 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
CC: Tony Arcieri <bascule@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, CFRG <cfrg@irtf.org>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>, secdir <secdir@ietf.org>
Thread-Topic: [Cfrg] [secdir] ISE seeks help with some crypto drafts
Thread-Index: AQHU14QevAW3fcLXj0aQOImPmtGJg6YFqbQAgAAL/QA=
Date: Sun, 10 Mar 2019 22:30:17 +0000
Message-ID: <FF118CAF-AFD2-4EB6-820D-E4B6EBC659C9@ll.mit.edu>
References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <alpine.LRH.2.21.1903081227200.30421@bofh.nohats.ca> <CAHOTMVLtjVxZNy3bFRn09xH+cOw+tPi2CL3BkaQuJEqxAzGOJg@mail.gmail.com> <edca701b-21f3-c80c-d754-fc333f1e2e04@cs.tcd.ie> <20190310182935.GE8182@kduck.mit.edu> <B876B124-7EDE-4E20-A878-3AAD3FA074BC@krovetz.net> <20190310191026.GF8182@kduck.mit.edu> <CAHOTMVJcosEgYV9caWapgyzQfh-g4k5DQry5n42bEfrkJvmdWQ@mail.gmail.com> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie>
In-Reply-To: <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
Content-Type: multipart/signed; boundary="Apple-Mail-F1FD1687-15BF-4297-B98B-9F84CA24E00E"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-10_19:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903100173
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/0P37_CwnZxVlVp7-yeVknx1Kgpo>
Subject: Re: [Cfrg] [secdir] ISE seeks help with some crypto drafts
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Mar 2019 22:30:27 -0000

Stephen,

I think the answer to all of your "interesting questions" is yes, IMHO. 

IMHO, the main reason it did not fly high back then was it's IPR - but that's been addressed for some protocols (e.g., TLS), and is being addressed now for wider IETF adoption.

Regards,
Uri

Sent from my iPhone

> On Mar 10, 2019, at 17:48, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> 
> Hiya,
> 
>> On 10/03/2019 20:57, Tony Arcieri wrote:
>> 
>> I think there are significant compelling reasons to prefer OCB mode 
>> over pretty much all other existing modes:
> 
> FWIW, I don't, because we're not dealing with a clean slate.
> 
> In the IETF context, whether or not OCB is a bit better
> then currently deployed modes is not an interesting
> question.
> 
> One interesting question might be: is OCB so much better
> that it could we displace uses of some existing mode with
> OCB. That seems unlikely to me for the widely used modes.
> 
> Another interesting question might be: is OCB so much
> better that we want to deploy it alongside current modes.
> I don't see the overall benefit of that myself.
> 
> So even though I'm happy to accept that OCB has better
> properties than e.g. GCM, I don't think it's so much
> better that RFCs for it are that useful.
> 
> That said, if the RFC for such a thing said "this is nice
> for brand new stuff (although library support will be less
> comprehensive) but is not worth the costs associated
> with adding it to existing protocols" then I'd be less
> against such RFCs being produced. Understandably enough,
> that kind of statement doesn't get added to such RFCs;-)
> 
> S.
> 
> PS: In case the ISE is still listening, the above is a
> reason why I think having CFRG produce this kind of RFC
> (instead of routing 'em via the ISE) would be a better
> plan. CFRG could (I think) likely reach better informed
> judgements (in the open) as to whether or not some crypto
> technique is really worth documenting in an RFC.
> 
> 
> <0x5AB2FAF17B172BEA.asc>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

v2.23.0 | Report a Bug | By Email