Re: [Acme] draft-ietf-acme-subdomains and public suffixes

[Ryan Sleevi]

On Mon, May 16, 2022 at 7:47 AM Peter Thomassen  wrote:

> FWIW, the notion is already codified in RFC 7489 (Section 3.2) and RFC
> 9091 (in the title, albeit experimental).


Yes, doubly unfortunate, as the DBOUND WG can attest ;)

Sure. However, if the relevant part of the DNS space is, at the time of
> certificate issuance, separated into different realms of authority (e.g.,
> as indicated by a PSL entry),


NB: the PSL does not indicate this separation of authority. This is an
example of the problem DBOUND was tackling, in which different use cases
and needs were projected onto the PSL, but not necessarily what the PSL
reflected.

> The requirement of public suffix separation is _primarily_ a holdover
> from when every validation method was treated equally by CAs (e.g. the use
> of HTTP to approve a wildcard domain, without demonstrating DNS-based
> control). With the new separations that restrict such broadening,
>
> Which?


The Baseline Requirements, and the limits on what methods are suitable to
authorize an Authorization Domain Name and Wildcard. The methods, and their
limitations, are discussed in 3.2.2.4

However, this is all policy, and arguably out of scope here. Even the PSL
reflects a policy-based approach, due to the many versions of such lists,
either chronological from a single source or, quite commonly, local policy
based modifications and adjustments. So there’s no value to be derived in
referencing, if only because it’s an unstable and subjective base to begin
with.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] draft-ietf-acme-subdomains and public suffixes

[Ryan Sleevi]

On Thu, Apr 7, 2022 at 10:36 AM Peter Thomassen  wrote:

> Now, should it be possible for the DNS admin of eu.org to request a
> certificate for example.de.eu.org (or subdomains thereof) through the
> mechanism described in the draft, although there is a public suffix in
> between? (I don't think so.)
>
> If this should be prevented, the corresponding public suffix check needs
> to be mandatory. (However, I'm not sure if it needs to be in this draft, or
> in the CA/B guidelines.)


Given that public suffices are an unfortunate fiction invented by browsers,
it'd be doubly unfortunate to codify it in an IETF doc.

That said, it is already an existing requirement of the CA/Browser Forum
Baseline Requirements (for TLS; no comments made re: S/MIME), such that the
authorization domain name (aka the prefix) used to verify a domain requires
termination of tree climbing upon encountering the first public suffix.

So, in practice, a CA using this spec and conforming to the CA/Browser
Forum BRs will refuse to issue such a certificate.

However, this is a convenient fiction in separation: the DNS admin of eu.org
can, at any time, remove de.eu.org from the public suffix list, as they are
the parent authority. In that sense, they have the full technical
capability to cause issuance.

The requirement of public suffix separation is _primarily_ a holdover from
when every validation method was treated equally by CAs (e.g. the use of
HTTP to approve a wildcard domain, without demonstrating DNS-based
control). With the new separations that restrict such broadening, it is
conceivable to imagine that the requirement to "stop" at the public suffix
is removed from the Baseline Requirements, in recognition that the parent
domain fundamentally has more power than the child labels.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Extending (A)RI to non-ACME use cases

[Ryan Sleevi]

On Fri, Feb 18, 2022 at 12:51 PM Rob Stradling  wrote:

> draft-aaron-acme-ari-01 describes an "extension to ACME", but ISTM that
> the core, OCSP-inspired protocol is not specific to ACME at all.  I
> appreciate that the document author's employer and this WG are only
> directly concerned with the ACME use case; however, ISTM that providing
> "renewal information" is something that non-ACME CAs also care about, so
> I'd like to explore how we could extend this capability to also support
> their use cases.
>
> A non-ACME CA would need an alternative mechanism for advertising ARI
> support, since it won't have an ACME directory object to which a
> "renewalInfo" resource can be added.  Continuing the "OCSP-inspired"
> theme, I propose defining a new "access descriptor" for use in the
> Authority Information Access certificate extension, so that CAs can
> (optionally) embed a renewalInfo URL into a well-known field in each
> certificate they issue.  The obvious name for this access descriptor would
> be "id-ad-renewalInfo".
>
> The JSON response format obviously makes sense for ACME, but might not be
> optimal for non-ACME use cases that wouldn't otherwise use JSON.  Perhaps
> the "start" and "end" timestamps could be replicated to HTTP response
> headers, so that the suggested window can be read by a non-ACME client
> without having to parse the JSON?
>
> I wonder if WG scope considerations would mean that the logical outcome of
> adopting my proposal would be that the document would need to be split in
> two: (1) Core "renewal info" specification, handled by LAMPS; and (2) ACME
> renewalInfo resource specification, handled here in ACME.
>
> One last thought: Both non-ACME and ACME use cases could use the proposed
> core "renewal info" protocol, meaning that the ACME renewalInfo resource
> could arguably become surplus to requirements.
>
> Comments?
>

Selfishly, I would rather see such CAs using no -ACME solutions engage more
with ACME to see about addressing those needs.

Pragmatically, I dislike the proposed path, because the renewalInfo isn’t
information relevant to a relying party, but rather, the certificate
subscriber. I think it’s reasonable to ask “Is this information critical to
any/all of the protocols using certificates, such as IPSec, TLS, and
S/MIME?” And the answer is resoundingly, and unambiguously, no.

I don’t disagree the value in perhaps having a formalized protocol, such
where information normally conveyed in-band within an ACME exchange (such
as via renewalInfo) can, for those CAs that predominantly use bespoke
protocols or out of band exchanges, can also be communicated out of band. I
just disagree with using the certificate as the appropriate means of
conveying that information.

It’s easy to get further into suggestions about the transport semantics
(legacy headers versus JSON vs structured headers, for example), but I
think before going down that route, it would be more useful to crispy
define why ACME would not be an appropriate path for those CAs, why it can
never be a path, and only then evaluate whether it’s worth the complexity
to have ARI support those use cases.

Personally, I would prefer a simpler protocol for ACME, but I admit, I may
be overlooking compelling reasons that justify the added complexity of
decoupling.

>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] working group call for adoption

[Ryan Sleevi]

On Wed, Sep 1, 2021 at 8:28 PM Michael Richardson 
wrote:

>
> Ryan Sleevi  wrote:
> >> This seems to make the ACME server keep a bunch of state itself
> (across
> >> multiple HTTPS/TLS connections), while I suspect that most of us
> would like
> >> the client to be responsible for keeping that authorization around.
> >>
> >> Would you agree with this?
>
>
> > I'm not sure I understand this. Isn't it already the case today that
> ACME
> > servers necessarily need to track this state?
>
> Yes, but not necessarily across TLS connections.
>
> One connects, gets a challenge, sets it up (DNS or HTTP/S), waits for the
> authorization check to complete, and sends an order.


As Aaron mentioned, I'm not only not aware of implementations that do what
you describe, but I also don't believe this was a design goal/constraint of
ACME to support. Indeed, it explicitly runs counter to the use cases that
were intended to be supported with the design (e.g. external accounts or
additional vetting).

Are you aware of implementations - clients or servers - that behave as you
describe? It would be interesting to learn more about them, and what sort
of use cases they exist to support, since it doesn't seem to fit with the
primary use cases ACME was designed to address.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] working group call for adoption

[Ryan Sleevi]

On Wed, Sep 1, 2021 at 7:45 PM Michael Richardson 
wrote:

> This seems to make the ACME server keep a bunch of state itself (across
> multiple HTTPS/TLS connections), while I suspect that most of us would like
> the client to be responsible for keeping that authorization around.
>
> Would you agree with this?


I'm not sure I understand this. Isn't it already the case today that ACME
servers necessarily need to track this state?

It's unclear if you're talking about an abstract goal, which the current
specifications may not achieve, certainly not in terms of those widely
deployed, or if you believe there's a concrete deployment today that is
able to achieve this "stateless" design, that the wildcard work would be
applicable to, and which would be unduly burdened by this. Certainly, for
some of the other use cases (e.g. OV and EV using ACME), this is
unquestionably true that state is managed on the server.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04

[Ryan Sleevi]

On Sat, Aug 14, 2021 at 6:18 PM Brian Sipos  wrote:

> Does it seems like it's at all reasonable, from the perspective of the
> security area and focus on PKIX (documents and tools), for an application
> profile like this to say to conform to "... RFC 5280 with the exception of
> the FQDN/IP-address restriction on URI authority part". It's not exactly an
> update to RFC 5280 but I don't know how valid or typical it is for one RFC
> to relax requirements from a normative reference.
>

I think that would be specifically ill-advised, and most likely harm
interoperability. The reality is implementations by and large don't offer
the flexibility being described here, and would see it as a security issue
to do so (given how constraints work with URIs), so the net effect is to
encourage implementers of this spec to "fork" RFC 5280, and, by nature,
fork the libraries or implementations due to a respectable unwillingness of
upstream to accept such relaxations.

So no, it's atypical, and not at all recommended.

Given that URI SANs / nameConstraints are already a security and
interoperability disaster [1] [2], avoiding building on them is absolutely
the way to go, even if the URI itself was conforming.

[1]
https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf
[2] https://datatracker.ietf.org/doc/html/draft-ruby-url-problem-01


> On the other hand, I see no reason why a new otherName OID allocation
> under the "SMI Security for PKIX Other Name Forms" IANA sub-registry [2]
> could not be used with the same value (a Node ID URI) and value encoding
> (IA5String). The PKIX profile for DTN is new and I doubt it has much
> deployment yet within DTNs. But now's the time to settle this out; the
> TCPCLv4 doc defining the profile is still in the RFC editor's queue.
>

Yes. This is a 'happy path' that supports interop with a number of existing
libraries and tools.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04

[Ryan Sleevi]

On Fri, Aug 13, 2021 at 4:04 PM Roman Danyliw  wrote:

> I think the current options might be:
>
> (1) Roughly what you said above + Make it clear that this document is NOT
> using the RFC5280 profile and simply reusing the data structures (but not
> the validation logic).  Related to this, and excuse my ignorance about DTN,
> would it be possible to constrain these non-RFC5280-conforming certificates
> from appear on the internet with some normative phrasing.  Technically,
> RFC5280 is the _Internet_ PKIX profile.  This document goes to great pains
> to separate the internet portion of the ACME protocol exchange and the
> validation happening over DTN (which might be considered a "limited domain"
> as framed by RFC8799).
>
> (2) Revise RFC5280.  I'm loath to pursue this path unless we really need
> to.
>

I suspect that either of these options would be a quick way to doom
interoperability. That is, for better or worse, RFC 5280 is _the_ profile
of X.509 that is commonly targeted by libraries and implementations.
Attempting to diverge here, or special-case exceptions, generally means
that implementing an interoperable and spec-compliant implementation are
increasingly unlikely, given the extant complexity inherent in X.509 and
RFC 5280 to begin with (e.g. as so many implementations overlook RFC 4158
to their own peril - and to the harm of interop)

To that end, is

(3) Express the DTN ID as an otherName within the SAN, rather than a
(non-conforming) URI

Not an option? The downside here is the obvious loss of nameConstraints
processing (RFC 5280 does not define even a processing algorithm for
otherName nameConstraints, which makes sense, given the complexities there
vis-a-vis multiple distinct otherNames vs multiple otherNames that make up
a single logical name), but if that's an acceptable trade-off, that likely
represents the most interoperable path forward.

That's not to say otherName is readily supported "out of the box", although
it is in some (e.g. most famously, Active Directory's use of the otherName
for the userPrincipalName), but it fits within the "no special cases" goal
of promoting interoperability, and lets one build/extend existing RFC 5280
implementations. Here, the lack of nameConstraints processing is a benefit,
rather than a limitation - it makes processing and extracting such fields
something relatively simple you can build on post-validation, if your
library is not extensible or not receptive towards exposing library-level
API support specific for DTN node IDs.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WGLC for ACME DTN Node ID

[Ryan Sleevi]

With admittedly very little context for this specific use case, a few
things stand out:

Section 2 states "Any identifier of type "uri" in a newOrder request MUST
NOT have a wildcard ("*") character in its value." This seems to
unnecessarily constrain the character space. While I suspect the purpose
was to exclude wildcards from the authority-part of a generic URI/specific
to a particular scheme, it ends up defining the semantics for all URIs.
Given URI's well-known ambiguity in representation across implementations,
and the ability to do things like include pct-encoded characters in
reg-name (it's only a must requirement, not a MUST requirement), this both
seems unnecessarily restrictive and fails to achieve the goal, especially
since such decoding to prevent this scenario, at the ACME server, is SHALL
NOT'd by the same section.

If the goal is to prevent wildcards that imply certain semantics for a
given scheme (e.g. "dtn:"), then that probably deserves a separate section
detailing the requirements for the extraction and validation of the Node ID
from the URI, and can define any restrictions on the character namespace.

Alternatively, since identifier labels are cheap, making the identifier
type a dtn-uri (rather than the acknowledge-generic URI) seems like a way
to impose requirements specific to DTN URIs without risk of overfitting for
other types of URIs.

Section 3 describes how this cribs from ietf-acme-email-smime, but provides
no clear explanation as to the _why_, only the _how_. For example, the
statement "requires that the ACME client have access to the results of each
channel to get both parts of the token" describes a result, but does not
describe the motivation that necessitates such a design. This seems like it
might be relevant for security considerations, but documenting the
rationale for this design seems relevant to successfully and securely
implementing/extending this spec. This becomes equally relevant when
attempting to understand why the choice of 128-bits of entropy within
Section 3.1, since it seems the choice in the size of the parts is equally
related to this undocumented threat.

In Section 3.1, I'm probably just not familiar enough with the underlying
specs, but as far as I could tell, it's not clear why Step 3 the ACME
client needs to indicate the  to the BP agent, versus just the
source. The source Node ID is clear, at least, but it seems like, at best,
 might just be serving as a "request ID" of sorts (judging by
3.4)

The reason I highlight this is because I think it diverges from some of the
classic assumptions about ACME and challenge design, because it seems to
suggest that  may transit the network in the clear and/or be
held by multiple parties, which is a very different model than the history
of ACME's DNS/TLS challenges being tied to the CA/Browser Forum's Request
Token (which not simply a random value, but uniquely bound to the original
request and is single-use). I *think* this might just be a terminology
issue here, but would it make sense to name these according to their
structural purpose, rather than just "token-part1" / "token-part2"?

In Section 3.3, it's stated "The ACME server SHOULD NOT perform URI
normalization on the Node ID given by the ACME client.". It seems like this
deserves its own section within Security Considerations, because as with
the above remarks, when, where, and how URI normalization is performed
seems like it has significant security impact. Even if this protocol uses
unnormalized URIs throughout the entire protocol, if implemented on top of
anything that performs normalization, or the certificates that are issued
are used by clients that perform normalization, you can end up with
ambiguities / confused deputies. Normally in a security protocol you would
want to validate and normalize your 'hostile' inputs as early as possible
in this flow, and that's one of the key roles of the ACME Server / CA, so
that it uses identifiers that are post-normalized/unambiguous. This seems
like a major oversight, but it could be that I'm misunderstanding something
specific to DTN.

Section 3.3 states "BP agents SHALL refuse to respond to a Challenge Bundle
which is signed by a known ACME server but has an invalid signature.". It
seems like this also deserves a note within the Security Considerations,
both in terms of how BP agents/ACME clients should determine whether an
ACME server is "known" and how they can successfully determine an invalid
signature (i.e. how to maintain the expected signing keys). This might
merely be a spec reference to DTN, but this normative language appears to
be trying to mitigate an undocumented security threat.

I agree with Russ' comments on Section 4 where the EKU MUST be included in
the issued certificate. Related, the profile from that Section 4.4.2 seems
problematic for implementation (around keyUsage), but alas, that's a whole
other issue for a whole other spec :)

