Re: [Acme] Specify account by kid (reg URL) rather than key. #193

[Jacob Hoffman-Andrews]

On 10/02/2016 08:40 AM, Richard Barnes wrote:
> the need to provide a valid signature provided some minimal validation
> of the request that could be performed totally statelessly by the server.
This would only filter out requests that are otherwise well-formed, but
have a bad signature, which are a vanishingly small fraction of
requests. I just sampled 100k POSTs from Let's Encrypt's logs, and
exactly 0 of them have that property. So I don't think this "stateless
validation" has an advantage.

> Nonetheless, key comparison does not seem that risky to me -- it's
> what undergirds every TLS and SSH session you've ever engaged in

The main concern is not key comparison, it's "verify, then lookup" vs
"lookup, then verify." Your SSH example actually supports my point: In
SSH, the client sends a user id to the server, which the server then
uses to look up the public keys with which to authenticate the user.

On 10/02/2016 05:34 PM, Hugo Landau wrote:

> Can we point to any historical vulnerabilities caused by an
implementation error of this kind?

The specific kind of bug that the "verify, then lookup" pattern makes
possible is one where the "lookup" phase looks up the wrong thing. That
type of bug happens a lot. For instance, one of these Rails snippets has
a security flaw that would allow misissuance, because of the "verify,
then lookup" pattern. Can you tell which one just by looking at them?

---
header_key = jws_body.header.jwk
if !jws_body.verify(header_key)
  return "Bad signature"
account = Account.find_by jwk: header_key
authorizations = Authorization.find_by account: account.id
if authorizations.any? {|a| a.fqdn == requested_fqdn }
  issue_cert()
---

---
header_key = jws_body.header.jwk
if !jws_body.verify(header_key)
  return "Bad signature"
account = Account.find_by! jwk: header_key
authorizations = Authorization.find_by! account: account.id
if authorizations.any? {|a| a.fqdn == requested_fqdn }
  issue_cert()
---

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

Re: [Acme] Specify account by kid (reg URL) rather than key. #193

[Martin Thomson]

I am inclined to think that this is a good change, on the basis that
it means that the server is minting the identifiers that the client
uses.  I think that Jacob is probably understating the potential for
bugs here.  And key canonicalization is a bad smell.

On 27 September 2016 at 14:51, Jacob Hoffman-Andrews  wrote:
> I understand the concern, but I think that clients already have to store
> a significant amount of state: the ACME directory URL, the private key,
> and the domain names, certificates, and private keys of existing
> certificates. I think that one more item, the account URL, is not a
> heavy burden, especially when weighed against a real flaw in the
> protocol. You could consider it akin to storing a username and password
> for a more traditional login.
>
> All that said, for clients that find it to be a big savings, there is
> always the method of finding the account URL by POSTing again to new-reg
> with the same key.
>
> On 09/24/2016 06:16 PM, Hugo Landau wrote:
>> I'm somewhat against this on the grounds that it introduces unnecessary
>> state into clients (the registration URI), increasing their complexity.
>>
>> ___
>> 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] Specify account by kid (reg URL) rather than key. #193

[Jacob Hoffman-Andrews]

I understand the concern, but I think that clients already have to store
a significant amount of state: the ACME directory URL, the private key,
and the domain names, certificates, and private keys of existing
certificates. I think that one more item, the account URL, is not a
heavy burden, especially when weighed against a real flaw in the
protocol. You could consider it akin to storing a username and password
for a more traditional login.

All that said, for clients that find it to be a big savings, there is
always the method of finding the account URL by POSTing again to new-reg
with the same key.

On 09/24/2016 06:16 PM, Hugo Landau wrote:
> I'm somewhat against this on the grounds that it introduces unnecessary
> state into clients (the registration URI), increasing their complexity.
>
> ___
> 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