Re: [Acme] New draft and DANGER

[Salz, Rich]

> Please review the PR as soon as possible and provide comments to the
> list. Other issues or text suggestions for the draft are, of course, also
> welcome.
 

It can be useful to open an issue on the GH repo, so that things don't get lost.

But please everyone, avoid the temptation to have all the discussion there, as 
opposed to this list.

Thanks.

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

Re: [Acme] New draft and DANGER

[Richard Barnes]

Dear WG,

I opened a few PRs over the weekend that address recently-raised issues:

* "Address signature reuse vulnerability" -
https://github.com/ietf-wg-acme/acme/pull/6
* "Address default virtual host risks" -
https://github.com/ietf-wg-acme/acme/pull/7
* "Add explicit versioning to challenges" -
https://github.com/ietf-wg-acme/acme/pull/8

I would really like to merge these and push -01 in the next few days.
It would be really helpful if a few folks could review these changes
and comment to the list (even if it's just "LGTM").

Thanks,
--Richard


On Mon, Sep 28, 2015 at 2:16 PM, Salz, Rich  wrote:
>> Please review the PR as soon as possible and provide comments to the
>> list. Other issues or text suggestions for the draft are, of course, also
>> welcome.
>
>
> It can be useful to open an issue on the GH repo, so that things don't get 
> lost.
>
> But please everyone, avoid the temptation to have all the discussion there, 
> as opposed to this list.
>
> Thanks.
>
> ___
> 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] New draft and DANGER

[Ted Hardie]

On Mon, Sep 28, 2015 at 12:01 PM, Richard Barnes  wrote:

> Dear WG,
> 
> * "Add explicit versioning to challenges" -
> https://github.com/ietf-wg-acme/acme/pull/8
>
>
​I'm not sure this quite right.  If I understand the proposal correctly,
when a client sees http-01 but understands only http-00, the idea that one
is related to the other has no meaning, as the client can only respond to
challenges when type and version match what it has code for,​ right?

I think if we want that behavior, we'll need to specify whether a single
array can have array entries with different versions of the same challenge
type and we'll need to ensure that the same challenge type with different
versions isn't used to create full coverage.

That is, if it's okay for a challenge to be something like "Fulfil HTTP
challenge version 0 and DNS challenge version 1 OR HTTP challenge version 1
and DNS challenge version 0"",  then we should say so.  I also think we
need to explicitly rule out things like "Fulfil HTTP challenge version 0
and HTTP challenge version 1". (If the latter is okay, we shouldn't call
them versions, but treat each iteration as fully semantically distinct).

regards,

Ted
Wearing no hats
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] New draft and DANGER

[Richard Barnes]

On Mon, Sep 28, 2015 at 4:43 PM, Ted Hardie  wrote:
> On Mon, Sep 28, 2015 at 12:01 PM, Richard Barnes  wrote:
>>
>> Dear WG,
>>
>> * "Add explicit versioning to challenges" -
>> https://github.com/ietf-wg-acme/acme/pull/8
>>
>
> I'm not sure this quite right.  If I understand the proposal correctly, when
> a client sees http-01 but understands only http-00, the idea that one is
> related to the other has no meaning, as the client can only respond to
> challenges when type and version match what it has code for, right?
>
> I think if we want that behavior, we'll need to specify whether a single
> array can have array entries with different versions of the same challenge
> type and we'll need to ensure that the same challenge type with different
> versions isn't used to create full coverage.

I was actually envisioning that the version numbers on the challenges
would only change when the challenge changed.  (I was also thinking
they would use the I-D version number, but I could go either way on
that.)  That way, two challenges have different tokens iff they entail
different behavior.  So as of version -07, you might have "http-01",
"tls-sni-03", and "dns-07".  Then when we head to RFC, we can drop the
version numbers.

However...

> That is, if it's okay for a challenge to be something like "Fulfil HTTP
> challenge version 0 and DNS challenge version 1 OR HTTP challenge version 1
> and DNS challenge version 0"",  then we should say so.  I also think we need
> to explicitly rule out things like "Fulfil HTTP challenge version 0 and HTTP
> challenge version 1". (If the latter is okay, we shouldn't call them
> versions, but treat each iteration as fully semantically distinct).

... we do have that capability right now, with the "combinations"
element of the authorization object.  For example, you would represent
the above with:

{
  ...
  "challenges": [
{ "type": "http-00", ... },
{ "type": "dns-00", ... },
{ "type": "http-01", ... },
{ "type": "dns-01", ... },
  ],
 "combinations": [ [0, 2], [1, 3] ]
}

Hope that helps,
--Richard

P.S. Obviously, now that -00 is out, the PR will need to be updated to
use "-01".


>
> regards,
>
> Ted
> Wearing no hats
>
>
>

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

Re: [Acme] New draft and DANGER

[Martin Thomson]

On 28 September 2015 at 13:43, Ted Hardie  wrote:
> I'm not sure this quite right.  If I understand the proposal correctly, when
> a client sees http-01 but understands only http-00, the idea that one is
> related to the other has no meaning, as the client can only respond to
> challenges when type and version match what it has code for, right?

A-00 + B-01 is a bit odd, but if the server wants to support multiple
versions, then it can enumerate all the combinations.  Otherwise, A-00
and A-01 are treated as completely different challenges in every
regard.

I think that keeps it simple.  An implementation that does only one
version (the sensible thing at this point) doesn't have any complexity
to swallow.  An implementation that supports multiple versions should
probably just do the simple thing.

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