Section 6.1 feels unnecessarily light for explaining why 

Re: [Acme] should acme-subdomains support http-01 challenges?

[Ryan Sleevi]

Responding to part of this.

On Sun, Dec 13, 2020 at 3:47 PM Michael Richardson 
wrote:

> > If a client is advertising multiple ADNs it can authorize, should the
> > supported challenge type be per ADN? e.g. dns-01 and http-01 for
> > foo1.foo2.bar.example.com but only dns-01 for example.com? Is this
> > flexibility in any way useful, or just likely to lead to confusion
> and
> > implementation bugs?
>
> > For sure, the way the draft is currently written, if a client places
> an
> > order for a subdomain, and the server issues a single challenge for a
> > parent ADN (which could be the BDN/Base Domain Name), then this will
> > result in frequent failures as the client is not authorized to
> control
> > the parent ADN/BDN.
>
> I guess I'm also confused by why a client would issue an order for a
> sub-domain for a domain it has not received authorization.
> Obviously, an attacker might do that, but why wouldn't the order just be
> rejected?


I'm not sure what you mean here, could you explain?

It sounds like you're suggesting that pre-authorization should be the only
flow (that is, newAuthz before newOrder). However, newAuthz is optional
(RFC 8555, Section 7.4.1), as also called out in the draft
(draft-friel-acme-subdomains-03, Section 5.1). However, I suspect I'm
misunderstanding your question?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fwd: New Version Notification for draft-biggs-acme-sso-00.txt

[Ryan Sleevi]

On Wed, Dec 9, 2020 at 12:00 PM Richard Barnes  wrote:

> Hi ACME folks,
>
> I'd like to bring this proposed extension to ACME to the attention of the
> working group.  This work builds on Alexei's document defining the "email"
> identifier type, and defines
>


> (1) a mechanism for validating email addresses using SSO,
>

Apologies for pedantry here, but is this really validating e-mail
addresses? It seems like it's delegating validation to an IDP? This might
be more of a "Web PKI" semantic quibble, and I understand your plan is to
*not* use such CAs and might be moot, but it seems an important enough
distinction to call out.

That is, as I understand it, the domain holder indicates an SSO IDP that
the CA may trust assertions for. The CA then directs the Applicant to
authenticate with the IDP, and the IDP returns an assertion to the CA. The
CA then accepts that assertion, provided that the global-part (dot-atom)
matches, right? The validation isn't of an e-mail address; the validation
is of an IDP declaring that e-mail address associated with a given account
(e.g. a JWT, a SAML assertion, etc).

