Re: [TLS] Consensus Call on MTI Algorithms

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 02 April 2015 13:37 UTC

Return-Path: <prvs=15343808f3=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 350CA1A1A2E for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 06:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 lzWKr2MraWWP for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 06:37:05 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6731A1A8F for <tls@ietf.org>; Thu, 2 Apr 2015 06:37:04 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t32DatSU028439; Thu, 2 Apr 2015 09:36:55 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "'yaronf.ietf@gmail.com'" <yaronf.ietf@gmail.com>, "'stephen.farrell@cs.tcd.ie'" <stephen.farrell@cs.tcd.ie>, "'martin.thomson@gmail.com'" <martin.thomson@gmail.com>
Thread-Topic: [TLS] Consensus Call on MTI Algorithms
Thread-Index: AQHQbKdrrgxSnl5sOUuqebcfK2nw3Z049zQAgAAvgQCAAAfCAIAAsbcAgAAQGYCAAAFBAP//yUYP
Date: Thu, 2 Apr 2015 13:36:54 +0000
Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC2711709F@LLE2K10-MBX01.mitll.ad.local>
In-Reply-To: <551D3B94.7070100@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [155.34.14.22]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-02_04:2015-04-02,2015-04-02,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-1504020131
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hBSZfKVsbFUeCtY44XGA6xQthvg>
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] Consensus Call on MTI Algorithms
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, 02 Apr 2015 13:37:08 -0000

You mandated AES-GCM with 128-bit key. Would it be a burden to add 256-bit key support for the algorithm you have to have anyway? 

Why not add AES-GCM-256 as SHOULD? 


--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Thursday, April 02, 2015 08:52 AM
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>ie>; Martin Thomson <martin.thomson@gmail.com>
Cc: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Consensus Call on MTI Algorithms



On 04/02/2015 05:48 AM, Stephen Farrell wrote:
>
>
> On 02/04/15 12:50, Yaron Sheffer wrote:
>>> On 1 April 2015 at 17:46, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>>>> AES-256-GCM and SHA-384. Doesn't it make sense to have them as SHOULD,
>>>
>>> I don't see much point.  All involved likely know if they need
>>> something that strong, which is way down there in the "we might need
>>> it someday" category [1].
>>>
>>> [1] http://www.keylength.com/en/3/
>>>
>>
>> The TLS BCP is IETF consensus, not just one person's opinion. If people
>> deploy stuff based on our recommendations, we should ensure that it is
>> still available to them when they migrate to TLS 1.3.
>
> But isn't it likely we revise the TLS BCP once TLS1.3 is done and
> implementations start to become common? We can make sure things
> all add up at that point in time, and are in-whack with what people
> are deploying, but we don't necessarily need to do so now I think.
>

It entirely likely. But even then, I am not sure we'll be able to 
convince people who went to AES-256 (presumably, for "compliance" 
reasons) to move to ChaCha. And certainly not to AES-128...

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls