Re: [Acme] lack of nonce for external account binding (was Re: Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14:) (with DISCUSS and COMMENT)

[Salz, Rich]

  *   I actually have the opposite inclination to you here -- if a field is not 
used by the protocol, then it should be forbidden, in the spirit of [1].  By 
that logic, we should also forbid the use of the "nonce" field in roll-over.  I 
think it was just an oversight that we didn't.  The security analysis that 
Bhargavan et al. did long ago did not presume any use of it.   I've made a PR 
making it a MUST NOT:


  *   
https://github.com/ietf-wg-acme/acme/pull/464


  *   [1] 
https://tools.ietf.org/html/draft-iab-protocol-maintenance-00

If anyone in the WG has objections to this, please speak up now.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] lack of nonce for external account binding (was Re: Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14:) (with DISCUSS and COMMENT)

[Richard Barnes]

On Wed, Oct 10, 2018 at 6:47 PM Benjamin Kaduk  wrote:

> On Wed, Oct 10, 2018 at 06:42:33PM -0400, Richard Barnes wrote:
> > On Wed, Oct 3, 2018 at 11:54 AM Benjamin Kaduk  wrote:
> >
> > > On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote:
> > > > On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote:
> > > > > > My co-author Daniel McCarney is working on the COMMENT comments.
> > > > >
> > > > > > IMPORTANT: I don't think I understand why "nonce" MUST NOT be
> > > present in
> > > > > > the external-binding JWS object, though I think I understand why
> one
> > > is
> > > > > not
> > > > > > needed in order to bind the MAC to the current transaction.
> (That
> > > is,
> > > > > this
> > > > > > is in effect a "triply nested" construct, where a standalone MAC
> that
> > > > > > certifies an ACME account (public) key as being authorized by the
> > > > > > external-account holder to act on behal of that external account.
> > > But
> > > > > this
> > > > > > standalone MAC will only be accepted by the ACME server in the
> > > context of
> > > > > > the outer JWS POST, that must be signed by the ACME account key,
> > > which is
> > > > > > assumed to be kept secure by the ACME client, ensuring that both
> > > > > > key-holding entities agree to the account linkage.)  Proof of
> > > freshness of
> > > > > > the commitment from the external account holder to authorize the
> ACME
> > > > > > account key would only be needed if there was a scenario where
> the
> > > > > external
> > > > > > account holder would revoke that association, which does not
> seem to
> > > be a
> > > > > > workflow supported by this document.  Any need to effectuate
> such a
> > > > > > revocation seems like it would involve issuing a new MAC key for
> the
> > > > > > external account (and invalidating the old one), and
> > > revoking/deactivating
> > > > > > the ACME account, which is a somewhat heavy hammer but perhaps
> > > reasonable
> > > > > > for such a scenario.
> > > > > > Account key rollover just says that the nonce is NOT REQUIRED,
> and
> > > also
> > > > > > uses some nicer (to me) language about "outer JWS" and "inner
> JWS".
> > > It
> > > > > > might be nice to synchronize these two sections.
> > > > >
> > > > > I defer on this to the other authors/people that want
> > > > > externalAccountBinding to
> > > > > be a thing.
> > > >
> > > > Okay.  I would like to avoid having needless normative requirements
> if
> > > > there is in fact no reason for this requirement.
> > >
> > > My apologies if I missed it when it went by, but did we ever hear more
> > > about this requirement from the proponents of externalAccountBinding?
> > >
> >
> > Picking this up...
> >
> > I actually have the opposite inclination to you here -- if a field is not
> > used by the protocol, then it should be forbidden, in the spirit of [1].
> > By that logic, we should also forbid the use of the "nonce" field in
> > roll-over.  I think it was just an oversight that we didn't.  The
> security
> > analysis that Bhargavan et al. did long ago did not presume any use of
> > it.   I've made a PR making it a MUST NOT:
> >
> > https://github.com/ietf-wg-acme/acme/pull/464
> >
> > [1] https://tools.ietf.org/html/draft-iab-protocol-maintenance-00
>
> Okay, a "MUST NOT" because anything not needed should be forbidden is a
> fine reason to me; thanks for putting together the PR to bring the two
> cases into consistency.
>