Note: Is referencing dot-atom correct, in this case, since rfc822Name is
restricted to preferred name syntax by virtue of the dependency on RFC
2821, as constrained by Section 2.3.5 (
https://tools.ietf.org/html/rfc2821#section-2.3.5 )


> and (2) some CAA mechanisms to manage issuance of certificates with email
> addresses.
>

Did I miss a normative dependency on / informative reference to RFC 8657
here? It seems relevant, since this is repurposing the parameter space that
is CA specific (as called out by
https://tools.ietf.org/html/rfc8657#section-6 ), and there's explicitly no
IANA registry to deconflict because of that. I realize that the parameters
are also specific to the tag, which you're defining a new tag here, but
this all seems... messy? That is, to have "validationmethods"  semantics
not depend on the CA (as it does for issue/issuewild) but instead depend on
whether it's issue vs issue-email.


> I would like for the ACME WG to take this on as a work item, as a logical
> next step following on draft-ietf-acme-email-smime.  Any feedback on the
> draft would be very welcome.
>

I'm hesitant as to whether this is a good idea, because this seems like a
significant shift in the level of assurance / what's validated, so I don't
think it's as clear a logical next step. While I don't plan to implement
(and would be opposed to implementing for trusted S/MIME CAs, for example),
I acknowledge it has interest for other use cases, and so would be
supportive of adopting in order to continue refining the security
considerations to be more explicit that validation is being delegated to a
third-party, rather than performed by the CA.


>
> Thanks,
> --Richard
>
>
> -- Forwarded message -
> From: 
> Date: Tue, Dec 8, 2020 at 10:09 AM
> Subject: New Version Notification for draft-biggs-acme-sso-00.txt
> To: Andrew Biggs , Richard L. Barnes 
>
>
>
> A new version of I-D, draft-biggs-acme-sso-00.txt
> has been successfully submitted by Richard Barnes and posted to the
> IETF repository.
>
> Name:   draft-biggs-acme-sso
> Revision:   00
> Title:  Automated Certificate Management Environment (ACME)
> Extension for Single Sign On Challenges
> Document date:  2020-12-08
> Group:  Individual Submission
> Pages:  12
> URL:
> https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.txt
> Status: https://datatracker.ietf.org/doc/draft-biggs-acme-sso/
> Html:
> https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.html
> Htmlized:   https://tools.ietf.org/html/draft-biggs-acme-sso-00
>
>
> Abstract:
>This document specifies an extension to the ACME protocol [RFC8555]
>to enable ACME servers to validate a client's control of an email
>identifier using single sign-on (SSO) technologies.  An extension to
>the CAA [RFC8659] resource record specification is also defined to
>provide domain owners a means to declare a set of SSO providers that
>ACME servers may rely upon when employing SSO for identifier
>validation on their domain.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

On Tue, Dec 8, 2020 at 8:14 PM Michael Richardson  wrote:

> > Alas, I'm equally at a loss to understand what you're asking here,
> as I
> > can't make much sense of your question?
>
> dns-01 challenges for bar.bar.foo.example do not have to show control over
> foo.example.
> Yet, you seem to think that they do.
>

Thanks for being clear!

To respond: No, I don't.

I'm highlighting that for a requested identifier of "baz.bar.foo.example",
the CA is permitted to challenge for "bar.foo.example" or "foo.example".
Indeed, some CAs, by default, will *only* challenge for "foo.example",
despite that being a parent of the requested domain, because they want to
reduce the effort involved to issue other certificates to that user.

Now, I never said a CA "has" to, but it's certainly true that a number of
CAs do, in fact, require this as their standard operating procedure, and my
understanding is that this proposal was specifically about enabling such
cases within ACME. That is, more generally, making a clear and well-lit
path where the domain used in the authorization does not match the domain
in the certificate.

Is that an unreasonable understanding? It seems directly supported in the
text of the draft, Section 5.4,
https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.4 ,
example 1.


>
> >> The client does not demonstrate control over lex.example using
> dns-01 when
> >> it
> >> asks for so.me.comp.lex.example.
>
> > Is that not literally what this draft is proposing (e.g.
> >
> https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ?
>
> It demonstrates control (during the authorization) for lex.example, which
> allows it to fullfil orders for so.me.comp.lex.example.
>
> Your line of questioning implies you think the reverse.
> 5.2 clearly shows authorization for example.org, followed by an order for
> sub.example.com


I am again at a loss for what you mean here / what you are attributing to
me. Equally, I'm hoping that the "example.org" / "sub.example.com", as I
cannot make any sense of what you said otherwise.

As to your statement about me thinking the reverse, I'm hoping you can
perhaps rephrase the following paragraph in Section 5.1:

   It may make sense to use the ACME pre-authorization flow for the
   subdomain use case, **however, that is an operator implementation and
   deployment decision.**  With the ACME pre-authorization flow, the
   client could pre-authorize for the parent domain once, and then issue
   multiple newOrder requests for certificates for multiple subdomains.

With the section in emphasis (**), it seems clear that this draft is not
prescriptive as to whether the example in Section 5.2 (the
"pre-authorization flow") needs to be required.

To try to be clearer, since it seems you and I may be talking past each
other and have been for some time, I'm considering the following flow:

- POST /newOrder "so.me.comp.lex.example"

Where the server needs to determine the appropriate set of authorizations
to return for this case and the set of challenges within those
authorizations. Again, this seems directly supported by Section 5.4 of the
draft,
https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.4 ,
example 1.


> > In the pre-auth flow, the client affirmatively requests
> "lex.example" (In
> > the illustration here, "example.org"), in order to authorize
> > "so.me.comp.lex.example" (in the illustration here, "sub.example.org
> ").
> > That is, the client explicitly declares their naming scope.
>
> > However, in the pre-auth flow, you have to know that the client will
> want
> > to be able to /newOrder for "sub.example.org" (as Step 2 in the
> > illustration), since you shouldn't return http-01 authorizations in
> Step 1
> > for this case.
>
> how are http-01 authorizations involved?
> The client asks for dns-01 authorizations.


Can you point me to the text in the draft you're using to support this
statement? As far as I can tell, there's nothing in the draft to indicate
that the client asks for dns-01 authorizations. Further, there's nothing as
far as I can tell that prohibits, restricts, or even allows a CA to
indicate that an http-01 authorization would not be allowed.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

On Tue, Dec 8, 2020 at 4:33 PM Michael Richardson 
wrote:

>
> Ryan Sleevi  wrote:
> >> The client has control over lex.example, but and can prove it with
> dns-01
> >> TXT
> >> record placed at _acme-challenge.lex.example.  Why does it matter
> whether
> >> it
> >> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example.
> >> or an.other.comp.lex.example??
>
>
> > The mistake you’ve made here is assuming the client has control over
> > lex.example, and thus all subdomains. The point of all of this is
> that is
> > an unrealistic assumption: the client may only have control over the
> DNS
> > zone at so.me.comp.lex.example or they might have control at the
> > me.comp.lex.example, but no control at comp.lex.example.
>
> I don't understand.
> If the client doesn't control lex.example, then why would it expect to get
> any kind of control of that?
> Same as without subdomains.
>

Alas, I'm equally at a loss to understand what you're asking here, as I
can't make much sense of your question?


> > The existing approach with ACME assumes and expects that validation
> will be
> > done at the FQDN (this is an oversimplification, but the nuance here
> isn’t
> > as important).
>
> Yes, the FULLY-QUALIFIED.  Not the public name.
> dns-01 works just fine today for so.me.comp.lex.example.
>
> The client does not demonstrate control over lex.example using dns-01 when
> it
> asks for so.me.comp.lex.example.
>

Is that not literally what this draft is proposing (e.g.
https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ?

In the pre-auth flow, the client affirmatively requests "lex.example" (In
the illustration here, "example.org"), in order to authorize
"so.me.comp.lex.example" (in the illustration here, "sub.example.org").
That is, the client explicitly declares their naming scope.

However, in the pre-auth flow, you have to know that the client will want
to be able to /newOrder for "sub.example.org" (as Step 2 in the
illustration), since you shouldn't return http-01 authorizations in Step 1
for this case.

For authorizations created in response to a request (i.e. the non-preauth
flow, which this draft explicitly states is allowed in 5.1), the CA has to
make a determination about what authorizations to issue, and the state to
track all of those pending authorizations created, which gets us back to
the discussion.

The significant majority of CAs, for the majority of certificates issued by
these CAs, totally rely upon authorizing "lex.example" in order to issue
certificates for "so.me.comp.lex.example" (whether using DNS-01, email, or
other). So I'm not sure what you mean by "does not demonstrate control".

Hopefully, this reply helps clarify, but if you still aren't sure, I'm
hoping you could be clearer on the uncertainty and I'll do my best to
rephrase.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

On Mon, Dec 7, 2020 at 8:30 AM Michael Richardson 
wrote:

>
> Ryan, I'm not really following this conversation.
> Probably my mental model of dns-01 challenges is lacking.
> The word "window" does not appear in RFC8555 or acme-subdomains, so that's
> your word, I think.
>
> Ryan Sleevi  wrote:
> > Further, if we assume that say there are ten domain labels, but the
> server
> > is only willing to maintain state for five (as a window), then it’s
> not
> > clear how the client can request the server sends the first five
> rather
> > than the last five. Having the client advertise its capabilities
> let’s the
> > client choose the window, and if the server rejects all of them, the
> client
> > at least can try again with a different window (e.g. the last five
> > labels).
>
> I don't really understand this at all.
> I think that we are discussing so.me.comp.lex.example.
>
> The client has control over lex.example, but and can prove it with dns-01
> TXT
> record placed at _acme-challenge.lex.example.  Why does it matter whether
> it
> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example.
> or an.other.comp.lex.example??


The mistake you’ve made here is assuming the client has control over
lex.example, and thus all subdomains. The point of all of this is that is
an unrealistic assumption: the client may only have control over the DNS
zone at so.me.comp.lex.example or they might have control at the
me.comp.lex.example, but no control at comp.lex.example.

The existing approach with ACME assumes and expects that validation will be
done at the FQDN (this is an oversimplification, but the nuance here isn’t
as important). The point is that if the server decides to challenge
lex.example or comp.lex.example, it will fail for this client, so that’s
why we need some form of either/or or both/and of multiple challenges and a
client indicated set of capabilities.

The window is simply which labels you select: the example you chose has
five labels, so whether we select the “first” two domains (“so” and “me”
working from most to least specific) or the “middle” two (“comp” and “lex”)
matters. Similarly, it’s valid to issue a challenge for “example” in all of
its glory: this comes up with ICANN Spec-9/Spec-13 gTLDs, and so it’s
useful to allow the client to say “no, really, validate the *entire*
namespace”. So even if the server challenged “lex.example” that could be
the wrong level.

One thing that just occured to me is whether or not there is any value in
> the
> dns-01 challenge remaining in the DNS after the authorization.
> What I'm thinking is that the CA could offload some of it's state for the
> client to store for it.


I don’t think it’s reasonable at all to make changes like that. It would
either limit issuance of multiple independent certificates within a time
period (collision on _acme-validation) or would encourage the use of random
values in the labels.


>
> > That’s why my slight preference was to have the client advertise.
> > Processing after validation seemed preferable to processing prior to
> > validation, and it also seemed useful to let the client advertise
> > capabilities directly to let the server reduce any stored state.
>
> > However, I
> > can equally imagine an asinine implementation of client-advertise
> that
> > requests a cert for “www.example.com” but let’s the client set the
> ADN as “
> > example.net” and, post-validation of example.net, fails to check
> that “
> > example.net” matches “example.com”. Or does something equally silly
> like
> > allowing “prefix.example” to authorize
> “not-actually-a-prefix.example”.
>
> I can't see how any of these things are anything other than serious bugs.


I didn’t say they weren’t. But just like C is a fundamentally insecure
language that no one ethically responsible or security conscious should
choose as a first choice for new code, the ergonomics of the decisions here
are worth pointing out. There are Top 10 CAs that are misissuing
certificates because they found it “confusing” to locate requirements [1]
or manually implement the CAA lookup algorithm by hand for every request
[2]. My intent in pointing these out is to acknowledge that we have to
contemplate the worst possible implementations, and view the risks through
that lens, when thinking about risks or tradeoff. We simply can’t assume a
competent implementation, unfortunately.

[1]
https://bugzilla.mozilla.org/show_bug.cgi?id=1662807
[2]
https://bugzilla.mozilla.org/show_bug.cgi?id=1651026#c12

>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

On Sun, Dec 6, 2020 at 9:32 PM Owen Friel (ofriel)  wrote:

> [ofriel] Are there any benefits or security advantages in #1 (client
> giving server options) vs. #2 (server giving client options)? With #2, the
> client does not have to explicitly divulge any information about its level
> of domain control. The server gives the client a set of options, and the
> client decides what to do. Obviously, if it fulfils the challenge against a
> parent Authorized Domain Name, then it has implicitly indicated control
> over that domain.
>
🤷‍♂️

If there is a limit to the number of challenges, it seems it benefits from
the client choosing/advertising. Until the challenge is complete, the
server has to maintain state for (effectively) an unauthorized user, while
in the client-advertise scenario, there’s no server state other than what
the server chooses to use.

Further, if we assume that say there are ten domain labels, but the server
is only willing to maintain state for five (as a window), then it’s not
clear how the client can request the server sends the first five rather
than the last five. Having the client advertise its capabilities let’s the
client choose the window, and if the server rejects all of them, the client
at least can try again with a different window (e.g. the last five labels).

I don’t know how compelling this is, but my assumption here is that because
we’re discussing effectively DNS-01 challenges, the client is limited in
its abilities, and so the client should indicate it’s capabilities, and
minimize server state.

Equally in this scenario, I think you're asking whether or not the client
> should be able to indicate its capabilities to the ACME server, for
> selecting appropriate challenges. If a client is using dns-01 and can only
> modify subdomain.example.com, it doesn't benefit the client at all if the
> server chooses to also allow example.com. The question is whether there's
> a security risk in doing so; that is, should the client be able to
> affirmatively restrict the server or does it not matter.
>
>
>
> [ofriel] Yes, that is exactly what I am getting at. Perhaps the question
> #1 should be phrased more accurately something like: Does the client need a
> mechanism to indicate to the server that it is capable of and authorized to
> fulfil challenges against the requested subdomain FQDN, as well as some or
> all of the parent Authorized Domain Names (potentially up to and including
> the Base Domain Name).
>
>
>
> TBH I have no thought about the security risk of a client indicating to
> the server that it has control over parent domains, potentially including
> the Base Domain Name. What does the CA/B currently think about this?
>
I mean, right now there’s no rules on which party selects the Authorization
Domain Name, when an ADN is allowed. The CA still has to validate the ADN
against the rules.

Having the client indicate minimizes CA processing before validation; each
of the advertised ADNs can really be treated as independent FQDNs (that is,
largely opaquely), and only after validation of the challenge does the CA
do any processing on the domain label, to ensure it’s an ADN for the
(originally requested) FQDN.

That’s why my slight preference was to have the client advertise.
Processing after validation seemed preferable to processing prior to
validation, and it also seemed useful to let the client advertise
capabilities directly to let the server reduce any stored state. However, I
can equally imagine an asinine implementation of client-advertise that
requests a cert for “www.example.com” but let’s the client set the ADN as “
example.net” and, post-validation of example.net, fails to check that “
example.net” matches “example.com”. Or does something equally silly like
allowing “prefix.example” to authorize “not-actually-a-prefix.example”.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

Thanks for bringing it to the list, Owen.

This is something we're trying to lock down in the CA/B Forum, at least
with respect to the 'http-01' method, by making it clear that, like
tls-alpn-01, it cannot be used as an Authorization Domain Name (i.e. a
domain and all of its descendents), only as an FQDN.

So this method primarily is for the 'dns-01' method, which seems to suggest
that, at a minimum, the ACME server needs to indicate to the ACME client
what modifications it will accept, since the ACME client will need to
actually modify the DNS record at the appropriate label. If the server only
chooses a single label, then it seems both likely and possible that the
server may choose a dns-01 challenge that the client cannot fulfill (e.g.
the client can only modify subdomain.example.com and descendents, but the
server/CA chooses to challenge against example.com)

So I *think* it would benefit from having the server be able to issue
challenges against several identifiers, and communicate that to the client,
which seems to argue "Yes" for your question #2.

Equally in this scenario, I think you're asking whether or not the client
should be able to indicate its capabilities to the ACME server, for
selecting appropriate challenges. If a client is using dns-01 and can only
modify subdomain.example.com, it doesn't benefit the client at all if the
server chooses to also allow example.com. The question is whether there's a
security risk in doing so; that is, should the client be able to
affirmatively restrict the server or does it not matter.

Does that accurately capture things?

On Fri, Dec 4, 2020 at 10:25 AM Owen Friel (ofriel)  wrote:

> That is what is currently documented – the server simply picks the one
> domain that it wants the client to fulfil the challenge against.
>
>
>
> That was presented as the current documented approach. And I also
> presented the open questions if we needed to build flexibility in client
> request and/or server response. There were no concrete opinions as far as I
> recall (waiting on the exact minutes) and Rich said to bring the qs to the
> mailer for further discussion.
>
>
>
> Cheers,
>
> Owen
>
>
>
>
>
> *From:* Acme  *On Behalf Of *Felipe Gasper
> *Sent:* 04 December 2020 21:35
> *To:* Owen Friel (ofriel) 
> *Cc:* acme@ietf.org
> *Subject:* Re: [Acme] acme subdomains open items
>
>
>
> I wasn’t part of IETF 109 .. was it discussed simply to give CAs the
> ability to choose whether it tries authz against parent domains without the
> client’s requesting it?
>
>
>
> This is how our (non-ACME) Sectigo integration works currently, and it
> suits us well.
>
>
>
> -F
>
>
>
> On Dec 4, 2020, at 02:23, Owen Friel (ofriel) <
> ofriel=40cisco@dmarc.ietf.org> wrote:
>
> 
>
> Hi all,
>
>
>
> As recommended by the chairs at IETF109, bring the two open items to the
> list for discussion. These were raised by Felipe and Ryan previously.
>
>
>
> 1: Does the client need a mechanism to indicate that they want to
> authorize a parent domain and not the explicit subdomain identifier? Or a
> mechanism to indicate that they are happy to authorize against a choice of
> identifiers?
>
>
>
> E.g. for foo1.foo2.bar.example.com, should the client be able to specify
> anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?
>
>
>
> 2: Does the server need a mechanism to provide a choice of identifiers to
> the client and let the client chose which challenge to fulfil?
>
>
>
> E.g. for foo1.foo2.bar.example.com, should the server be able to specify
> anywhere from 1 to 4 identifiers that the client can pick from to fulfil?
>
>
>
> Both 1 and 2 require JSON object definition changes. Currently, the
> document only defines how a client can submit a newOrder / newAuthz for a
> subdomain, and the server can chose any one parent identifier that it
> requires a challenge fulfilment on
>
>
>
> Owen
>
>
>
>
> https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01
>
>
>
> https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4
>
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] CAA DNS RR IODEF e-mail spam && client side CAA verification

[Ryan Sleevi]

On Thu, Oct 22, 2020 at 11:59 AM Anton Luka Šijanec 
wrote:

> Hello!
>
> I hope I am addressing this e-mail to the correct mailing list. After
> glancing through the CAA DNS RR specifications for allowing only
> specific CAs to issue certificates for a specific domain, I saw that
> the iodef field for specifying the URI for sending violations is not
> verified when submitting reports to different domains.
>
> What I mean by this is that someone.example can specify an email
> address of someone@else.example. Then someone.example issues a lot of
> certificate signing requests to CAs that are not allowed for his
> domain, filling someone@else.example's inbox with violation spam.
>
> I propose a system, such as the one used for DMARC, to allow
> whitelisted cross-domain violation email delivery.
>
> For example, if IODEF field of caa.example specifies "mailto:
> report@violation.example", CAs will before sending a report check if
> the TXT record caa.example._caa.violation.example. has a value of
> "CAA=v1; caa-reports=allow;" or something similar.
>
> If such a system is already in place, how can I make sure I am
> correctly implementing it on my domain? Can someone direct me to the
> specification?
>
> My second suggestion is that client browsers would verify certificates
> by performing DNS CAA queries and validating if the certificate is okay
> and optionally send violation reports. What are your thoughts?


This is intentionally, and explicitly, not part of CAA. CAA is designed as
an ACL on issuance; were clients to check, this would necessitate that
domains continue to authorize future certificate issuance.

For example, if I used CA A at Time 0, but later switched new issuance to
CA B at Time 10, if clients checked at Time 11, I would be required to list
both A and B as authorized; A, because it had authorized some of my
existing certificates, and B, because it was authorized for new
certificates.

Short of replacing every unexpired, unrevoked certificate from A, I would
not be able to safely and securely only authorize B going forward.

Section 1 of RFC 8659 makes this unambiguous:
> Relying Parties MUST NOT use CAA records as part of certificate
validation.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] dns-01 challenge limitations

[Ryan Sleevi]

On Sun, Sep 13, 2020 at 5:25 AM Simon Ser  wrote:

> > The question would be whether or not it would get implemented.
>
> Yes, this is why I'm writing to this mailing list. Maybe I should've CC'ed
> some
> Let's Encrypt specific mailing list as well.


It's certainly possible, but to be clear: any option for implementing a
validation method needs to be clear enough that browser/OS vendors will
permit it as acceptable. The gating function here is whether product
vendors, for their products, find it sufficiently secure, not whether CAs
do. CAs can often act as intermediaries, proposing ideas to browser/OS
vendors. Ultimately, as (sometimes contracted, always delegated) suppliers,
acting on behalf of the browser/OS vendor, your ultimate gate isn't
demonstrating whether there's consensus to write an I-D, or consensus with
a CA, but that there's consensus with the browser/OS vendors that would
implement it within their root programs.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] dns-01 challenge limitations

[Ryan Sleevi]

This is the least secure option and most likely to be deprecated going
forward. Sending an email, even to the IANA-defined boundaries, is simply
not a substitute for proof of domain control.

On Sun, Sep 13, 2020 at 5:17 AM Philipp Junghannß 
wrote:

>  maybe one could make it so an email specific to the domain that is
> verified could be used instead to just screw the entire DNS thing? I mean
> CAs have used e-Mail based issuance over the address in the whois (no
> longer  practical due to increase of whois privacy by default) or the
> standardized hostmaster etc addresses. that way any given acme client would
> only need access to the inbox of that specific mail which probably is a
> whole lot easier than DNS stuff.
>
> Am So., 13. Sept. 2020 um 11:13 Uhr schrieb Simon Ser  >:
>
>> > On Friday, September 11, 2020 4:26 PM, Ryan Sleevi <
>> ryan-i...@sleevi.com> wrote:
>> >
>> > > On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß <
>> teamhydro55...@gmail.com> wrote:
>> > >
>> > > > problem is obviously also the CA/Browser Forum has certain
>> requirements,
>> > > > and I guess having access to some kind of direct verification at
>> the time
>> > > > of issue might be probably one of these.
>> > >
>> > > This is the correct answer.
>> > >
>> > > While the IETF can certainly explore developing voluntary standards
>> for
>> > > other methods, the ability for CAs to adopt these methods is limited
>> by CAs
>> > > customers: the browsers and operating systems that include and use
>> CAs to
>> > > validate domain names on their behalf.
>> > >
>> > > The explicit goal by several browser/OS vendors is to obtain a fresh
>> proof
>> > > of control over a domain, and reduce/eliminate any caching or reuse.
>> > > Delegation (by keys or persistent records) is definitely an area of
>> > > expressed concern.
>>
>> My take is that in theory it's an understandable goal, but that in
>> practice,
>> this detoriorates security.
>>
>> In practice, ACME clients:
>>
>> 1. Have a static, long-term token stored in their configuration file
>> 2. The token is powerful and can update any DNS record in the zone
>>
>> How come browser/OS vendors are fine with this, but not with a different
>> approach involving an ACME-specific key?
>>
>> Sure, since this happens behind the ACME/DNS protocols and is an
>> implementation
>> detail, this isn't ACME's responsibility anymore. However, because
>> browsers/OS
>> vendors have this requirement of not allowing delegated proofs, we end up
>> with
>> a worse situation than necessary.
>>
>> Ultimately, ACME clients need a way to update DNS records to solve the
>> dns-01
>> challenge. Ignoring and pushing the problem down to the DNS operators
>> does not
>> fix the root cause.
>>
>> If an ACME client needs to prove that they have authority over a DNS
>> zone, they
>> will need some kind of authorization/key/token or similar, be it
>> vendor-specific or not. Why not acknowlege this fact and come up with a
>> reasonable standard?
>>
>> > > I think the suggest of more uniform APIs for managing DNS is very
>> much in
>> > > line with those goals, and would help far more than ACME.
>>
>> Yes, no matter what ACME requires, a standardized API to update DNS
>> records
>> would be nice. Michael Richardson suggested that such an API (or a subset
>> of)
>> already exists (via secure DDNS), but isn't supported by most DNS
>> operators
>> (even if supported by some DNS daemons).
>>
>> Establishing a new standard involves talking to existing DNS operators,
>> and ask
>> them to implement the new standard. For them, the new standard wouldn't
>> have a
>> high enough return on investment: ACME clients already volunteer to
>> implement
>> each and every proprietary API. Even if a good standard ticking the
>> checkboxes
>> of RFC 5218 existed, I don't think it would be successful (no "Positive
>> Net
>> Value" for DNS operators).
>>
>>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] dns-01 challenge limitations

