Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 12 February 2020 22:57 UTC

Return-Path: <prvs=93118b9c8e=uri@ll.mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A35120026 for <tls@ietfa.amsl.com>; Wed, 12 Feb 2020 14:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 gSmhiA7YLW_c for <tls@ietfa.amsl.com>; Wed, 12 Feb 2020 14:57:14 -0800 (PST)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75B7120013 for <tls@ietf.org>; Wed, 12 Feb 2020 14:57:13 -0800 (PST)
Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 01CMv8dT031131; Wed, 12 Feb 2020 17:57:08 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Martin Thomson <mt@lowentropy.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design
Thread-Index: AQHV4fbKdYkW0pRwtUOF1RalA0aXZ6gYK5KA
Date: Wed, 12 Feb 2020 22:57:07 +0000
Message-ID: <F4D9DA29-D029-4BE2-80BC-BE3777F0142E@ll.mit.edu>
References: <CAFBh+SRAJAbviyrcQM2PjztumAH565i4-ui28OQ-pCJE9nePJg@mail.gmail.com> <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <CDADA8F3-65EA-4002-B7B7-7F3798BB331B@ll.mit.edu> <540a1632-5e0e-4aac-b9d0-8fac6b8f06be@www.fastmail.com> <00015213-5a87-7275-67b1-aade6cc5ed8c@cs.tcd.ie>
In-Reply-To: <00015213-5a87-7275-67b1-aade6cc5ed8c@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
x-originating-ip: [172.25.1.90]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3664375027_1635549460"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-12_10:, , 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-1911140001 definitions=main-2002120158
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Qa46VTIslqcY9jIJFdmzahoAOdA>
Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Feb 2020 22:57:16 -0000

I don't expect you to be knowledgeable about 25+ proposed algorithms.

I expect you to be knowledgeable about the ballpark of the new key sizes that practically all of the candidates use. The shortest keys are in the ballpark of a few KB, and I won't go into the size of the largest ones.

You may not want to *adopt* them now - but you better be ready to support Key Exchange for sizes far larger than what's currently implemented. And keep in mind that while Signatures aren't a priority yet, that will come eventually.



´╗┐On 2/12/20, 5:50 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>; wrote:
  
    Hiya,
    
    On 12/02/2020 21:57, Martin Thomson wrote:
    > Only a few of them.  Some are OK, but the number is few, I agree.  I
    > haven't found a good summary of the second round candidates and I
    > don't have time to dig into all of the candidates.

    Fine reason to wait and see IMO.
    
    I'd be much happier adopting this if we did that with
    the explicit understanding that we won't produce an
    RFC until the "winners" in the NIST process are known
    and their properties understood. (I don't mean waiting
    for a FIPS or formal NIST document but at least for
    the final announcement from their process.)
    
    If the plan were to adopt this and produce an RFC now
    (e.g. to mix different curves or something) then I am
    against that. There's no need for such combinations so
    the real rationale here is PQC and we (at least I, but
    I suspect also many IETF participants) don't know enough
    about the relevant algorithms yet. (And expecting us
    to be knowledgeable about 25+ algorithms isn't realistic.)
    
    Cheers,
    S.