Thanks for the review!
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] lack of nonce for external account binding (was Re: Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14:) (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Wed, Oct 10, 2018 at 06:42:33PM -0400, Richard Barnes wrote:
> On Wed, Oct 3, 2018 at 11:54 AM Benjamin Kaduk  wrote:
> 
> > On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote:
> > > On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote:
> > > > > My co-author Daniel McCarney is working on the COMMENT comments.
> > > >
> > > > > IMPORTANT: I don't think I understand why "nonce" MUST NOT be
> > present in
> > > > > the external-binding JWS object, though I think I understand why one
> > is
> > > > not
> > > > > needed in order to bind the MAC to the current transaction.  (That
> > is,
> > > > this
> > > > > is in effect a "triply nested" construct, where a standalone MAC that
> > > > > certifies an ACME account (public) key as being authorized by the
> > > > > external-account holder to act on behal of that external account.
> > But
> > > > this
> > > > > standalone MAC will only be accepted by the ACME server in the
> > context of
> > > > > the outer JWS POST, that must be signed by the ACME account key,
> > which is
> > > > > assumed to be kept secure by the ACME client, ensuring that both
> > > > > key-holding entities agree to the account linkage.)  Proof of
> > freshness of
> > > > > the commitment from the external account holder to authorize the ACME
> > > > > account key would only be needed if there was a scenario where the
> > > > external
> > > > > account holder would revoke that association, which does not seem to
> > be a
> > > > > workflow supported by this document.  Any need to effectuate such a
> > > > > revocation seems like it would involve issuing a new MAC key for the
> > > > > external account (and invalidating the old one), and
> > revoking/deactivating
> > > > > the ACME account, which is a somewhat heavy hammer but perhaps
> > reasonable
> > > > > for such a scenario.
> > > > > Account key rollover just says that the nonce is NOT REQUIRED, and
> > also
> > > > > uses some nicer (to me) language about "outer JWS" and "inner JWS".
> > It
> > > > > might be nice to synchronize these two sections.
> > > >
> > > > I defer on this to the other authors/people that want
> > > > externalAccountBinding to
> > > > be a thing.
> > >
> > > Okay.  I would like to avoid having needless normative requirements if
> > > there is in fact no reason for this requirement.
> >
> > My apologies if I missed it when it went by, but did we ever hear more
> > about this requirement from the proponents of externalAccountBinding?
> >
> 
> Picking this up...
> 
> I actually have the opposite inclination to you here -- if a field is not
> used by the protocol, then it should be forbidden, in the spirit of [1].
> By that logic, we should also forbid the use of the "nonce" field in
> roll-over.  I think it was just an oversight that we didn't.  The security
> analysis that Bhargavan et al. did long ago did not presume any use of
> it.   I've made a PR making it a MUST NOT:
> 
> https://github.com/ietf-wg-acme/acme/pull/464
> 
> [1] https://tools.ietf.org/html/draft-iab-protocol-maintenance-00

Okay, a "MUST NOT" because anything not needed should be forbidden is a
fine reason to me; thanks for putting together the PR to bring the two
cases into consistency.

-Benjamin

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

Re: [Acme] lack of nonce for external account binding (was Re: Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14:) (with DISCUSS and COMMENT)

[Richard Barnes]

On Wed, Oct 3, 2018 at 11:54 AM Benjamin Kaduk  wrote:

> On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote:
> > On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote:
> > > > My co-author Daniel McCarney is working on the COMMENT comments.
> > >
> > > > IMPORTANT: I don't think I understand why "nonce" MUST NOT be
> present in
> > > > the external-binding JWS object, though I think I understand why one
> is
> > > not
> > > > needed in order to bind the MAC to the current transaction.  (That
> is,
> > > this
> > > > is in effect a "triply nested" construct, where a standalone MAC that
> > > > certifies an ACME account (public) key as being authorized by the
> > > > external-account holder to act on behal of that external account.
> But
> > > this
> > > > standalone MAC will only be accepted by the ACME server in the
> context of
> > > > the outer JWS POST, that must be signed by the ACME account key,
> which is
> > > > assumed to be kept secure by the ACME client, ensuring that both
> > > > key-holding entities agree to the account linkage.)  Proof of
> freshness of
> > > > the commitment from the external account holder to authorize the ACME
> > > > account key would only be needed if there was a scenario where the
> > > external
> > > > account holder would revoke that association, which does not seem to
> be a
> > > > workflow supported by this document.  Any need to effectuate such a
> > > > revocation seems like it would involve issuing a new MAC key for the
> > > > external account (and invalidating the old one), and
> revoking/deactivating
> > > > the ACME account, which is a somewhat heavy hammer but perhaps
> reasonable
> > > > for such a scenario.
> > > > Account key rollover just says that the nonce is NOT REQUIRED, and
> also
> > > > uses some nicer (to me) language about "outer JWS" and "inner JWS".
> It
> > > > might be nice to synchronize these two sections.
> > >
> > > I defer on this to the other authors/people that want
> > > externalAccountBinding to
> > > be a thing.
> >
> > Okay.  I would like to avoid having needless normative requirements if
> > there is in fact no reason for this requirement.
>
> My apologies if I missed it when it went by, but did we ever hear more
> about this requirement from the proponents of externalAccountBinding?
>

Picking this up...

I actually have the opposite inclination to you here -- if a field is not
used by the protocol, then it should be forbidden, in the spirit of [1].
By that logic, we should also forbid the use of the "nonce" field in
roll-over.  I think it was just an oversight that we didn't.  The security
analysis that Bhargavan et al. did long ago did not presume any use of
it.   I've made a PR making it a MUST NOT:

https://github.com/ietf-wg-acme/acme/pull/464

[1] https://tools.ietf.org/html/draft-iab-protocol-maintenance-00


>
> Thanks,
>
> Benjamin
>
> ___
> 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] lack of nonce for external account binding (was Re: Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14:) (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote:
> On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote:
> > > My co-author Daniel McCarney is working on the COMMENT comments.
> > 
> > > IMPORTANT: I don't think I understand why "nonce" MUST NOT be present in
> > > the external-binding JWS object, though I think I understand why one is
> > not
> > > needed in order to bind the MAC to the current transaction.  (That is,
> > this
> > > is in effect a "triply nested" construct, where a standalone MAC that
> > > certifies an ACME account (public) key as being authorized by the
> > > external-account holder to act on behal of that external account.  But
> > this
> > > standalone MAC will only be accepted by the ACME server in the context of
> > > the outer JWS POST, that must be signed by the ACME account key, which is
> > > assumed to be kept secure by the ACME client, ensuring that both
> > > key-holding entities agree to the account linkage.)  Proof of freshness of
> > > the commitment from the external account holder to authorize the ACME
> > > account key would only be needed if there was a scenario where the
> > external
> > > account holder would revoke that association, which does not seem to be a
> > > workflow supported by this document.  Any need to effectuate such a
> > > revocation seems like it would involve issuing a new MAC key for the
> > > external account (and invalidating the old one), and revoking/deactivating
> > > the ACME account, which is a somewhat heavy hammer but perhaps reasonable
> > > for such a scenario.
> > > Account key rollover just says that the nonce is NOT REQUIRED, and also
> > > uses some nicer (to me) language about "outer JWS" and "inner JWS".  It
> > > might be nice to synchronize these two sections.
> > 
> > I defer on this to the other authors/people that want
> > externalAccountBinding to
> > be a thing.
> 
> Okay.  I would like to avoid having needless normative requirements if
> there is in fact no reason for this requirement.

My apologies if I missed it when it went by, but did we ever hear more
about this requirement from the proponents of externalAccountBinding?

Thanks,

Benjamin

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