[Ryan Sleevi]

On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß 
wrote:

> problem is obviously also the CA/Browser Forum has certain requirements,
> and I guess having access to some kind of direct verification at the time
> of issue might be probably one of these.
>
This is the correct answer.

While the IETF can certainly explore developing voluntary standards for
other methods, the ability for CAs to adopt these methods is limited by CAs
customers: the browsers and operating systems that include and use CAs to
validate domain names on their behalf.

The explicit goal by several browser/OS vendors is to obtain a fresh proof
of control over a domain, and reduce/eliminate any caching or reuse.
Delegation (by keys or persistent records) is definitely an area of
expressed concern.

I think the suggest of more uniform APIs for managing DNS is very much in
line with those goals, and would help far more than ACME.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME subdomains

[Ryan Sleevi]

On Thu, Sep 3, 2020 at 9:47 AM Salz, Rich  wrote:

>
>- I followed the patterns used in RFC8555 which consistently uses
>example.com as the ACME server base domain and example.org as the
>client certificate identifier base domain, but yes Ryan I did find this a
>source of confusion too when reading ACME.
>
>
>
> Thanks for the changes.  I am also confused by example.com and example.org.
> Someone want to grab acmeserver.org and donate it?
>

That still seems problematic; registrations are fixed lifetimes.

Just use RFC 6761 https://tools.ietf.org/html/rfc6761#section-6.5

Specifically, acmeserver.example

As James points out, the use isn't really consistent with RFC 8555 in the
examples provided, and that's why it bears clarifying. However, my specific
concern was this statement:

"For flexibility, I guess if the client wants foo.bar.example.org the
protocol should also allow server choice of offering challenges for (1)
both foo.bar.example.org and  example.com (2) only the requested identifier
foo.bar.example.com or (3) only the parent domain example.com."

Which is the problematic area. I believe this is "trying" to say that the
options are:

foo.bar.example.org
bar.example.org
example.org

And all permutations/combinations of those.

Whether those go to acmeserver.com or acmeserver.example is irrelevant; the
point of clarification is what challenges can be used for the identifier.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME subdomains

[Ryan Sleevi]

There’s a lot of mixing of example.org and example.com here, in ways I’m
having trouble making sense of. I just wanted to confirm those were typos,
since we have recently seen some confusion around this space.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] CAA in draft-ietf-acme-client-01.txt

[Ryan Sleevi]

Ben: This text was intended towards auditors, and is indeed part of the
ongoing logging requirements imposed on CA. While it’s easy to imagine a
hypothetical world of CAA transparency and talk of it as if it was a thing,
there are a number of real and practical operational challenges that make
it more than “just” a log, particularly given the time-bounded nature of
DNSSEC validity and cryptographic material.

The text in the draft, as is, is problematic, because that’s not been the
goal of CAA, and using it in such a manner, particularly clients, would be
actively harmful to the security value and deployability of CAA, and
further makes migration CAs unnecessarily difficult. This was a hugely
contentious barrier towards the deployment and requirement of CAA support
by CAs, and would have obvious lasting security harm.

Concretely, imagine at Time 0, my CAA record says “foo.example”, and a
certificate with a validity period of 100 is issued. At Time 10, I cease
doing new business with Foo CA, and transition to Bar CA, with CAA record
of “bar.example”

If clients check CAA, I would have to continue to permit Foo to be able to
issue new certificates from T=10 to T=100 in order to continue to use my
existing certificates. Further, I would have no technical means of
disclaiming or proving any misissuance; e.g. due to Foo using validation
methods my organization did not wish to use, because my organization could
not adequately secure them. In such a world, it would be “my” fault, while
CAA provided a way to shift that burden to the CA performing the validation..

This doomsday scenario doesn’t even require “most” clients to do so; just
“enough” and the interoperability risk of CAA would be too great and the
only obvious answer would be to not deploy it.

In code signing, this is even more pronounced, because although the
validity period is T=0 to T=100, code signing that delegates to third party
CAs, as opposed to directly administered by the vendor, tends to
counter-sign such signatures with a timestamp, so that the signed artifact
can be used outside of its validity period. If the counter-signer checked
CAA, you “only” have to worry about keeping CAA around for [T=10, T=100],
but if the client verified CAA, you’d have to keep it around for [T=10,
T=infinity] in order to keep that artifact valid.

As Roland states, CAA is between a site, the CA, and whomever supervises
that CA (e.g. auditors, supervisory bodies, etc). It provides a form of
dispute resolution about whether a certificate was authorized at the time
it was issued, in a consistent and interoperable way. The logs maintained
by CAs are primarily there to aid in that direct dispute resolution, which
is an inherently fuzzy and human process for what is expected to be a truly
exceptional situation, and anything more generic/more broadly would require
significantly greater complexity and design before it could be said to meet
any verification goals.

I support the paragraphs removal.

On Tue, Jul 28, 2020 at 4:12 PM Ben Schwartz  wrote:

> RFC 6844 Section 4.1 points out that logged DNSSEC-signed CAA records can
> be used when auditing CAs for mis-issuance.  The current draft says "CAA
> helps as anyone ... can verify that the CA used has been authorized", which
> is true, but only if "anyone" has access to a log of the signed CAA records
> used by the CA, and the domain is DNSSEC-signed.
>
> I would like it if CAs published such logs, but I don't know whether it is
> a common practice.
>
> On Tue, Jul 28, 2020 at 3:58 PM  wrote:
>
>> Roland,
>>
>>
>>
>> Thank you, that’s very helpful  Any other opinions?  I’m very happy to
>> delete with consensus and appreciate the reviews on this particular issue
>> as well as on the draft.
>>
>>
>>
>> Best regards,
>>
>> Kathleen
>>
>>
>>
>> *From:* Roland Shoemaker 
>> *Sent:* Tuesday, July 28, 2020 3:27 PM
>> *To:* Kathleen Moriarty
>> *Cc:* Carl Mehner; Moriarty, Kathleen; IETF ACME
>> *Subject:* Re: [Acme] CAA in draft-ietf-acme-client-01.txt
>>
>>
>>
>> [EXTERNAL EMAIL]
>>
>> I think the disconnect here is between CAs and Relying Applications (i.e..
>> browsers) using CAA. The CA should use CAA to validate if they have
>> authority to issue, but the relying application must not because the CAA
>> records are only applicable at the time of issuance and there is no
>> guarantee that the current CAA records may match the records that were
>> present in the past (i.e. I may set my CAA record to allow "example-ca",
>> issue a certificate, and then set my CAA record to an empty string to
>> prevent issuance from anyone, the check is valid at the time of issuance,
>> but anyone trying to do post-issuance validation would fail since the
>> record has changed).
>>
>>
>>
>> I would support removing the paragraph.
>>
>>
>>
>> On Tue, Jul 28, 2020 at 7:57 AM Kathleen Moriarty <
>> kathleen.moriarty.i...@gmail.com> wrote:
>>
>> Hello Carl,
>>
>>
>>
>> Thank you for your review and I apologize for my extremely tardy response.

Re: [Acme] Onion address validation extension

[Ryan Sleevi]

On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara 
wrote:

> On Wed, Jul 08, 2020 at 08:03:40PM +0200, Sebastian Nielsen wrote:
> > Couldn’t it be done in the way that the ACME server creates a nonce.
>
> I am not sure why the client nonce is there. And I can not quickly find
> any discussion about cryptographic reasons.


This goes back to when it was originally introduced, and v2 addresses were
in use. It’s about mitigating the cross-protocol attack scenario.

The desire was to avoid having to introduce a full Tor implementation for a
CA to validate. It was seen that some POP was needed, not of the TLS Key,
but if the associated Tor HS key, in order to actually demonstrate some
association / “ownership” of the domain.

Having the whole CSR be signed meant the CSR would be replayable. So a CA
provided nonce was added, so the CA can demonstrably prove it was fresh.
However, if only CA data was used, then particularly with v2 addresses
(using SHA-1), there was a concern that a malicious CA might try to
compromise the HS security by making the CSR request a cross-protocol
signing oracle, supplying hostile nonces. So the client random was added,
to add entropy and otherwise mitigate this admittedly convoluted case. But
this was all predicated on v2 just having awful cryptographic properties
(truncated SHA-1 and 1024-bit RSA says what).

Unfortunately, you’re correct for pointing out that since the OID
allocations placed the CA attribute over the applicant attribute, the sort
of the SET of ATTRIBUTES defeats this. Alas, this is why the CABF benefits
from greater public participation.

The original thread starts around November-2014,
https://lists.cabforum.org/pipermail/public/2014-November/004569.html .
It’s easy to miss, because it around the same time there were discussions
of shortening certificate lifetimes and requiring id-kp-serverAuth in
certificates, things the CABF is **finally** getting around to doing in 2020

It could be for hash strenthening. However, that explanation is
> problematic:
>
> - The signature scheme is Ed25519, which has built-in hash
>   strengthening.
> - For hash strenthening via applicant nonce to actually work, the
>   CSR must have applicant nonce before CA nonce.
>
> However, I do not think it is impossible that it is indeed for hash
> strengthening and these two details were just missed.
>
> > 2 – OR the client can choose to submit the validation result inside
> > the final CSR. There is a object in the CSR called ”Challenge
> > password”, which could be ”reused” for this purpose, by filling it
> > with the result of the validation (ergo a signature by the onion
> > private key over the nonce).
>
> I do not think that would work for two reasons:
>
> - ACME protocol is not meant to proceed to CSR sending until after all
>   names are validated. Breaking that would cause implementation
>   problems.
> - The CSRs are assumed to be self-signed, which is a problem here:
>   - The signature needs to be from Tor key for obvious reasons.
>   - The Tor keys are Ed25519, which is not allowed in WebPKI,
> even for subscriber certificates.
>   - Even if the keys were allowed, using them for TLS is not
> cryptographically kosher. However, there should be no problems in
> this case.
>
>
> For designing a cleaner mechanism to propose to CABForum, I think
> reasonable starting point would be to model it like the ACME key-
> change endpoint.  However, signing JOSE messages with Tor key is
> not cryptographically kosher (just like singing CSRs with it is
> not kosher). However, again there should be no problems in practice
> (Tor itself never signs with this key, only derives other keys from
> it).


I think the odds of a change in the Forum are low here. I’ll readily admit,
I am intentionally rather hostile to JOSE / COSE being introduced into the
CABF, because of the consistent and persistent security failures these
formats lead to.

That said, given the rather significant improvements to the cryptographic
constructions of v3, I’m also quite keen for any establishment protocol in
the CSR that can suitably demonstrate a POP within the CSR. It needs to be
robust to cross-protocol reuse, but I suspect that is now substantially
easier given the v3 construction. I suspect that would also make it easier
for ACME, but perhaps I’m overlooking why even a simplified form is
challenging?

>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review of draft-ietf-acme-email-smime-07

[Ryan Sleevi]

On Fri, May 29, 2020 at 1:08 PM Russ Housley  wrote:
> >> ** What was the thinking behind the document status being informational?
> > I don't think there was much thought or discussion of this point. I am 
> > flexible. I think when I started it was not very clear how much 
> > support/interest there were in this, but I noticed more interest over time.
>
> I would like to see standards track.  I wonder what other in the ACME WG 
> think.

With my acknowledged bias towards thinking about policies around CAs
trusted in my employer's products, I think Informational makes sense.

I mention this largely because work is still ongoing within the
broader CA/Root Store industry around establishing requirements around
the issuance and validation of S/MIME certificates, and it's not at
all inconceivable to think things may need to change or be adjusted to
be used within those PKIs. The issuance practices and required level
of validation / validation process are not as well or widely
established and documented, nor are the expectations across vendors as
consistent, and so it's difficult to see that there's a lot of
"running code" for this model, in terms of CAs or Root Stores.

It's also not inconceivable that this may be fine as-is. I'll be the
first to readily admit that while I've read the document, I've not
read it to a degree that I'd be fully comfortable allowing it for use
by CAs that I might delegate to. While I don't for a second think that
alone is somehow reasonable to suggest Informational, when I look at
the broader sector of folks who have engaged within ACME on the draft,
I don't see a a wide variety of participants on the list or in the
minutes, and that makes me think that the lack of detailed review by
existing industry implementers may be a bit more wide-spread.

