Re: [lamps] Paul Wouters' Discuss on draft-ietf-lamps-caa-issuemail-06: (with DISCUSS)

[Paul Wouters <[e-mail]>]

Corey,

Thanks for answering my DISCUSS questions. I've updated my ballot to Yes.

Paul


On Wed, Aug 9, 2023 at 9:07 AM Corey Bonnell <[e-mail]>
wrote:

> Hi Paul,
> Thank you for your review and your comments. Replies inline.
>
> > is it the desired behaviour that toronto.nohats.ca can override the
> > nohats.ca
> policy and issues certs for [e-mail]?  This also brings into
> question whether Public Suffix List (PSL) type restrains matter.
>
> My understanding is that this behavior is intended and desired based on
> the
> discussions surrounding the tree-climbing algorithm as defined in RFC 6844
> and
> later amended in 8659. Phillip provides an excellent description of this
> design choice here [1]. Additionally, the use of Public Delegation
> Points/PSL
> was removed in later drafts of RFC 6844 [2] and replaced with a simpler
> algorithm that merely walks up each label to the DNS root.
>
> > Section 5.4 contains an example of conflicting records, and the text then
> describes a process of "failing open". From a security point of view, I
> would argue this should "fail close" and not allow issuance. Was this
> discussed
> in the WG? What is the rationale behind this "more vulnerable to mistakes"
> interpretation?
>
> I don't believe this specific point was discussed in the context of this
> draft, but this behavior is the same as defined in RFC 6844. I believe
> this is
> a feature and not a bug, as the "failing closed" behavior in the face of
> conflicting records would prevent domains from using multiple CA providers.
>
> Thanks,
> Corey
>
> [1]
> https://mailarchive.ietf.org/arch/msg/pkix/CvkHdFP6gdXRCTmq5TXjvMlGOV0/
> [2]
> https://mailarchive.ietf.org/arch/msg/pkix/87NqhuFaKCVQO--8pSD3NhjQd2U/
>
>
> -----Original Message-----
> From: Paul Wouters via Datatracker <[e-mail]>
> Sent: Tuesday, August 8, 2023 9:34 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Paul Wouters' Discuss on draft-ietf-lamps-caa-issuemail-06: (with
> DISCUSS)
>
> Paul Wouters has entered the following ballot position for
> draft-ietf-lamps-caa-issuemail-06: Discuss
>
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this
> introductory
> paragraph, however.)
>
>
> Please refer to
>
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-caa-issuemail/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> Issue #1
>
>         The discovery of such a Relevant RRSet MUST be performed using the
>         algorithm specified in section 3 of [RFC8659]. The input domain to
> the
>         discovery algorithm SHALL be the domain "part" ([RFC5322]) of the
> email
>         address that is being certified.
>
> And RFC 8659 states:
>
>         The search for a CAA RRset climbs the DNS name tree from the
>         specified label up to, but not including, the DNS root "." until
>         a CAA RRset is found.
>
>
> While this algorithm makes sense for a CAA to restrict issuing, I'm not
> sure
> it
> makes sense for email addresses where the permission might be granted by a
> parent.
>
> eg ig there is a CAA record saying "no email certs" at nohats.ca,
> and there is a CAA record saying "sure, issue stuff" at toronto.nohats.ca,
>
> is it the desired behaviour that toronto.nohats.ca can override the
> nohats.ca
> policy and issues certs for [e-mail]?  This also brings into
> question whether Public Suffix List (PSL) type restrains matter.
>
> It might very well be the intent, but then perhaps it should be made a
> little
> more
> explicit ? (and then I have to rethink about what I think about subdomains
> overriding
> their parents)
>
>
> Issue #2:
>
> Section 5.4 contains an example of conflicting records, and the text then
> describes a process of "failing open". From a security point of view, I
> would argue this should "fail close" and not allow issuance. Was this
> discussed
> in the WG? What is the rationale behind this "more vulnerable to mistakes"
> interpretation?
>
>
>
>
>
>