Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01

"Kampanakis, Panos" <kpanos@amazon.com> Fri, 23 September 2022 13:30 UTC

Return-Path: <prvs=2581099e8=kpanos@amazon.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79ABC1522AB for <spasm@ietfa.amsl.com>; Fri, 23 Sep 2022 06:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.478
X-Spam-Level:
X-Spam-Status: No, score=-12.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVEOQATFKOEH for <spasm@ietfa.amsl.com>; Fri, 23 Sep 2022 06:30:30 -0700 (PDT)
Received: from smtp-fw-9103.amazon.com (smtp-fw-9103.amazon.com [207.171.188.200]) (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 06AF4C1524C6 for <spasm@ietf.org>; Fri, 23 Sep 2022 06:30:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1663939830; x=1695475830; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=4guBXo1NiJMfyeuuvZ3FoBopKUrv89MWZQA0wqNABcg=; b=MgtULGdv8nDuUBFarJGpDz2gfydBZ+Ns4OYv//K6XOtRYCjN/77AUw0s 8Hfip9P/NoiZTkoj78Xut/QdbOfLdBla27BNtkfTpGLyeEdwv1WHzGzUH dPArceOCnpGzPNvzghethY/FQ9KoGC/K3CimIQ5l4RDWT6oGZoc3D7DCj U=;
X-IronPort-AV: E=Sophos;i="5.93,339,1654560000"; d="scan'208,217";a="1057412273"
Thread-Topic: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01
Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-iad-1e-41c1ef8b.us-east-1.amazon.com) ([10.25.36.214]) by smtp-border-fw-9103.sea19.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 13:29:51 +0000
Received: from EX13MTAUWB001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-iad-1e-41c1ef8b.us-east-1.amazon.com (Postfix) with ESMTPS id 8E20D1602A5; Fri, 23 Sep 2022 13:29:49 +0000 (UTC)
Received: from EX19D001ANA001.ant.amazon.com (10.37.240.156) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.38; Fri, 23 Sep 2022 13:29:43 +0000
Received: from EX19D001ANA001.ant.amazon.com (10.37.240.156) by EX19D001ANA001.ant.amazon.com (10.37.240.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1118.12; Fri, 23 Sep 2022 13:29:42 +0000
Received: from EX19D001ANA001.ant.amazon.com ([fe80::6054:a5f0:5f79:c120]) by EX19D001ANA001.ant.amazon.com ([fe80::6054:a5f0:5f79:c120%5]) with mapi id 15.02.1118.012; Fri, 23 Sep 2022 13:29:42 +0000
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: Michael Jenkins <m.jenkins.364706@gmail.com>
CC: Russ Housley <housley@vigilsec.com>, LAMPS <spasm@ietf.org>
Thread-Index: AQHYzsExBGQUwZWuNkKXQOFSh1GJUa3sN1vA
Date: Fri, 23 Sep 2022 13:29:42 +0000
Message-ID: <5a867dc9b7f64a94aba3d96f0d1f7e4d@amazon.com>
References: <PH0PR00MB10003EC6A096FE0A363BBFB9F5459@PH0PR00MB1000.namprd00.prod.outlook.com> <PH0PR00MB10002A7A2850A1333B4F6C00F54A9@PH0PR00MB1000.namprd00.prod.outlook.com> <35BEB1D9-7EA5-4CD4-BADA-88CCB0E9E8F9@vigilsec.com> <2b711f2ede13466490ce79f822244f5a@amazon.com> <CAC2=hndPr_z7_hn8q7XxH85pfjiOvB3rh9kTq9V5sT=nfvwRDw@mail.gmail.com>
In-Reply-To: <CAC2=hndPr_z7_hn8q7XxH85pfjiOvB3rh9kTq9V5sT=nfvwRDw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.179.17]
Content-Type: multipart/alternative; boundary="_000_5a867dc9b7f64a94aba3d96f0d1f7e4damazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/C60eX5E-uXpEw4hoBG4YylhgIsc>
Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2022 13:30:32 -0000

Hi Mike,

Let me be more specific:
- The issuer now has to go fetch a related cert in order to issue a new one. There is no such concept in issuers today.
- Should the issuer now check and verify SCTs in the related certificate (if it is WebPKI) to confirm it was issued legally and exists in CT? There is no such concept in issuers today.
- Should the issuer now go verify revocation status of the related cert?  There is no such concept in issuers today.
- What if the related cert was issued by a different CA? Does the new issuer just trust the domain or EV validation the other CA performed? If these two identities are supposed to be used together, then it probably needs to. I am  not sure how comfortable CA1 would be about CA2’s DV or EV validation.
- What if the related cert was revoked at some point? How would a different issuer that issued a related cert get notified about that revocation in order to revoke that too?
- How about time overlap of these certs? If I issue related certs that have just 2 months overlap, as an issuer how do I charge the customer that is asking for 1 year certs? Now I have to make a choice to deny some of the certs if there is not enough overlap which is something I do not control.
- How about outages? We have seen plenty of outages with renewing certs on their own. Now that we have overlapping times of two differently issued certs, how many more outages will we see because the time overlap is short? Operationally, now we need to track two related certs in order to make sure they get renewed properly with adequate overlap to avoid outages.
- Should the issuer make sure the subject-name and SANs in the related cert match exactly the subject-name and SANs in the requested cert? I could argue for and against it.
- The Enterprise RA may certainly perform some checks, but the issuer is responsible for tying certs together with the extension. Maybe in an Enterprise Private PKI the CA will not mind issuing for any CSR  coming from the RA with the cmcRA bit set, but  I am not sure how generally comfortable all CAs would be just putting in the related cert extension just because it went through an RA.