At the end of the day, I take the view that the question about whether
this provides "sufficient" assurance is going to be situational; it
depends on the needs and policies of the mail provider, the CAs, the
relying parties, MTAs, and root stores. That may be reason to think of
this on the "Experimental" or "Informational" spectrum, or it may be
that folks believe the particular mechanism is well-specified enough
that it deserves to be on the "Standards" track, and whether or not
parties implement or adopt that standard is entirely orthogonal.

Given that this spec describes a very specific method of providing
assurance, and not just a general protocol for assurance
establishment, I do lean towards Informational/Experimental.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

[Ryan Sleevi]

On Sat, May 2, 2020 at 2:11 PM Ben Schwartz  wrote:

>
>
> On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov 
> wrote:
>
>> Hi Ben,
>> On 21/04/2020 01:12, Ben Schwartz wrote:
>>
>>
>> On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov 
>> wrote:
>>
>>> Hi Ben,
>>>
>>> My apologies for missing your email in March:
>>>
>>
>> And mine for this delayed response.
>>
>>> On 12/03/2020 20:42, Ben Schwartz wrote:
>>>
>>> Section 3 says token-part1 "contains at least 64 bit of entropy", but
>>> Section 3.1 says token-part1 "MUST be at least 64 octet long after
>>> decoding".  Is this difference deliberate?
>>>
>>> No, I obviously made a typo when saying octets. I will fix.
>>>
>> Fixed.
>>
>> Also 64 octets of entropy is a _lot_.  RFC 8555 says "the token is
>>> required to contain at least 128 bits of entropy".
>>>
>>> The draft seems to be oriented entirely toward use with e-mail clients
>>> that have a built-in ACME-S/MIME client.  I'm a bit disappointed that the
>>> draft doesn't accommodate users with "naive" email clients very well, e..g.
>>> by allowing customized subject lines.
>>>
>>> Actually, I was trying to accommodate naive email clients, but it was a
>>> fine balance trying to specify minimal requirements.
>>>
>>> Can you suggest some specific text to change and then we can discuss
>>> whether or not it should be done? My thinking about the Subject header
>>> field was that I wanted to have a unique subject (so that ACME email
>>> messages are easily findable). I also wanted to allow the token in the
>>> subject for APIs that can easily access Subject and not other header fields.
>>>
>> In that case, I would suggest "... subject ending with "(ACME:
>> )", where ...".  That would allow the first part of the
>> subject (most likely to be seen by a human) to be human-readable.
>>
>> After thinking a bit more about this:
>>
>> As ACME servers are generating ACME challenge emails, the requirement on
>> them is stricter (they create the first message in an email thread). I am
>> tempted to leave this as is. Can you think of a case where ACME servers
>> would be unable to comply with this restriction?
>>
> My concern is that users will not know what to do if they receive an email
> whose subject line is "ACME: awlkNSdpijawrfz...".  Users are used to seeing
> emails whose subject line is "Please verify your email address" or "Confirm
> your email".  (My inbox is full of them.)  I see no reason to disallow that
> here.
>
> Mandating that the subject line be non-human-readable seems like an
> unnecessary barrier to adoption.
>

Are you expecting humans to be the primary interaction point? It almost
seems that ensuring human unfriendliness is a feature, not a bug, towards
the goal of automation.

This structure seems especially important if it has a chance to be adopted
by publicly trusted CAs. One of the big concerns with existing validation
approaches is bodies that are rich-text with links used for approval, and
for which anti-spam or scanning engines inspect (“click”) and cause
improper authorizations. The more structure, the better, towards preventing
accidental authorizations.

ACME responses already allow arbitrary prefix to accommodate naive clients.
>>
>> Similarly, for Section 3.2. Point 6, I would relax the requirement to
>> state that this block must appear somewhere in the body.  That way, if the
>> user sees the response message, it can provide some explanation of what is
>> going on.
>>
>> Good idea. Changed.
>>
>> For Section 3.1 Point 5, I don't understand why the body is restricted to
>> text/plain.  In particular, I think hyperlinks to explanations and
>> instructions are likely to be helpful.  I also wonder whether support for
>> multipart/multilingual could be useful.
>>
>> The body is irrelevant to ACME-aware clients, so it seems like there
>> could be a lot of freedom in how this is constructed.
>>
>> This is true for the challenge email.
>>
> Yes, that's what I was referring to.
>
>> There is a requirement on S/MIME (if used) to provide header protection,
>> but I agree that otherwise the body structure can be pretty flexible.
>>
>> Most email clients automatically convert HTTPS URLs to hyperlinks, which
>> should make the silly schemes I'm imagining possible, but not very
>> attractive, for ordinary users.
>>
>>> Best Regards,
>>>
>>> Alexey
>>>
>>> I assume this is deliberate, perhaps because of a desire to use
>>> short-TTL S/MIME certificates that would be impractical to provision
>>> manually, but the draft doesn't mention a rationale.
>>>
>>> On Thu, Mar 12, 2020 at 2:52 PM Salz, Rich >> 40akamai@dmarc.ietf..org <40akamai@dmarc..ietf.org>> wrote:
>>>
 This mail begins a one-week working group last call on
 https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?include_text=1



 If you have comments or issues, please post here.



 If anyone wants to be a document shepherd, please contact the chairs.

>>> Best Regards,
>>
>> Alexe

Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

[Ryan Sleevi]

On Tue, Mar 31, 2020 at 6:24 PM A. Schulze  wrote:

>
>
> Am 12.03.20 um 19:51 schrieb Salz, Rich:
> > This mail begins a one-week working group last call on
> https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?include_text=1
> (hopefully not to late ...)
>
> Hello @all,
>
> I became aware of a privacy problem once an ACME instance will implement
> this draft: CT logs.
> Usually the space of local parts for a domains email addresses is private..
> Enumeration is impossible and unwanted.
> But CT logs change some assumptions people may have...


Aren’t those concerns founded on certain assumptions that may not be
entirely accurate?
- That an ACME server (CA) implementing this is using the same trust
hierarchy that they use for TLS?
  - This is forbidden by most major client software (to issue both from the
same hierarchy)
- That the CT logs intended for one protocol (e.g. TLS) accept certificates
for other protocols
  - This is a bug in the current TLS CT logs being fixed (to properly
exclude non-TLS certificates)

Either, or both, of these issues mitigate the concern. However, it doesn’t
seem this concern is related to the protocol, nor would this draft change
anything (and was discussed heavily in TRANS)

>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Ryan Sleevi]

On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel) 
wrote:

> > Also, the linked document states:
> >
> >The call flow illustrates the DNS-based proof of ownership mechanism,
> >but the subdomain workflow is equally valid for HTTP based proof of
> >ownership.
> >
> > Can’t I have HTTP access to a base domain’s website without having
> access to a
> > subdomain’s, though? I thought that was the reason why ACME limits
> wildcard
> > authz to DNS.
>
> [ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an
> ACME limitation.


Although the CA/Browser Forum / Browser Stores have repeatedly discussed
forbidding it. That is, allowing the HTTP and TLS methods of validation to
only be scoped for the host in question (and potentially the service in
question, if we can work out the safe SRVName transition, due to the
interaction of nameConstraints and policy)

Would it be simpler to remove the statement from the draft, rather than try
to clarify equally valid refers to the technology without commenting on the
policy?

>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

[Ryan Sleevi]

On Thu, Oct 10, 2019 at 5:22 AM Yaron Sheffer  wrote:

> I am wondering though about this sentence: A CA can "also offer additional
> validation methods/issuance flows which also use the "dns-01" method."
> Doesn't specifying "dns-01" restrict the CA to one particular
> validation/authorization flow?
>

No.

There's a gap in the assumption here, which is that the CA MUST support
draft-ietf-acme-caa, which is not specified, and were it specified, runs
into the set of issues covered in
https://tools.ietf.org/html/draft-ietf-acme-caa-10#section-5

However, setting that aside, the dns-01 validation method alone doesn't
restrict the issuance pattern to just being STAR, which is the assertion
"To restrict certificate delegation only to the protocol defined here:"
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Warren Kumari's Discuss on draft-ietf-acme-ip-07: (with DISCUSS and COMMENT)

[Ryan Sleevi]

On Tue, Oct 1, 2019 at 2:28 PM Warren Kumari  wrote:

> > The second scenario you suggest is also something covered by 8555, if
> the attacker is able to fully control the network, then they can control
> ACME. This is not just the case for IP validation, if an attacker is able
> to hijack BGP routes then they are able to complete validation for both IP
> and DNS identifiers (there is currently a handful of both academic and
> industry work happening to try and mitigate these issues) and is also not
> just the case for ACME, any CA that does network based control validation,
> automated or not, is susceptible to these kinds of attacks.
>
> Yup, I've read 8555, but somehow it feels much more scary to have this
> happen for IP addresses than for DNS names -- some of this might just
> be me being triggered by expectations that addressed get reused (e.g
> DHCP), and that e.g someone on the IETF meeting network could iterate
> over all addresses, getting certificates for all of the space...
>
> This still *feels* dangerous to me...
>

What are the things you might be looking for to address the concern here?

The trouble with the scenario you've described basically requires one of
two things:
- Attackers to be proximate on the 'local' network of the validation target
(e.g. ARP poisoning)
- Attackers being able to control or influence routing tables as seen by
the issuing CA (e.g. BGP poisoning)

As Roland mentioned, both of these scenarios are no different than
dNSName-bearing certificates. dNSName suffers from issues such as DNS
spoofing/fragmentation, as we've seen. However, once the DNS has been
translated to an IP by the authoritative server, both scenarios you
describe here - ARP spoofing and BGP poisoning - are just as viable to
asserting possession of the domain name as they are the iPAddress.


It seems that the concern you've expressed here is slightly different than
the one you initially raised on the DISCUSS, and that's a question about
certificate lifetimes, and how long the assertion between a key and a
subjectAltName should be reasonably expected to be valid. The presumption
here is that domain names are "long-lived" in some form (e.g. with their
annual renewal), while iPAddresses are "short-lived" (e.g. due to DHCP
dispatching from pools). Is that a fair expression of the unease you're
expressing?

In practice, I think the concern you're expressing for IP addresses is
actually common for dNSNames too, as discussed on the topic of BygoneSSL (
https://insecure.design ), and that the solutions are largely not in the
validation space, but in defining meaningful and sensible profiles. In this
respect, an ACME method to support such iPAddress-bearing certificates
helps the problem, more than it worsens the problem, by providing coherent
and consistent APIs to facilitate shorter certificate lifetimes and clearer
management of those certificates.

Regardless of the position taken with respect to this draft document, such
certificates exist today, are recognized by major Root Stores, and
meaningfully help improve security of important services (such as DoH/DoT
to the resolver). So, hopefully that suggests it's a net-good to
standardize an approach that might be usable, in future policies, to only
permit such IP-bearing certificates iff constraints are met, such as
reduced lifetimes, automated issuance, etc.

Does that help put you at ease, with respect to this document?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] draft-ietf-acme-star

[Ryan Sleevi]

On Wed, Sep 11, 2019 at 12:09 PM Thomas Fossati 
wrote:

> 2 The pre-dating that the ACME server MUST do on cert rotation to
>   prevent the client to fetch a not-yet-valid credential (i.e., the
>   overlap you mention).
>
> IIUC, you are suggesting to drop the former, i.e., removing the ability
> for a client to request recurrent-certificate-predate, correct?  Or are
> you suggesting to only remove the RECOMMENDED from section 4.1?
>

I'm not Richard, but with respect to publicly trusted certificates, issuing
a certificate with a notBefore set prior to that certificate was issued is
seen as, minimally, problematic, and at times has resulted in a complete
removal of trust in that CA, particularly if/when such actions have lead to
bypasses of technical controls enforced based upon the notBefore.

The clock skew problem is, admittedly, real, and the general solution as
practiced by industry-recognized CAs and Subscribers is to generate the
request and issue the certificate in advance of its actual deployment,
rather than to issue the certificate and then back-date it to facilitate
deployment.

To that end, the language about "amount of pre-dating added to each STAR
certificate" (in 3.1.1) is, as Richard highlighted, about the overlap that
exists.
The language in Section 4.1, however, should be clarified to be clear that
the CA/ACME server MUST NOT set the notBefore to before the request, but
instead about ensuring that the STAR client requests the 'next certificate'
in advance of the actual deployment. This may substantially alter the
protocol, it's unclear, but it's extremely unwise, if not outright fatal to
interoperability, to issue a certificate with a notBefore set prior to the
request, and it seems that is what is meant by Section 4.1.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

[Ryan Sleevi]

On Tue, Aug 27, 2019 at 2:28 AM Yaron Sheffer  wrote:

> The new version contains some significant changes:
>
> - Addition of the STIR use case.
> - Refinement of the CDNI use case.
> - Addition of the CSR template (partial, more work required).
> - Further security considerations (work in progress).
>
> Thanks,
> Yaron
>

I was a bit surprised to not see any references to the Delegated
Credentials for TLS ( https://tools.ietf.org/html/draft-ietf-tls-subcerts )
specification. Is my understanding correct that these are functionally
addressing the same problem?

Introduction:
The introduction introduces the concept of NDC, but then transitions to use
the acronym CDN. Perhaps it would be useful to explicitly specify if you
meant a Content Delivery Network (CDN) to be a Name Delegation Consumer
(NDC), or if perhaps that was just a typo.

Also in the introduction, it states "Understandably, most IdOs balk at
sharing their long-term private keys", but this is difficult to quantify.
It would imply that most sites do not use CDNs, when I suspect the reality
is actually inverted - more sites use CDNs or hosting provider than those
that don't. Perhaps this should be updated to say "some IdOs", or perhaps
quantify as "IdOs may balk", both of which indicate possibilities without
indicating magnitude.

4.1.2 Chained Delegation
The use of the terms uCDN and dCDN are... a bit surprising. Could you
indicate a bit what those letters are meant to specify? My worry is that
the u will be seen as similar to the Greek letter mu - aka the prefix
typically used to indicate micro.

That said, I admit, I'm a bit confused about the protocol design attempting
to accommodate this. The motivation appears to be because "IdO may not even
know about dCDN", but then immediately following, it notes that such
proxying as proposed by the protocol is "governed by policy and contracts
between the parties". It seems that if the intent is to leave it to policy,
such accommodation may not be necessary. Alternative, if the intent is to
explicitly support this, it may be desirable to allow the IdO to express
its policy to the uCDN as to expectations related to the dCDN, rather than
relying upon an out-of-band mechanism.

6.1 Restricting CDNs to the Delegation Mechanism
There are RFC 2119 MUSTs attached here, when it seems these functionally
should be SHOULDs. That is, I think it's fair to highlight the
consideration of concerns between the IdO and the CDN, but I don't think
it's reasonable to normatively specify the policy consideration mechanism.
For example, as specified, those requirements would not be sufficient to
guarantee that a conforming CA uses this mechanism, as a number of CAs
"comply with ACME" (second bullet), but also offer additional validation
methods/issuance flows which also use the "dns-01" method.

As CAA is intentionally flexible to allow for CA-specific policy
identifiers to be expressed between the IdO and the CA, I think it's best
to change these to SHOULD, and to recognize that CAs may devise other means
of technically expressing this conformance, and that's between the IdO and
the CA. CAA provides the necessary component (to allow them to restrict to
CAs that respect CAA, to allow CA-specific policy), but I think that's the
extent to which policy-specific requirements can be made.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi]

On Thu, Apr 25, 2019 at 2:27 AM Ilari Liusvaara 
wrote:

> On Wed, Apr 24, 2019 at 01:48:24PM -0400, Ryan Sleevi wrote:
> > On Wed, Apr 24, 2019 at 1:34 PM Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > > If that's roughly correct, would you agree a possible mitigation
> > > > (notwithstanding complexity concerns) 'could' be the use of a client
> > > hello
> > > > extension, echo'd by the server (thus confirming it understands the
> > > > protocol, and is not merely 'dumb' parsing but an active participant
> in
> > > the
> > > > TLS handshake), that indicates the IP being verified?
> > >
> > > The server must already acknowledge the IP address being verified.
> > >
> >
> > I'm not sure how this conclusion is reached. Could you help me understand
> > more?
>
> The validation certificate contains the IP address being verified
> in the SAN extension.
>
> > > And that mitigation does not work. If the NAT does not know about
> > > TLS-ALPN, it will not know about whatever extension that would be,
> > > and thus just copy it through straight to attacker, who can then
> > > freely reply.
> >
> >
> > I'm not sure why you say this. Your original threat model was that the
> TLS
> > SNI NAT box does something 'sensible' in the absence of SNI - and that
> the
> > attacker would not be able to terminate the handshake if SNI were absent.
> > If the proposal were to omit the SNI, while still making sure it's bound
> to
> > the request (via a separate extension), then as long as the TLS SNI NAT
> box
> > does the sensible thing for an SNI-less request, there's no additional
> > privilege.
>
> What are the consequences if the server just takes that address without
> checking (echoing the extension, with whatever is in it)?
>
> TLS-ALPN with domain names is pretty robust security-wise against
> servers and middleboxes doing wrong (but sensible) things.


