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

[Corey Bonnell <[e-mail]>]

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?