Re: [Acme] Allowing clients to understand the account creation functionality supported by a server

[Josh Soref]

>From my perspective, the UX from not having this feature is pretty awful.
And for clients to try to make the UX not awful, they'd have to add quite a
bit of complexity.

I'd much rather a must with a bit of extra information in the meta
directory.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?

[Dr. Pala]

Hi Ilari, all,

I strongly disagree with your statement. From a crypto standpoint, key 
rotation IS an important point and should be addressed. I think 
something could/should be added to the I-D to limit the number of 
renewal or the period where the same CSR can be used for certificate 
re-issuing.


The solution might be as simple as set a validity in the CSR that is 
generated (if you want that to be in control of the requesting client). 
I am not suggesting the specifics of how to solve it, but I think that 
this is a point that should be addressed (possibly something that was in 
the mind of the original authors, but did not make it in the document... 
?).


What is the position of the I-D authors ?

Just my 2 cents, of course :D

Cheers,
Max


On 3/30/17 2:06 PM, Ilari Liusvaara wrote:

On Thu, Mar 30, 2017 at 12:26:17PM -0500, Dr. Pala wrote:

I have a small question about the I-D. In particular, it seems to me that
this proposal circumvents any limitation on the effective lifetime of a
short-lived-cert's keypair. From a cryptographic standpoint of view, it is
good practice to impose strict lifetimes on keys (i.e., usually via validity
periods in certificates) to limit the issue of successful attacks on the
crypto scheme (e.g., key factorization). This proposal would de-facto remove
this property by adopting re-issuing instead of re-keying when renewing a
certificate.

I do not think that limiting key lifetime is necressarily a good idea.

Usually, when you discover that your key is compromised (using the
WebPKI definition), the attackers have been in position to compromise
your keys for who knows how long. If you rotated keys, all (or at least
a long list) the past keys are considered compromised too.

The threat of using stolen keypairs to decrypt sessions is exactly
what PFS is meant to defend against.

There's also key rollovers for parameter updates, but those are quite
rare, and are not emergency rollovers. There are already parameters
where the time that happens is either: 1) Major cryptographical break-
through, or 2) Large quantum computers are invented.


So, I don't think CA should do anything with key lifetimes (outside
obvious indications that key is not good, like revocation with
KeyCompromise).



-Ilari

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


--
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca

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

Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?

[Ilari Liusvaara]

On Thu, Mar 30, 2017 at 12:26:17PM -0500, Dr. Pala wrote:
> 
> I have a small question about the I-D. In particular, it seems to me that
> this proposal circumvents any limitation on the effective lifetime of a
> short-lived-cert's keypair. From a cryptographic standpoint of view, it is
> good practice to impose strict lifetimes on keys (i.e., usually via validity
> periods in certificates) to limit the issue of successful attacks on the
> crypto scheme (e.g., key factorization). This proposal would de-facto remove
> this property by adopting re-issuing instead of re-keying when renewing a
> certificate.

I do not think that limiting key lifetime is necressarily a good idea.

Usually, when you discover that your key is compromised (using the
WebPKI definition), the attackers have been in position to compromise
your keys for who knows how long. If you rotated keys, all (or at least
a long list) the past keys are considered compromised too.

The threat of using stolen keypairs to decrypt sessions is exactly
what PFS is meant to defend against.

There's also key rollovers for parameter updates, but those are quite
rare, and are not emergency rollovers. There are already parameters
where the time that happens is either: 1) Major cryptographical break-
through, or 2) Large quantum computers are invented.


So, I don't think CA should do anything with key lifetimes (outside
obvious indications that key is not good, like revocation with
KeyCompromise).



-Ilari

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

Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?

[Max]

Hi Eric,

I am not saying it is the CA job (although, good CAs will impose max 
life-times on keys), but it seems to me that this issue should be 
addressed since it would violate one of the basic security principles 
when it comes to crypto, i.e. key lifetime. Maybe adding something to 
this regard could be useful so that "TLS operators" and CDN operators do 
not shoot themselves in the foot :D


Cheers,
Max


On 3/30/17 12:53 PM, Eric Rescorla wrote:

I don't think it's the CA's job to dictate policy in this area.

-Ekr


On Thu, Mar 30, 2017 at 12:26 PM, Dr. Pala > wrote:


Hi all,

I have a small question about the I-D. In particular, it seems to
me that this proposal circumvents any limitation on the effective
lifetime of a short-lived-cert's keypair. From a cryptographic
standpoint of view, it is good practice to impose strict lifetimes
on keys (i.e., usually via validity periods in certificates) to
limit the issue of successful attacks on the crypto scheme (e.g.,
key factorization). This proposal would de-facto remove this
property by adopting re-issuing instead of re-keying when renewing
a certificate.

Although the CA might be able to track the usage of a key from the
initial CSRs, the automatic issuance of the certificate itself
without the constraints of the key longevity seems quite dangerous
and possibly open to a policy of "set-and-forget" that might last
for... years... (automatically not re-issuing the certificate
based on key-size + CSR timestamp would, I think, create issues
for CDNs as there would be no indication when a new LURK/CSR cycle
is needed).

Am I reading it wrong / missing something ?

Cheers,
Max

-- 
Massimiliano Pala, PhD

Director at OpenCA Labs
twitter: @openca

___
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


--
Massimiliano Pala
Director at OpenCA Labs
twitter: @_mpala_

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

Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?

[Eric Rescorla]

I don't think it's the CA's job to dictate policy in this area.

-Ekr


On Thu, Mar 30, 2017 at 12:26 PM, Dr. Pala  wrote:

> Hi all,
>
> I have a small question about the I-D. In particular, it seems to me that
> this proposal circumvents any limitation on the effective lifetime of a
> short-lived-cert's keypair. From a cryptographic standpoint of view, it is
> good practice to impose strict lifetimes on keys (i.e., usually via
> validity periods in certificates) to limit the issue of successful attacks
> on the crypto scheme (e.g., key factorization). This proposal would
> de-facto remove this property by adopting re-issuing instead of re-keying
> when renewing a certificate.
>
> Although the CA might be able to track the usage of a key from the initial
> CSRs, the automatic issuance of the certificate itself without the
> constraints of the key longevity seems quite dangerous and possibly open to
> a policy of "set-and-forget" that might last for... years... (automatically
> not re-issuing the certificate based on key-size + CSR timestamp would, I
> think, create issues for CDNs as there would be no indication when a new
> LURK/CSR cycle is needed).
>
> Am I reading it wrong / missing something ?
>
> Cheers,
> Max
>
> --
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca
>
> ___
> 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] Generating nonces probabilistically in 6.4.1. Replay-Nonce

[Eric Rescorla]

As the veteran of many arguments about pseudorandomness and uniqueness, I
think
it's reasonable to consider a sufficiently long random string to be unique.

"high probability" actually makes it worse, because 99.99 is actually a
very high
probability but not really a security boundary. If you want to provide more
guidance,
I would suggest instead giving a minimum length for the random string.

-Ekr


On Tue, Mar 28, 2017 at 7:16 AM, Alan Doherty  wrote:

> At 11:46 28/03/2017  Tuesday, Martin Thomson wrote:
> >I agree with Jacob here.  MUST seems appropriate, but requiring
> >uniqueness absolutely imposes a constraint on server design that is so
> >onerous that I would see it as impractical.  (Also, the document
> >doesn't really identify a scope for this uniqueness, which would
> >probably be necessary if you had to avoid random generation.)
>
>
> i think given a large enough set of transactions unique is impossible (and
> guaranteeing a previous use in identical circumstances impossible, unlikely
> but not guaranteeing)
> thus as its impossible mathematically (unless using sequential numbers of
> infinite length)
>
> its better to keep 'high probability' as the possibility of random
> generating a sequence twice is always there, if its truly random
> improbable can be done, impossible is infinitely more work (as would
> require keeping all previous and negative matching an ever growing list
> before use)
>
>
>
> >On 27 March 2017 at 16:46, Jacob Hoffman-Andrews  wrote:
> >> Forwarding on behalf of Erica Portnoy.
> >>
> >> I agree, the uniqueness should be a MUST, but I think "high probability"
> >> should stay so random generation of nonces is acceptable. PR:
> >> https://github.com/ietf-wg-acme/acme/pull/289
> >>
> >>
> >>  Forwarded Message 
> >> Subject:Generating nonces probabilistically in 6.4.1.
> Replay-Nonce
> >> Resent-Date:Fri, 24 Mar 2017 18:19:35 -0700 (PDT)
> >> Resent-From:alias-boun...@ietf.org
> >> Resent-To:  r...@ipv.sx, j...@eff.org, jdkas...@umich.edu
> >> Date:   Fri, 24 Mar 2017 18:03:53 -0700
> >> From:   erica 
> >> To: draft-ietf-acme-a...@ietf.org
> >>
> >>
> >>
> >> In section 6.4.1. Replay-Nonce, it states: "The server should generate
> >> the value provided in Replay-Nonce in such a way that they are unique to
> >> each message, with high probability."
> >>
> >> Should this not be: "The server MUST generate the value provided in
> >> Replay-Nonce in such a way that they are unique to each message."
> >>
> >> This is actually two separate items:
> >> - First, that the server must, not should, generate a unique
> >> Replay-Nonce. I can't imagine that we're ok with the spec allowing a
> >> server to come under replay attacks, so this should probably be MUST.
> >> - Second, do Replay-Nonces need to be certainly unique to each message?
> >> Or are we merely attempting to mostly rule out replay attacks? If we
> >> want to disable them completely, not just with extremely high
> >> probability, then we should remove "with high probability".
> >>
> >> Best,
> >> Erica Portnoy
> >>
> >>
> >> ___
> >> 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
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

[Jacob Hoffman-Andrews]

On 03/30/2017 09:04 AM, Sean Leonard wrote:
> IN PARTICULAR: both Apache and Ngnix may be subject to a private key
> substitution attack with naive passing of the ACME response to the web
> server! See:
> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate
> http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile
>
> The SSL Certificate option includes the option of including the
> private key in the same input: “A secret key in the PEM format may be
> placed in the same file.” 
>
> What this means is that a malicious ACME server can serve a
> certificate per the client’s request, but substitute the server’s
> specified private key with the ACME server’s own choice of private key
> by including -BEGIN RSA PRIVATE KEY- in the response. Then
> when put into production, the ACME server operator will be able to
> decrypt all of the traffic. WHOOPS. (Obviously the ACME server can
> impersonate the web/TLS server, since it’s a CA component, but this is
> not what you want.)
This is a good point, and makes me more inclined towards the
"concatenated DER" approach you suggested, if it looks like it would be
straightforward for clients to implement. Specifically because any
client transforming the DER into PEM would be responsible for adding the
"-BEGIN CERTIFICATE-" delimiters, and would be very unlikely to
output private key delimiters instead.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

[Sean Leonard]

> On Mar 30, 2017, at 10:47 AM, Jacob Hoffman-Andrews  wrote:
> 
>> Therefore the “receiver” is the ACME client, which also is the web/TLS
> server that incorporates the chain into its operations.
> 
> Note that in common deployment today, the ACME client is separate from
> the web server.

Ok.

> 
> On 03/30/2017 08:27 AM, Sean Leonard wrote:
>> Contents: DER-encoded certificates, concatenated in RFC 5246 Section
>> 7.4.2 order 
> Is there a straightforward OpenSSL command to convert this entity into a
> PEM file containing multiple certificates? I don't think there is but I
> could be wrong.

It’s straightforward. I’ll research it later…if it’s not “straightforward 
enough” I can just write a script for you all to take.

>> This is easier and better than stringing the textual encoded versions 
>> because you don’t have to deal with text metadata issues, charsets, line 
>> endings, and extra processing. Specifically, an ACME server is going to have 
>> to take the certificate bytes and base64-encode each one, followed by ASCII 
>> armoring. Then the ACME client is going to have to reverse this. No point 
>> and confusing.
> Our expectation is that many ACME clients will *not* reverse the base64
> and ASCII armoring, but will write out the entire contents to a file for
> ingestion by a web server. The two most popular web servers, Apache and
> Nginx, consume PEM-formatted certificate chains.

Yeah, that’s a problem, you need to be #@($#@ sure that you are validating the 
response from the ACME client.

RFC 7468 discusses implementations considerations with multiple textually 
encoded crypto items (Section 2, Section 14). If you are ingesting a stream 
that has textually encoded items, you need to “hunt-and-pick” exactly what you 
are looking for, and validate the contents.

IN PARTICULAR: both Apache and Ngnix may be subject to a private key 
substitution attack with naive passing of the ACME response to the web server! 
See:
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate 

http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile 


The SSL Certificate option includes the option of including the private key in 
the same input: “A secret key in the PEM format may be placed in the same 
file.” 

What this means is that a malicious ACME server can serve a certificate per the 
client’s request, but substitute the server’s specified private key with the 
ACME server’s own choice of private key by including -BEGIN RSA PRIVATE 
KEY- in the response. Then when put into production, the ACME server 
operator will be able to decrypt all of the traffic. WHOOPS. (Obviously the 
ACME server can impersonate the web/TLS server, since it’s a CA component, but 
this is not what you want.)

Different implementations may behave differently: the moral lesson is to 
validate your inputs, and in this case, that means to deal with the certificate 
chain response with a lot more finesse than is contemplated with 
“application/pem-certificate-chain”.

> 
> You're right that an ACME client would have to decode this format if
> they wanted to change it to something else, but what we are seeing in
> practice is clients that simply convert the end-entity certificate from
> DER to PEM and don't bother with the intermediates, resulting in
> end-user pain.

Check out the above. :-)

> 
>> For those who don’t like binary, ACME is JSON-based, so you can just have an 
>> application/json response that is just an array:
>> 
>> [“MIICAS...base64 of end-entity cert”,“MIICAS…base64 of second cert…”…to 
>> root]
> For me, "don't like binary" isn't the issue. If CMS were the most common
> certificate chain input format for web servers, I would be fine with
> returning binary CMS. Unfortunately, it is not.