I’m still struggling to build up a cohesive threat model for your concerns.
Perhaps you can try writing one up, for folks who haven’t read this thread
- and this might help folks like me who have read this thread.

Where I struggle is that the threats seem to continually shift through each
message, but perhaps  I’m not understanding. For example, a middlebox that
blindly echoes TLS extensions means it is terminating TLS, not merely
dispatching on it. The security model of TLS-ALPN is, as discussed during
that process, fundamentally undermined if the server starts echoing the
ALPN - which is why the ALPN draft warns against it.

I’m trying to understand what “bad but legitimate” behaviors you see,
because I doubt we can, will, or should solve for “bad and violating
existing TLS invariant” behaviours. We should be careful to balance how
many hypotheticals here, as unless we have a concrete threat model, we’re
making protocol authors do unreasonable and undocumented dances.

And in CABForum BRs, fradulent IP address certificate is quite bad, as
> it allows (at least in rules) getting fradulent DNS certificates for
> any domain pointing to that name (due to existence of method 8).


I think that is largely orthogonal to this discussion. There is no need for
a certificate - any “technical control” over the IP is sufficient for that
purpose. If we’re countenancing servers that don’t do something sensible
for SNI-less requests, then that’s already an issue, since CAs also aren’t
required to use TLS-ALPN.

> If the issue is that the TLS SNI NAT box is *only* secure in the context
> of
> > DNS - and maybe it does something sensible absent an SNI, and maybe it's
> > terrible and fundamentally insecure absent an SNI - then what we're
> saying
> > is middleboxes are evil and fundamentally insecure ;)
>
> The reason for distinction between DNS and IP here is because of the
> difference in how TLS-ALPN works with DNS and IP versus how clients
> works with DNS and IP.
>
> Consider TLS-SNI. That difference in behavior renders it insecure
> w.r.t. such middleboxes for both DNS and IP. Yet I do not think anybody
> would blame the middleboxes for this issue, they blame TLS-SNI instead.


I’m still not confident I have a clear understanding of your concerns, and
that’s concerning if only because it sounds like you believe there are
critical, unaddressed security issues with the draft, and it’s unclear how
to move forward or address them. It appears the concerns are shifting in
the messages, but it’s entirely likely I’m missing some metapoint you’re
making.

Do you have suggestions on how to address the issues you see? That might
also help make it clearer.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi]

On Wed, Apr 24, 2019 at 1:34 PM Ilari Liusvaara 
wrote:

> > If that's roughly correct, would you agree a possible mitigation
> > (notwithstanding complexity concerns) 'could' be the use of a client
> hello
> > extension, echo'd by the server (thus confirming it understands the
> > protocol, and is not merely 'dumb' parsing but an active participant in
> the
> > TLS handshake), that indicates the IP being verified?
>
> The server must already acknowledge the IP address being verified.
>

I'm not sure how this conclusion is reached. Could you help me understand
more?


> And that mitigation does not work. If the NAT does not know about
> TLS-ALPN, it will not know about whatever extension that would be,
> and thus just copy it through straight to attacker, who can then
> freely reply.


I'm not sure why you say this. Your original threat model was that the TLS
SNI NAT box does something 'sensible' in the absence of SNI - and that the
attacker would not be able to terminate the handshake if SNI were absent.
If the proposal were to omit the SNI, while still making sure it's bound to
the request (via a separate extension), then as long as the TLS SNI NAT box
does the sensible thing for an SNI-less request, there's no additional
privilege.

If the issue is that the TLS SNI NAT box is *only* secure in the context of
DNS - and maybe it does something sensible absent an SNI, and maybe it's
terrible and fundamentally insecure absent an SNI - then what we're saying
is middleboxes are evil and fundamentally insecure ;)
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi]

On Wed, Apr 24, 2019 at 10:23 AM Ilari Liusvaara 
wrote:

> I am not sure ALPN extension prevents exploitation.
>
>
> Consider TLS SNI NAT (yes, such things exist) with:
>
> - Connections without SNI are handled in some safe way.
> - Loose registration practices (which made TLS-SNI-01/02 insecure)
> - No TLS termination (or customer can disable termination for their
>   name).
> - No support for TLS-ALPN.
>
>
> Now, attacker claims the RDNS name of the IP address of the host
> and sets up TLS-ALPN responder (this fails with DNS-type names).
>
>
> Then attacker requests certificate for the IP address. The NAT then
> sees the SNI, ignores ALPN and sends the connection to the attacker,
> which can then respond with validation certificate. The authorization
> passes and CA issues fradulent certificate.
>
>
> The attack exploits the different SNI in requests client would send
> and what validation uses (TLS-ALPN with DNS names uses the same name,
> so the attack will not work). The attack against TLS-SNI also exploited
> this difference (but could work even if TLS termination could not be
> disabled).
>

Thanks Ilari!

Just to make sure - these are TLS SNI NAT based on inspecting the TLS
handshake, without actually terminating it, right? That is, it's doing the
"middlebox" thing that introduced huge amounts of complexity to deploying
TLS 1.3, and we're wanting to make sure the IP validation similarly works
around it.

The further assumption here is that these products are 'safe by default'
when omitting SNI, but are otherwise ignorant of ALPN and its semantics.

If that's roughly correct, would you agree a possible mitigation
(notwithstanding complexity concerns) 'could' be the use of a client hello
extension, echo'd by the server (thus confirming it understands the
protocol, and is not merely 'dumb' parsing but an active participant in the
TLS handshake), that indicates the IP being verified?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi]

On Tue, Apr 23, 2019 at 10:03 PM Michael Richardson 
wrote:

>
> mcr> I ommited your great explanation of the situation.  *I* think
> that
> mcr> certificates bound to IP addresses are useful for things like
> server
> mcr> management systems (Dell DRACs, HP iLO, IBM RSA..).  As such,
> there are
> mcr> no cloud issues involved.
>
> Ryan Sleevi  wrote:
> > I’m a bit confused by understanding how this bit fits into the
> > discussion.
>
> > Is the concern that the draft-acme-ip would not work for these cases,
> > and/or that the choice and use of TLS-ALPN (or another identifier)
> > would preclude addressing these use cases?
>
> I think your inclusion of TLS-ALPN (which would be new code, vs a few
> extra scripts, I think) makes the solution more complex that it needs to
> be,
> in order to address a use case which I've not been convinced is real.
>

I think I'm still confused, then, as it seems this thread has forked from
what it was originally discussing.

Corey's original question was in the context of including or omitting the
SNI - but it seemed uncontroversial that the protocol itself would continue
to be signaled via the ALPN method. To omit that signaling would be to
fundamentally invite security disaster.

However, it seems that's precisely your concern - that independent of the
SNI inclusion or omission, it would seem there is concern about requiring
the use of ALPN. Is that a correct understanding? If not, it would help if
you might clearly state which parts of the draft you find problematic, as I
am still missing how this ties into the concerns Corey was raising
originally.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi]

On Tue, Apr 23, 2019 at 5:18 PM Michael Richardson 
wrote:

> I ommited your great explanation of the situation.
> *I* think that certificates bound to IP addresses are useful for things
> like
> server management systems (Dell DRACs, HP iLO, IBM RSA..).  As such, there
> are no cloud issues involved.


I’m a bit confused by understanding how this bit fits into the discussion.

Is the concern that the draft-acme-ip would not work for these cases,
and/or that the choice and use of TLS-ALPN (or another identifier) would
preclude addressing these use cases?

It seems that the applicability of the protocol satisfies all of these use
cases, including internal CAs. Have I overlooked a concern with respect to
SNI and ALPN?

>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi]

On Tue, Apr 23, 2019 at 4:28 PM Michael Richardson 
wrote:

> > In a world where IPs were possible to be validated using TLS-ALPN,
> and
> > the information omitted from the request, if evil.example/Customer B
> > can serve a certificate that confirms the response for 10.0.0.2, then
> > they could get a certificate for Customer A's IP.
>
> To do this requires that the cloud provider make a clear decision about
> what
> they are going to do with SNI-less requests above.I feel that the cloud
> provider did something wrong here.


That's a not-unreasonable position to take, generally speaking, but it's
not an invariant that the TLS-ALPN method stated needed to be met. For
example, we 'could' just as well introduce yet-another-ALPN method to
indicate it's being used to validate an IP address, rather than a domain,
and then we can totally omit the IP address (encoded or otherwise) from the
TLS handshake, on the assumption that the Service Provider must be
responsible for determining the authorization scope. The use of a new ALPN
value would be explicit signalling by said Cloud Provider that they're
aware of the semantics and the security properties that need to be observed.

Fundamentally, TLS-SNI had problems because it relied on
implicit/out-of-band state to bind the request to the response (in this
case, the binding between the .acme.invalid namespace and the actual
customer namespace). As a result, the TLS terminator was not able to
dispatch or ACL appropriately. The 'main' contribution of TLS-ALPN was to
make the server explicitly signal support for the method, rather than
implicitly signal. We could have left the SNI domain as .acme.invalid and
still achieved the same security properties - however, moving it to use the
'actual' name, and only dispatch on ALPN, simply made it easier for Cloud
Providers to implement safely and securely.

That same logic applies here - we 'could' use a distinct ALPN method, in
which case, omitting the IP is fine. However, including the IP (albeit,
encoded) makes it easier to reason about, dispatch, and less likely to
result in implementation flaws, and in particular, given that the draft is
reusing the ALPN tag of TLS-ALPN, observes the semantics and security
properties required of servers that 'speak' TLS-ALPN.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi]

On Tue, Apr 23, 2019 at 2:28 PM Michael Richardson 
wrote:

>
> Ryan Sleevi  wrote:
> > The latter only becomes a consideration if multiple IPs are
> terminated
> > at the same TLS layer, and that TLS termination layer doesn't
> consider
> > the destination IP when dispatching certificates. If we were to omit
>
> I am curious to understand the use case for offboard TLS termination by IP
> address.That would seem to involve some kind of layer-3 (destination)
> NAT.
> Given that TLS would forbid SNI being present in that case, how would such
> a
> offboard TLS termination work?
>

Right. I wasn't trying to suggest that such servers intended to be
responding on 'bare' IP addresses, merely that they were capable of doing
so (by virtue of the SNI absence). As commonly configured by a TLS server,
all IPs would merely be dispatched to a common 'default' host
implementation, *unless* the server used some out-of-band signaling method
to determine the 'original' IP.

In the cloud provider model, this might be multiple physical IPs all
dispatched to a same internal system. The internal system ACLs based on
hostname (the original issue with the tls-sni proposal), and thus may not
have ACLs on the 'bare hostname' form. Let's say I have 'good.example'
(Customer A) resolving to 10.0.0.2, 'evil.example' (Customer B) resolving
to 10.0.0.3, and whenever you connect, TLS termination is dispatched to an
internal service on 10.0.0.1.

Now, the system can already dispatched based on hostname, ensuring that
good.example sessions are served Customer A's response, and evil.example
sessions are served Customer B's response. The issue is whose response is
served when there is no SNI? Under a TLS-ALPN (no-ip) model, there's no
restrictions or requirements there; you could serve Customer A, customer B,
or neither - and none would undermine the security of TLS-ALPN (as a
validation method) or of the security properties you're trying for.

