Re: [Add] Fwd: New Version Notification for draft-reddy-add-delegated-credentials-00.txt

On Wed, 5 Apr 2023 at 09:55, Martin Thomson <mt@lowentropy.net> wrote:

> Having spoken to Tiru in Yokohama, I might have a better understanding of
> the problem statement.
>
> The problem, as I understand it, is exactly what Eric is talking about:
> the challenges with ensuring that CPE has a current certificate, or can at
> least answer requests for a public name.  Short-lived certificates have a
> bunch of challenges that are hard enough for well-connected services to
> manage.  These are only exacerbated when you have far less robust
> connectivity.
>

Eric and you have understood the problem correctly.

>
> The use of delegated credentials (DC) here only really helps if you don't
> need to generate new certificates.

Yes, delegated credentials can be used by the CPE to host an encrypted DNS
forwarder but without having to get a certificate from a public CA.

> There are no provisions in DC for constraining the scope of the
> delegation, so - if the concern is that the CPE might be renamed so that it
> needs a new cert - you are still stuck while someone goes to fetch that
> certificate, even if that is being done by a well-connected server.  And it
> is not, because the CPE still needs a copy of the certificate.  If the CPE
> is renamed, a new certificate still needs to be acquired.  Note also that
> the manufacturer can't delegate from a wildcard certificate, or CPE could
> just impersonate each other.
>

If delegated credentials are used, each CPE need not be assigned a unique
FQDN. The delegated credential would be cryptographically bound to the PKI
EE certificate with KeyPurposeId set to id-kp-serverAuth to identify that
the certificate is for a server.

>
> The idea that you might rely on the manufacturer to serve as a remote
> signing oracle works, but it has the major drawback that the CPE needs to
> be online to function.  That makes it a bit of non-starter, though because
> you aren't handing out delegated credentials, a wildcard certificate might
> work as a way of managing name churn.  So, this likely only works as a sort
> of fallback to some more robust system, like to cover for certificate
> issuance delays or other gaps.  This is a pretty complex setup though, so
> I'd probably not recommend it in any case.  Better to find a robust design.
>
> The idea that I floated with Tiru was that the CPE manufacturer sign on
> with a CA to get a name-constrained delegation.  Then, instead of sending
> them a constant stream of requests, they are responsible for managing the
> allocation of certificates to CPE (using ACME I would hope).  These could
> be relatively long-lived then, up to what is allowed by policies of the CA
> and manufacturer, with all that entails.
>

Thanks for suggesting the alternative. I think you are referring to using name
constraints extension
https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10. In this use case,
the service managing the CPEs could get a CA certificate with name
constraints extension and the service would in-turn act as an ACME server
to provision end-entity certificates on CPEs. I see we have to select among
three mechanisms (a) name constraints extension (b) delegated credentials
(c) star certificates defined in ACME WG. Name constraints extension seems
to be not supported by all CAs but requires no changes to TLS
client/server. Delegated credentials does not require support from CA (but
requires update to TLS client/server). Star certificates require support by
CAs but require no changes to TLS client/server.

>
> In part, the problem here is down to name selection choices.  If names are
> based on IP or anything else that is ephemeral, that means that they aren't
> stable and so they can be more exposed to a need for reissuance.  Whereas
> if they are essentially fixed, then lifetimes can be longer.
>
> p.s., We should not be putting private information in these names, as the
> draft suggests.  Even if we don't expect them to leak onto public networks,
> nothing treats names as a secret, so using account or device serial numbers
> seems unwise to me.  Yes, manufacturers that assign identifiers need to
> manage uniqueness, but they could at least hide the inputs (with a PRP,
> say).
>

Agreed, we will update the draft to say that the name must not use any PII
or device identification details.

Cheers,
-Tiru

>
> On Wed, Apr 5, 2023, at 13:07, Eric Rescorla wrote:
> > I'm finding this draft kind of hard to read, but as I understand it,
> > the problem you are trying to solve is that it's difficult for the
> > vendor to provision individual certificates to each CPE device, right?
> >
> > This document doesn't describe the proposed configuration in as much
> > detail as I would like, but it seems like the plan is to have a single
> > certificate for example.com and then issue each CPE a distinct
> delegated
> > credential but signed by the same key/cert. Is that correct?
> >
> >
> >
> >
> >
> >
> > On Sun, Mar 26, 2023 at 6:50 PM tirumal reddy <kondtir@gmail.com> wrote:
> >> The new draft
> https://datatracker.ietf.org/doc/html/draft-reddy-add-delegated-credentials
> discusses the use of TLS delegated credentials for a DNS server deployed on
> a CPE. This approach is meant to ease operating DNS forwarders in CPEs
> while allowing to make use of encrypted DNS capabilities.
> >>
> >> Comments and suggestions are welcome.
> >>
> >> We plan to present the draft in the ADD meeting slot.
> >>
> >> - Dan, Tiru, Mohamed and Shashank
> >>
> >> ---------- Forwarded message ---------
> >> From: <internet-drafts@ietf.org>
> >> Date: Mon, 27 Mar 2023 at 06:25
> >> Subject: New Version Notification for
> draft-reddy-add-delegated-credentials-00.txt
> >> To: Tirumaleswar Reddy.K <kondtir@gmail.com>, Dan Wing <
> dwing-ietf@fuggles.com>, Mohamed Boucadair <mohamed.boucadair@orange.com>,
> Shashank Jain <Shashank_Jain@mcafee.com>, Shashank Jain <
> shashank_jain@mcafee.com>
> >>
> >>
> >>
> >> A new version of I-D, draft-reddy-add-delegated-credentials-00.txt
> >> has been successfully submitted by Tirumaleswar Reddy and posted to the
> >> IETF repository.
> >>
> >> Name:           draft-reddy-add-delegated-credentials
> >> Revision:       00
> >> Title:          Delegated Credentials to Host Encrypted DNS Forwarders
> on CPEs
> >> Document date:  2023-03-26
> >> Group:          Individual Submission
> >> Pages:          12
> >> URL:
> https://www.ietf.org/archive/id/draft-reddy-add-delegated-credentials-00.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-reddy-add-delegated-credentials/
> >> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reddy-add-delegated-credentials
> >>
> >>
> >> Abstract:
> >>    An encrypted DNS server is authenticated by a certificate signed by a
> >>    Certificate Authority (CA).  However, for typical encrypted DNS
> >>    server deployments on Customer Premise Equipment (CPEs), the
> >>    signature cannot be obtained or requires excessive interactions with
> >>    a Certificate Authority.
> >>
> >>    This document explores the use of TLS delegated credentials for a DNS
> >>    server deployed on a CPE.  This approach is meant to ease operating
> >>    DNS forwarders in CPEs while allowing to make use of encrypted DNS
> >>    capabilities.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >>
> >> --
> >> Add mailing list
> >> Add@ietf.org
> >> https://www.ietf.org/mailman/listinfo/add
> > --
> > Add mailing list
> > Add@ietf.org
> > https://www.ietf.org/mailman/listinfo/add
>