I do not consider the above straightforward or to align with how PKI Ops work today.

A couple more challenges brought up in previous threads
- We now need a global cert directory in order to uniquely identify fetched certs. Who is going to offer that?
- the related cert signature could be copied unless the signed content proposed in the draft currently changes.

> In terms of impact to protocols - yes, it would have impact to protocols, we submitted a (now expired) draft to explain how protocols would be impacted. Largely that's doing things twice.

Yes, I had read it. Sure, we could update (D)TLS, QUIC, IKEv2, SSH, EAP (or any other protocol using X.509 for authentication) to negotiate and send two cert chains and two signatures. As a verifier I now need to verify two identities and ensure they are identical and properly related in all protocols I use certs for authentication. It just seems lots of work for a temporary transition-to-PQ mechanism.

> Nothing in the related certs draft inhibits the use of composite keys and certs. I don't see these approaches as mutually exclusive.

They certainly address the same issue. I feel standardizing and implementing multiple ways of doing the same thing adds unnecessary complexity to standards and implementations.

Personally, I consider changing CA/RA’s operations and all deployed protocols significantly much more complicated than swapping in an algorithm twice (assuming you do not trust Dilithium, Falcon, SPHINCS+ yet) .

Is it the cert cost that you consider prohibitive with composites, or the complexity?



From: Spasm <spasm-bounces@ietf.org> On Behalf Of Michael Jenkins
Sent: Thursday, September 22, 2022 4:22 PM
To: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org>
Cc: Russ Housley <housley@vigilsec.com>; LAMPS <spasm@ietf.org>
Subject: RE: [EXTERNAL][lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


Panos,

I don't know which peers you talked to, but several of these concerns are either unfounded or overstated. It might have been helpful to talk to us.

CAs don't need to completely change their paradigm. CAs don't have to offer the extension at all if they don't see a need or benefit. If they do, the extension is requested through an CSR attribute, attested by an RA. This is not at all out of the realm of PKI procedure (especially enterprise PKI procedure, where this is likely to find value). A certificate with the related certs attribute will work perfectly well whether the recipient cares about it or not.

The latest draft drops the term "bound". The certificates, and by extension keys, are "related". The indicator of relation is to the Relying Party - in all cases, it is up to the RP to determine whether it cares, and if it does, what to make of it. This is as it should be for authentication.

In terms of impact to protocols - yes, it would have impact to protocols, we submitted a (now expired) draft to explain how protocols would be impacted. Largely that's doing things twice. None of it needs to be "bound". All of it would be negotiated in-protocol, to the satisfaction of the parties involved.

Nothing in the related certs draft inhibits the use of composite keys and certs. I don't see these approaches as mutually exclusive.

If you have remaining concerns, we'd be happy to talk to you about them or to continue on-list.

Mike Jenkins
NSA-CCSS

On Thu, Sep 22, 2022 at 3:54 PM Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org<mailto:40amazon.com@dmarc.ietf.org>> wrote:
After giving it more thought and chatting with peers, I am against adopting this draft.

It has huge implications to CAs because they would completely need to change their paradigm and check existing certs before issuing a new one bound to the existing one. That has great impact to the PKI ecosystem and how certs are issued, how keys are bound together, what happens if one gets revoked etc. Some of these issues may be solvable, but admittedly this is a lot of complexity we have not dealt with before.

Additionally, it has great implications to existing protocols using X.509 for authentication. They would require major changes to introduce double signatures, send over two chains, confirm the signatures are from bound public keys etc.

I understand that the authors' goal was to prevent two PKI migrations, one to PQ-hybrid and one to pure PQ but in my opinion the complexity is not worth it. Folks that are worried about authentication and want PQ support now could use composite in the near-term. Folks that either trust Dilithium, Falcon, or SPHINCS+ already or can wait a few years until they trust them, can just go to pure PQ signatures. These seem better options than going for a brand new complicated paradigm with bound certificates.

Rgs,
Panos



-----Original Message-----
From: Spasm <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org>> On Behalf Of Russ Housley
Sent: Thursday, September 15, 2022 11:45 AM
To: LAMPS <spasm@ietf.org<mailto:spasm@ietf.org>>
Subject: [EXTERNAL] [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-01

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



There has been some discussion of https://datatracker.ietf.org/doc/draft-becker-guthrie-cert-binding-for-multi-auth/.  During the discussion at IETF 114, we agree to have a call for adoption of this document.

Should the LAMPS WG adopt “Related Certificates for Use in Multiple Authentications within a Protocol” indraft-becker-guthrie-cert-binding-for-multi-auth-01?

Please reply to this message by Friday, 30 September 2022 to voice your support or opposition to adoption.

On behalf of the LAMPS WG Chairs,
Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org<mailto:Spasm@ietf.org>
https://www.ietf.org/mailman/listinfo/spasm
_______________________________________________
Spasm mailing list
Spasm@ietf.org<mailto:Spasm@ietf.org>
https://www.ietf.org/mailman/listinfo/spasm


--
Mike Jenkins
mjjenki@cyber.nsa.gov<mailto:mjjenki@tycho.ncsc.mil>
443-598-7837