In a world where IPs were possible to be validated using TLS-ALPN, and the
information omitted from the request, if evil.example/Customer B can serve
a certificate that confirms the response for 10.0.0.2, then they could get
a certificate for Customer A's IP.

In a world where we include the to-be-validated IP in the request, and the
Cloud Provider is observing the security invariants required for TLS-ALPN
(that any hostnames to be validated have been successfully authenticated as
belonging to the customer in question), then Customer B would have to
demonstrate control, to the provider, over 2.0.0.10.in-addr.arpa in order
to get such a certificate.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi]

Good points!

I can't speak for the draft authors here, but my understanding and
expectation was, in part in response to the concerns with tls-sni mitigated
by tls-alpn, to ensure there's a strong binding from the request to the
response, and that the binding is unambiguous.

What I mean by that is that in the case of tls-sni, there wasn't a strong
binding between the host name of the challenge certificate and the host
name that the certificate would be issued for (the .invalid problem).
TLS-ALPN resolves this by introducing the ALPN identifier as the protocol
signal, and thus ensures a strong binding between the SNI name and the
final certificate - ensuring it's unambiguous as to what host name will be
challenged for.

As you note, TLS prohibits the use of the IP address in SNI, and thus makes
it difficult to have a strong binding between the name that the certificate
will be issued for and the challenge certificate. This leaves two options:
introduce an alternative way to encode the challenged-for IP in the request
(which the draft does) or omit it entirely (as I believe you're proposing).
If we go with the former approach, encoding it in the request, than servers
that are dispatching the request can ensure that it's only dispatched to
the entity responsible for the IP address encoded. If we go with the latter
approach, then servers would need to ensure that the SNI-less responses can
only be provided on the particular party authorized for that IP address.

The latter only becomes a consideration if multiple IPs are terminated at
the same TLS layer, and that TLS termination layer doesn't consider the
destination IP when dispatching certificates. If we were to omit the
binding, it'd likely be worthy of a security consideration to specify
guidance as to how to do so safely / considerations that should be done
before enabling TLS-ALPN in the context of IP. Alternatively, if we assume
they took the necessary steps for TLS-ALPN, then encoding the domain in the
SNI allows the existing dispatch protection mechanisms to work will
continue to work.

That's, at least, how I've viewed it :)

On Mon, Apr 22, 2019 at 9:21 PM Corey Bonnell  wrote:

> Hi Ryan,
> I suppose I should have framed my email a bit more generally as opposed to
> focusing specifically on the security aspects. More broadly, I'm having a
> hard time coming up with a reason why the SNI extension must be included at
> all for IP address challenges. In the normal TLS connection flow, a
> connection by direct IP address (not hostname) would not include the SNI
> extension at all, so mandating the use of the .arpa domain in the SNI is
> inconsistent with normal TLS processing. This inconsistency is compounded
> when you consider that the self-signed cert for the challenge encodes the
> IP address as an iPAddress SAN (and not the .arpa dNSName). I could also
> see someone being confused upon reading the spec and thinking that a DNS
> A/ record lookup against the in-addr/ipv6.arpa domain must be performed
> and that the challenge TLS connection is to be done against the resolved IP
> address.
>
> I believe it would be more consistent with normal TLS processing and less
> confusing to prohibit the use of SNI altogether for IP address validations.
> However, I'd greatly appreciate any explanations as to why it is preferable
> to include the SNI extension.
>
> Thanks,
> Corey
>
> --
> *From:* Ryan Sleevi 
> *Sent:* Wednesday, April 17, 2019 1:05 AM
> *To:* Corey Bonnell
> *Cc:* acme@ietf.org
> *Subject:* Re: [Acme] SNI extension for tls-alpn-01 challenge in
> draft-ietf-acme-ip-05
>
>
>
> On Tue, Apr 16, 2019 at 9:55 PM Corey Bonnell 
> wrote:
>
> Hello,
>
> Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge, an
> SNI value with the in-addr/ipv6.arpa domain name corresponding to the
> iPAddress being validated MUST be specified. I have a concern that this
> requirement suffers the same problem that rendered tls-sni-01 insecure:
> namely, an arbitrary user on a shared hosting provider could upload an
> arbitrary certificate for the required .ip-addr/ipv6.arpa domain, thus
> circumventing any security provided by the mandatory SNI extension.
>
> The mandatory ALPN extension prevents this from being exploited to obtain
> fraudulent certificates, but given how trivially the SNI requirement can be
> defeated in the same manner as for tls-sni-01, I don’t believe that
> requiring SNI provides any security value and is not necessary. If the
> intent for requiring the SNI extension is to convey to the TLS server that
> an IP address is being validated, couldn’t that similarly be accomplished
> by *not* specifying any SNI extension at all? Tls-apln-01 (for dNSNames)
> requires that a SNI va

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi]

On Tue, Apr 16, 2019 at 9:55 PM Corey Bonnell  wrote:

> Hello,
>
> Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge, an
> SNI value with the in-addr/ipv6.arpa domain name corresponding to the
> iPAddress being validated MUST be specified. I have a concern that this
> requirement suffers the same problem that rendered tls-sni-01 insecure:
> namely, an arbitrary user on a shared hosting provider could upload an
> arbitrary certificate for the required .ip-addr/ipv6.arpa domain, thus
> circumventing any security provided by the mandatory SNI extension.
>
> The mandatory ALPN extension prevents this from being exploited to obtain
> fraudulent certificates, but given how trivially the SNI requirement can be
> defeated in the same manner as for tls-sni-01, I don’t believe that
> requiring SNI provides any security value and is not necessary. If the
> intent for requiring the SNI extension is to convey to the TLS server that
> an IP address is being validated, couldn’t that similarly be accomplished
> by *not* specifying any SNI extension at all? Tls-apln-01 (for dNSNames)
> requires that a SNI value be specified, so TLS servers could differentiate
> between challenge requests for dNSNames and iPAddress based on the presence
> (or absence) of the SNI extension.
>

I’m not sure I follow the attack scenario you’re describing.. The value
proposition of the ALPN method is that it’s indicative that the server does
not “suffer the same problem that rendered sni-01 insecure”, precisely
because it does not allow an arbitrary user to upload an arbitrary
certificate while also responding with that ALPN identifier.

Perhaps I misunderstood your question, but with the above invariant being
the reason for the introduction of the ALPN method, if we assume it holds,
do you still have concerns?

>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-00.txt

[Ryan Sleevi]

On Tue, Jan 15, 2019 at 1:58 PM Rifaat Shekh-Yusef 
wrote:

> The proposed mechanism does not suggest the CA perform a domain validation
> based on
> an attestation from the Device Authority.
> Instead, the Client that already has an account with the ACME server and
> proved that it has control
> over the domain, is asking for a certificate to be issued to a specific
> device with their domain.
>

I had the same reading and reaction as Ilari when I first read it.

Specifically, from reading Section 2.2, I found that a bit confusing, as it
reads:

   For example, if vendor.com is configured as a trusted entity on ACME
   server, and if a device from vendor.com is being deployed by a
   customer.com, and customer.com requires the device to obtain an ACME
   certificate, this mechanism allows the automatic issuance of
   certificates to the device with the customer.com identifier based on
   attestation from vendor.com.

This seems to suggest some delegated form of domain validation; if that's
not intended, then this is probably a problematic description of the use
case.

This seems similarly supported based on 2.3, namely:

   This architecture assumes a trust relationship between the ACME CA
   and the Third-Party Device Authority, which means that the ACME CA is
   willing to accept the attestation of the Third-Party Device Authority
   for particular types of identifiers as sufficient proof to issue a
   certificate.

>From reading through your protocol flow in Section 2.4 and Section 7, it
appears the use case is for ACME CA to allow Client to attest a non-domain
identity (in this case, "identifier={mac}"), in addition to the domain
name. Rather than ACME CA directly validating the "identifier={mac}", it
relies on an apriori trust relationship with Device Authority, and Client
demonstrates their control/ability by the use of JWT via Device Authority.

Is that an accurate read?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME DV Security Considerations Draft

[Ryan Sleevi]

On Sun, Oct 21, 2018 at 6:48 PM Benjamin Kaduk  wrote:

> On Sun, Oct 21, 2018 at 05:25:40PM +, Salz, Rich wrote:
> >   *   It does not seem to be related to ACME - that is, what you’re
> describing is more broadly a set of concerns with the methods that may be
> used to validate a domain.
> >
> > Perhaps ACME isn’t the right place for this, perhaps it should be
> reviewed by SecDispatch, or whatever the DNS equivalent is, or coordinated
> between the two area AD’s.
>
> Since there are proposed solutions in here, secdispatch would seem like a
> fine place (and the latest agenda I saw for them had some slots free,
> still).  There might also be a place for a more open-ended discussion of
> problems with DV in SAAG, if someone were to volunteer to prepare some
> slides and structure the discussion.
>

Thanks. I agree secdispatch is probably a better place for this. The
CA/Browser Forum's Validation WG attempted to perform a similar analysis
during it's F2F in Herdon, VA, as captured ever so briefly in
https://cabforum.org/2018/03/08/final-minutes-for-ca-browser-forum-f2f-meeting-herndon-va-7-8-march-2018/
.. This was the first (and only) meeting in which the Forum Chair extended
blanket invitations for experts to participate, and while well-attended, is
nowhere near the open participation model that the IETF represents. Work on
attempting to resolve some of the security concerns is captured in
http://cabforum.org/pipermail/validation , although the limited
participation (largely of CAs) prevents a lot of the thorough analysis this
work represents, and having a broader participation such as through
secdispatch is better for the ecosystem as a whole.

One minor pedantic quibble, however, is that I think the discussion would
be better served by not speaking of it as ACME or DV. The notion of
"DV/OV/EV" is an arbitrary marketing distinction with no security value -
all certificate types rely on the same procedures for validating an
assertion of control (organizational or operational) over a domain name.
Indeed, in many cases, forms of certificates such as OV/EV have been
demonstrated to be significantly weaker in practice - for example, that the
organization name in WHOIS (i.e. "Google, Inc") matches an incorporated
institution somewhere named the same - without any further validation about
which "Google, Inc" is being referred to, soft-matches such as "Google,
LLC", or even relationships such as "There's a Google LLC as a subsidiary
of Alphabet, and this company's name is Alphabets, so that's probably OK".

By speaking more generally of the challenges of validating a domain, we
allow speaking with precision without the distinction of marketing or
branding, and addressing the underlying security issues more directly.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME DV Security Considerations Draft

[Ryan Sleevi]

Thanks for posting this.

It does not seem to be related to ACME - that is, what you’re describing is
more broadly a set of concerns with the methods that may be used to
validate a domain. For example, ACME is a strict, well-defined subset of
that which permitted by the CA/Browser Forum’s Baseline Requirements. By
focusing only on ACME, it seems like it leaves significantly greater risk
that other CAs will fail to adopt mitigation’s.

That said, I do have to disagree with the very premise of High Risk
Domains. That’s a sort of discussion without data, especially since EV does
not meaningfully provide any security benefit to domain validation. As that
seems to mix personal opinions with otherwise well founded recommendations,
could you speak to why you believe there’s any value in those approaches?

On Sun, Oct 21, 2018 at 6:38 PM Tobias Fiebig  wrote:

> Dear all,
> At the IETF in Montreal, I presented findings on security issues with
> domain validation in ACME, and were encouraged to write a short draft
> outlining attacks and possible defenses. We now created a first draft,
> which outlines the general structure and contents we are aiming for, see
> https://datatracker.ietf.org/doc/draft-fiebig-acme-esecacme. We are
> looking forward to your input on our plans.
>
> Met vriendelijke groet,
>
> Dr.-Ing. Tobias Fiebig,
> Assistant Professor / Universitair Docent
> Department Engineering Systems and Services
>
> Informatie- en Communicatie Technologie (ICT)
>
> TU Delft / Dept. ESS
> Faculty of Technology, Policy and Management (TBM)
> Building 31
> Jaffalaan 5 - room B3.170
> 2628 BX  Delft
> P.O.Box 5015
> 2600 GA Delft, The Netherlands
> T +31 (0)15 27 85700
> E  t.fie...@tudelft.nl
>
> Present: Monday t/m Friday
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] HTTP redirects in validation [Was: Re: FW: Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)]

[Ryan Sleevi]

On Thu, Aug 30, 2018 at 2:28 PM Ilari Liusvaara 
wrote:

> > The main reason to allow redirects within a domain is if there is a
> > unilateral redirect from example.com to www.example.com
> >  , which is of course incredibly common.  It
> > seems one should be able to validate example.com using that redirect.
>
> I have no data on potentially exploitable redirects on-domain versus
> off-domain, but I can say that even some http://foo.example to
> https://foo.example redirects are exploitable (especially with
> substring matching, but sometimes even without that).
>
> The following two types of redirects seem practicularly troublesome:
>
> - Redirect is from above validation directory (usually via global
>   redirect of any resource on name). http:// to https:// redirects
>   and redirects from example.com to www.example.com are usually of
>   this kind. In contrast, redirects specific to validation directory
>   are very probably secure.
> - Redirects that are not injective (multiple source URLs map to the
>   same target URL.). These are invariably from above validation
>   directory redirects.
>
> Then I saw somebody argue that redirecting .well-known globally
> is misconfiguration. And indeed, that place is grab-bag of different
> things, some of which prohibit redirects, some which leave things
> implicit and some that explicitly follow redirects.
>

I'm not sure why either of these are particularly troublesome, given the
requirements, and giving the use of either the Random Value (which must be
random) or it being bound to the request.

Is the issue here one of redirects, or the (as practiced by CAs)
distinction between "the presence of" versus "the contents shall be".

That is, if the CA/Browser Forum required that the contents be explicit
(and/or with a mime-type requirement), does that resolve the matter with
redirects? (I ask, because that's one of the already identified structural
weaknesses of 3.2.2.4.6)
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] tls-alpn-01 spec: TLS-SNI history

