From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [170.10.129.74]) by mx.groups.io with SMTP id smtpd.web12.8361.1651738006687359528 for ; Thu, 05 May 2022 01:06:47 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=jRzp5mDP; spf=pass (domain: redhat.com, ip: 170.10.129.74, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651738005; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sgXW/aUiuFH6WCjohg+0Zo60c2SmWNotQG9E2T/I5No=; b=jRzp5mDPQTxKP1fQfD9t5bUoj4AOoj0TzKQqj53JdKSVtWGK+hA99qnUBOpSTc98mLqYSU JP6BFGqp4VcHaFl8eR6irrIEf9VZToTUMimHoFEZykpQh3Tjl+ReHhkm46/nyTDqaRU2dx r3Prgx7hCPv8CKSDmlVfBBwvVwlR3c4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-619-X4yb62p-MUKBt5IamJqYFw-1; Thu, 05 May 2022 04:06:44 -0400 X-MC-Unique: X4yb62p-MUKBt5IamJqYFw-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D5DB718E530C; Thu, 5 May 2022 08:06:43 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.13]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 73AE6463BD7; Thu, 5 May 2022 08:06:43 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id ACDD418000A9; Thu, 5 May 2022 10:06:38 +0200 (CEST) Date: Thu, 5 May 2022 10:06:38 +0200 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "devel@edk2.groups.io" , Pawel Polawski , "Li, Yi1" , Oliver Steffen , "Wang, Jian J" , Ard Biesheuvel , "Jiang, Guomin" , "Lu, Xiaoyu1" , "Justen, Jordan L" Subject: Re: [PATCH 0/5] CryptoPkg/openssl: enable EC unconditionally. Message-ID: <20220505080638.rmrw3f773rkw3ljl@sirius.home.kraxel.org> References: <20220502103436.3274412-1-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > However, I do have concern for crypto package to enable ECC *unconditionally*. > I am not convinced that "EC is hard requirement for EDKII" just because "EC is a hard requirement for TLS 1.3". My reason below: > A) TLS1.3 is only for DXE, but enabling ECC unconditionally may impact PEI/DXE. (Unless size of PEI/SMM is unchanged). Well, the PcdEcEnabled switch we have in the tree right now enables or disables EC for everybody, it doesn't support enabling EC for DXE only. In we want change that we'll need two different *.inf files I guess, one for openssl with ec and one for openssl without ec. I'll check the effect on image sizes. > C) TLS1.3 is not a mandatory requirement. TLS1.2 can still be used. Yes, today this isn't much of a problem. But I expect that will change in the future as browsers fade out support for older TLS versions to improve security. Recent firefox versions have TLS 1.0 and 1.1 disabled by default. So while this isn't urgent it is still something we should consider and keep on our radar. take care, Gerd