Right, but “PEM” is not the format that you are actually looking for in this 
case, despite its apparent ease of use. What this draft is calling 
application/pem-certificate-chain boils down to text/plain, and at least 
text/plain makes the security issues more obvious (because the ACME client is 
ingesting arbitrary inputs).

Let’s address the issue raised above first…

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

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

[Jacob Hoffman-Andrews]

> Therefore the “receiver” is the ACME client, which also is the web/TLS
server that incorporates the chain into its operations.

Note that in common deployment today, the ACME client is separate from
the web server.

On 03/30/2017 08:27 AM, Sean Leonard wrote:
> Contents: DER-encoded certificates, concatenated in RFC 5246 Section
> 7.4.2 order 
Is there a straightforward OpenSSL command to convert this entity into a
PEM file containing multiple certificates? I don't think there is but I
could be wrong.
> This is easier and better than stringing the textual encoded versions because 
> you don’t have to deal with text metadata issues, charsets, line endings, and 
> extra processing. Specifically, an ACME server is going to have to take the 
> certificate bytes and base64-encode each one, followed by ASCII armoring. 
> Then the ACME client is going to have to reverse this. No point and confusing.
Our expectation is that many ACME clients will *not* reverse the base64
and ASCII armoring, but will write out the entire contents to a file for
ingestion by a web server. The two most popular web servers, Apache and
Nginx, consume PEM-formatted certificate chains.

You're right that an ACME client would have to decode this format if
they wanted to change it to something else, but what we are seeing in
practice is clients that simply convert the end-entity certificate from
DER to PEM and don't bother with the intermediates, resulting in
end-user pain.

> For those who don’t like binary, ACME is JSON-based, so you can just have an 
> application/json response that is just an array:
>
> [“MIICAS...base64 of end-entity cert”,“MIICAS…base64 of second cert…”…to root]
For me, "don't like binary" isn't the issue. If CMS were the most common
certificate chain input format for web servers, I would be fine with
returning binary CMS. Unfortunately, it is not.

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

Re: [Acme] Retrying failed authorizations

[Jacob Hoffman-Andrews]

On 03/29/2017 08:31 PM, Hugo Landau wrote:
>> What is the rest of the group's thoughts on whether we'd have to restart
>> WGLC for this?
> I'd hope that if the 'can retry individual challenges' option is chosen
> this is considered a minor enough change to avoid restarting WGLC.
>
> However, it also seems pointless to finalize the ACME specification as
> an RFC when we have the opportunity to wait until Let's Encrypt obtains
> operational experience in production with the revised specification.
> It's a little bizarre that a version of the specification that isn't
> going to be standardized as an RFC has a lot more deployment experience
> attached to it than a substantially different version with no current
> deployment experience.
>
> It would be a different story if this WG thought it was holding anything
> up by virtue of deferring standarization; if another WG was waiting on
> an RFC to cite, or so on. But the evidence is that the fact that ACME is
> still an I-D hasn't stopped real-world deployment of either CAs (Let's
> Encrypt) or a multitude of clients.
Thanks for expressing this; I tend to agree, but that makes sense given
that I work on Let's Encrypt.

The main countervailing pressure, in my mind, is that other CAs are
starting to show interest in ACME, but of course the main reason to use
ACME is interop with existing tools. So we want to have something
reasonably final (and in production), so that new integrations are built
against the final-ish version rather than Boulder's outdated variant as
much as possible. However, I think the main gating factor there is, as
you say, getting the latest spec into production in Boulder. Which we're
working on. :-)

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

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

[Jacob Hoffman-Andrews]

On 03/29/2017 01:48 PM, Sean Leonard wrote:
> If you are saying that the receiver is only expected to handle TLS
> 1.2-ordered certificates: “Each following certificate MUST directly
> certify the one preceding it” (MUST, not SHOULD) then we have a
> different situation and PKCS #7/CMS certs-only may not be appropriate.
> But the text does not currently say that, so I need clarification
> before suggesting a better data format for the certificate chain.
In general, the expectation is that the ACME client passes the
certificate chain straight to a web server or other TLS server.
Generally speaking, the TLS server will then pass along the chain in the
same order to the TLS client during the handshake. So I assume by
"receiver" you mean TLS client, right?

My understanding of TLS deployment is that, even though TLS 1.2, 1.1,
and 1.0 required strict ordering of certificates in the chain, deployed
clients were actually tolerant of out-of-order certificates. I haven't
followed TLS 1.3 standardization closely, but my guess is that that's
the reason the ordering requirement was relaxed.

So I think the answer to your question is: The receiver (TLS client) is
expected to handle TLS 1.3-ordered certificates, and our belief is that
that's reasonable given today's deployments.

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