[Ryan Sleevi]

On Thu, Jun 21, 2018 at 1:40 PM, Tim Hollebeek 
wrote:

> So the disagreement is whether the it is sufficient to merely use the name
> for the
>
> DNS lookup, and then accept whatever happens afterwards, or whether the
> intent
>
> was that the web page should be retrieved in much the same way as it is
> retrieved by
>
> browsers.  Matching them as closely as possible makes the validation more
> reliable.
>

I think TLS-ALPN documents why this is true, but we know multiple CAs that
implemented either TLS-SNI or alternatives viewed it the same at the time.
I am greatly appreciative of hindsight being 20/20, but I think it's
important to recall that it is hindsight. As part of the introduction of
3.2.2.4.10, CAs were actively discussing about how this avoids the need to
do such matches, and the CA/Browser Forum Validation WG acknowledged it as
a correct interpretation. This is not about strict interpretations - this
is about documented and uncontested discussion in the Validation WG.

However, as to the remainder of the message, it seems we're echoing each
other - that a well-specified TLS-ALPN that concretely documents the
processing mode is of great benefit to the community, both in terms of
client implementers knowing what edge cases to expect that may cause an
ACME server to reject their response, and ACME servers to consider in
implementing when considering the validation level of the client's request.
My hope, then, is that any energy that might be directed at trying to
duplicate this work in 3.2.2.4.10 in the CA/Browser Forum might otherwise
be more productively and holistically directed at this effort within the
IETF and TLS-ALPN, allowing both broader participation and review, and
resulting in a state such that 3.2.2.4.10 can simply be replaced,
wholesale, with a statement "Using TLS-ALPN as specified is acceptable".


> Unfortunately, historically, the requirements are underspecified, and
> there is freedom
>
> to implement the validation mechanism badly.  There are improvements
>
> that were discussed in the excellent discussion in Virginia, but even
> today, we
>
> aren’t there yet.  So yes, it is possible by using a very strict,
> technical reading,
>
> an argument can be made that TLS-SNI is compliant.
>


>
>
> I’m just not a fan of that argument.  When the BRs say “retrieve a […] web
> page”, I
>
> believe that includes a responsibility to interpret that provision in a
> way that meets
>
> the intent of the validation method, and doesn’t introduce security risks.
>
>
>
> -Tim
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] tls-alpn-01 spec: TLS-SNI history

[Ryan Sleevi]

On Thu, Jun 21, 2018 at 8:40 AM, Tim Hollebeek 
wrote:

>
> > TLS-ALPN addresses the latter problem by requiring the server_name to
> match
> > the validation target (which is AFACIT also required by the Baseline
> > Requirements). This stops claiming arbitary names from allowing
> > misvalidations.
>
> This was certainly the intent.  Never in over two years of some pretty
> detailed discussions about the mechanics of validation did anyone ever
> propose it was reasonable to validate domain name A by contacting
> the web server for a name that is not A (except for the approved the
> _prefix
> stuff).
>

That's not what is done under TLS-SNI.


> I realize that after it was pointed out that TLS-SNI was horribly broken
> in this regard, there were attempts by some to retroactively claim that
> such behavior was compliant, but I always found those explanations a
> bit tortured and unconvincing.  Certainly if I a large commercial CA had
> made them, they would have been laughed at and ridiculed.
>

Considering that large commercial CAs similarly interpreted the language as
described, I don't think this claim is well-supported. At the time of
TLS-SNI, it was seen as acceptable practice, and indeed, judging by the
minutes, CAs that similarly interpreted it as such were actively
participating in the validation WG and explicitly suggesting equivalent
solutions.


> I would actually love to work with some people on updating the CABF
> method 10 validation requirements in order to properly express the
> security requirements that ALPN-01 satisfies.  The whole TLS-SNI
> experience showed that Method 10 does not have sufficiently rigorous
> requirements to guarantee it actually validates what it claims to validate.
> Since the CABF VWG is currently working on adding more security rigor
> to all the approved validation methods, it would be a great time to fix
> up Method 10.
>
> ALPN-01 is a much better validation method, and I'm very thankful
> to all the people who worked hard to come up with a replacement,
> which as far as I can tell from looking at it briefly (I wish I had more
> time)
> looks pretty secure and robust.
>

I think it's good for CAs to look at improving validation requirements. I
think an easier way, however, than that attempt to describe prosaically
what TLS-ALPN expresses from guarantees is a simple and explicit
requirement to use TLS-ALPN. To that end, the question for TLS-ALPN spec is
whether it sufficiently expresses the expectations for where things go
right - and the handling mode for errors along the way. Thus, if there is
any time or energy for fixing Method 10, it seems that diverting it to
TLS-ALPN and ensuring it's well-specified in terms of failure handling and
expectations is the best way to achieve that laudable goal.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

[Ryan Sleevi]

On Thu, Jun 21, 2018 at 8:30 AM, Tim Hollebeek 
wrote:

> The current ABNF in 6844 is basically broken, and doesn’t express what it
> was intended to express.  I remember staring at it with Corey and wondering
> how it got approved …
>

>
> So while I’m not particularly picky on the exact bureaucratic details of
> how a fix gets made, it would be nice to get this resolved quickly via an
> errata or whatever.  There are a bunch of reasonable extensions to CAA that
> could be made in the future, and a solid and agreed-upon grammar is a
> necessary prerequisite.
>
>
>
> Another option (at least for uses on the Web PKI) is clarification by CABF
> ballot.  Despite all the downsides of CABF, it does have the ability to
> move pretty quickly when it needs to.
>
>
>
> -Tim
>

I would like to focus on resolving the issues with the document, as
written, as it specifies a grammar not conformant with 6844.

I disagree with your assessments about intent, brokenness, or possible
solutions for 6844 - but those are all better for LAMPS to work out, and we
can have that reasonable debate there. I hope, though, we're in agreement
that conforming implementations of 6844 cannot and should not process these
records, and as Ivan calls out, runs real operational risk to users that
rely on them. Let's fix that, now, and worry about whether or not we can
break compatibility in a -bis document and whether it's worth it.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

[Ryan Sleevi]

On Wed, Jun 20, 2018 at 4:47 PM, Roland Shoemaker 
wrote:

> As previously discussed on the list the two property names defined in
> draft-ietf-acme-caa, "validation-methods” and "account-uri”, do not conform
> to the ABNF syntax in RFC 6844 as they contain hyphens. 6844-bis fixes this
> by expanding the ABNF to be less restrictive but for now this doesn’t
> really address the problem at hand.
>
> Given it is probably unlikely that 6844-bis will be standardized any time
> soon is there any plan to make changes to draft-ietf-acme-caa to address
> this in the short term? Given we are not yet at the point where there is
> wide deployment/adoption of this feature can we take the easy route and
> simply remove the hyphens so that the document at least complies with the
> existing CAA document?
>

It is not just that -bis would need to be finalized and standardized, but
that CAs would also have to adopt and recognize the syntax in -bis,
updating their 6844 implementations. Even if -bis were final tomorrow, that
would still take considerable time, given the normative differences, and so
I think aligning on an inter-operable expression is certainly preferable,
allowing it to work with both 6844 and -bis.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] tls-alpn-01 spec: TLS-SNI history

[Ryan Sleevi]

On Wed, Jun 20, 2018 at 5:34 AM, Ilari Liusvaara 
wrote:
>
> My understanding was that catastrophic problem was not the default-
> vhost behavior of Apache or Nginx, altough that could casue security
> issues. But instead, the problem was  that many hosting provoders let
> one claim arbitrary hostnames on FCFS basis. This let attacker upload
> arbitrary validation certificates to be served, and due to how TLS-SNI
> worked, this lead to misvalidation.
>

This is correct, although it was not necessarily dependent on FCFS
behaviour - the issue would still exist because there was no implicit or
explicit binding between the ACME challenge name and the name being
validated in the protocol. That, combined with service providers reliance
on DNS to resolve conflicts, lead to these issues.

I'm not aware of any of the issues that were responsibly disclosed to
browser vendors having been related to Apache configuration.


> TLS-ALPN addresses the latter problem by requiring the server_name to
> match the validation target (which is AFACIT also required by the
> Baseline Requirements). This stops claiming arbitary names from
> allowing misvalidations.
>

Note: The Baseline Requirements do not require this.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Ryan Sleevi]

On Fri, May 25, 2018 at 12:08 PM, Eric Rescorla  wrote:
>
> > > IMPORTANT
> > > S 6.2.
> > > > algorithm in its "alg" field
> > > >
> > > >  o  The JWS Payload MUST NOT be detached
> > > >  o  The JWS Protected Header MUST include the following fields:
> > > >
> > > > *  "alg" (Algorithm)
> > >
> > > Do you want to specify a set of acceptable signature algorithms here?
> >
> > I am inclined not to.  We have already forbidden "none" and MAC.  We
> > shouldn't specify "MUST"s here, because CABF sets their own list of
> > required algorithms, and we don't want to conflict.  I guess you
> > could specify some MUST NOTs pretty safely, but given that they're
> > already forbidden by CABF, it seems kind of duplicative.
>
> This is about the signatures that ACME accepts, not the signatures
> in certs. Does CABF have a position on what signature algorithms
> that ACME uses?
>

The Baseline Requirements do not establish any policies here regarding
proof of key possession (which is not required, strictly speaking) or
domain name validation methods, or on the authentication channel between
the Applicant and CA.

For example, 3.2.2.4.6 of the BRs (at time of writing,
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.7-29-Apr-2018.pdf
) allow the use of MD2 or MD4 as part of their request token construction
or within the use of CSRs.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ALPN based TLS challenge

[Ryan Sleevi]

On Mon, Feb 26, 2018 at 3:33 PM, Doug Beattie 
wrote:

>
>
> I would find it a bit surprising if the CABF adopted a domain validation
> method that relied on the web hosting provider claiming to do the right
> thing (to separate users on shared IP addresses so they cannot request
> certs from the other customers on that IP address).
>

I'm surprised that it's seen as surprising, as this is already the implicit
assumption for the validation methods within the CA/Browser Forum's
Baseline Requirements.

Notable among the comparisons would be to 3.2.2.4.4, which makes a
presumption that the email provider for the domain has not only observed
RFC 2142 Section 5, but also the CA/Browser Forum specific aliases of
"admin" and "administrator"

Alternatively, one might consider the comparison to 3.2.2.4.6, in which the
presumption is made that the /.well-known/ path is restricted from general
access. Section 8.3 of ACME (
https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.3 )
specifically encourages the following of redirects when dereferencing the
/.well-known/, but this understandably opens up attacks should a blanket
redirect be used.

That said, I do think the artificial distinction between "web hosting
provider" may be detrimental. Given the existing of the CA/Browser Forum's
3.2.2.4.8, one can equally see an attack made under such shared-hosting
scenarios by any CA that utilizes the .8 methods of validation, in that
multiple tenants on that IP would have access to respond for that IP (under
3.2.2.5)


> Has anyone discussed this with the CABF?  I’d recommend that someone send
> this out to the public list for feedback.
>

Considering that the method described is consistent with 3.2.2.4.10 in the
Baseline Requirements, did you mean to suggest conversations with Root
Store programs that might otherwise restrict the usage of methods beyond
that of the Baseline Requirements, such as forbidding 3.2.2.4.1, .5, .9 and
.10 without specific mitigations?

As one such Root Store operator, we're happy to see this method progress
within the IETF, and believe it provides suitable mitigations for the
issues disclosed. In retrospect, the introduction of the TLS-SNI method as
specified in https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.4
, is functionally no different than introducing a new e-mail alias in the
3.2.2.4.4 method of validation - that is, presuming that all at-risk
domains (such as those that allow arbitrary e-mail registration) must now
take steps to block. The proposed method provides an opt-in, rather than an
opt-out, and thus provides suitable mitigation.

Much like a domain holder could choose a hosting provider that permits
arbitrary modification to /.well-known/ or arbitrary DNS modification, I do
not believe this introduces any additional security holes compared to the
presently-industry-accepted methods of validating domain control.


>
>
> Doug
>
>
>
> *From:* Acme [mailto:acme-boun...@ietf.org] *On Behalf Of *Daniel McCarney
> *Sent:* Monday, February 26, 2018 2:14 PM
> *Cc:* IETF ACME 
> *Subject:* Re: [Acme] ALPN based TLS challenge
>
>
>
> +1
>
> The WG should adopt this document. I will volunteer to help review if
> adopted.
>
>
>
>
>
> On Mon, Feb 26, 2018 at 12:02 PM, Richard Barnes  wrote:
>
> +1
>
>
>
> This approach is a major improvement from earlier efforts at a TLS-based
> challenge.  It follows normal TLS processing logic much more closely,
> differing only in the fact that the certificate presented has an extra
> extension.  Minimizing the differences w.r.t. normal behavior seems like a
> good approach to avoiding the sorts of corner cases that have tripped up
> earlier flavors of TLS-based challenges.
>
>
>
> Before this is finalized as an RFC, we should verify empirically that most
> hosting providers will be secure in the presence of this challenge.  But
> I'm convinced that the approach in Roland's document is likely enough to
> work that we should go ahead and develop a specification, which we can test
> as it matures.
>
>
>
> --Richard
>
>
>
>
>
> On Fri, Feb 23, 2018 at 11:41 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>
>
> On 23/02/18 16:31, Salz, Rich wrote:
> >
> >> Here is the ID:
> >> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/
> >
> > Should the WG adopt this document?
>
> Yes.
>
> Having a sufficiently secure mechanism that works on port 443 is
> a good thing in general. I'm not sure how many folks were using
> tls-sni-01 for new domains (I was) but whatever that number was,
> is I think evidence that a port 443 scheme fills a read need.
>
> I assume that if problems are found with the new mechanism
> (whether those be technical, due to odd deployments or I guess
> even cabforum politics;-) then we'd recognise that and stop
> the work. The fact that we did that to tls-sni-02 hould be
> re-assuring wrt this.
>
> If one accepts the two assertions above then adoption seems
> like a no-brainer.
>
> S.
>
>
> > Speak up