Re: [Acme] Should the DNS challenge be deterministic?

>If the issuer of the DNS challenge flushes its DNS cache and checks with >the authoritative server itself, the propagation de​lay doesn't seem like >an issue. Are there particular issuers/conditions for which you believe >the issuer would have to rely on caching resolvers? This

Re: [Acme] Should the DNS challenge be deterministic?

I like the idea, and it generalizes to the other queries. For instance, you can imagine putting up an HTTP validation file that contains a list of authorized account keys, with no random token. However, the CA/B Forum validation requirements currently being discussed include a requirement for a

Re: [Acme] Spec change to allow retrieval of Terms of Service URL

On Thu 2015-11-12 10:30:44 -0500, Matthew Holt wrote: > If the client leaves it up to the user to follow the link, then the format > shouldn't matter in terms of the ACME spec; it is up to the document > renderer (browser) to do so safely and correctly. if the spec has any implications that the

Re: [Acme] Should the DNS challenge be deterministic?

> This seems problematic, however. Changes to DNS can take time to > propagate, and changes to DNS may involve manual intervention. If an > authorization fails for any reason, the process has to be started again. +1 To avoid the cache issue I'm using short TTL but it would be easier if the DNS

[Acme] Content-Type and file extensions for HTTP01 challenges

https://github.com/ietf-wg-acme/acme/pull/40 was just merged, but we didn't actually get consensus that dropping Content-Type restrictions altogether was a good idea. The options are: 0.keep the old spec (Content-Type application/jose+json, no file extensions allowed) 1 keep the

Re: [Acme] Open issues on GitHub

Others might disagree, but those look largely editorial to my reading. My guess is that the editors are busy and will address your concerns when they are able. If you think that there is a technical deficiency with the specification, definitely bring it here. Opening an issue as well helps with

Re: [Acme] Content-Type and file extensions for HTTP01 challenges

I should have added another option, 3b, drop the Content-Type restriction but allow file extensions. Sounds like that would be a win on IIS. On Thu, Nov 12, 2015 at 05:05:53PM -0800, Martin Thomson wrote: > On 12 November 2015 at 16:44, Peter Eckersley wrote: > > But is 3 the best

[Acme] Open issues on GitHub

Hello, how are issues on GitHub handled? Should they always be brought to the list? Seems like there isn't that much activity there. I opened a few while implementing my PHP client with no answers during the last few days. https://github.com/ietf-wg-acme/acme/issues/31

[Acme] PRs from IETF 94

Hey all, I just finished posting a bunch of PRs that I believe reflect the agreements we reached during the ACME meeting at IETF 94. I went ahead and merged those that were either editorial or well-discussed in the room: https://github.com/ietf-wg-acme/acme/pull/40

Re: [Acme] Content-Type and file extensions for HTTP01 challenges

Sorry if I pulled the trigger on that one a bit early. Happy to revise, as always. I think there was pretty feeling in the room at the IETF meeting that Content-Type checking was not doing much. Are we aware of any actual scenarios where untrusted entities can write to .well-known directories?

Re: [Acme] Content-Type and file extensions for HTTP01 challenges

On 12 November 2015 at 16:44, Peter Eckersley wrote: > But is 3 the best answer? Of those presented, I think so. I know that this isn't a great answer (it's bad already, so bad must be OK), but being able to drop things into .well-known opens a raft of other interesting attacks.

Re: [Acme] Should the DNS challenge be deterministic?

On Thu, Nov 12, 2015 at 10:11:12AM +0100, Romain Fliedel wrote: > > > This seems problematic, however. Changes to DNS can take time to > > propagate, and changes to DNS may involve manual intervention. If an > > authorization fails for any reason, the process has to be started again. > > +1 >

Re: [Acme] Should the DNS challenge be deterministic?

On Fri, Nov 13, 2015 at 01:25:35AM +, Hugo Landau wrote: > On Thu, Nov 12, 2015 at 02:14:11PM -0800, Jacob Hoffman-Andrews wrote: > > I like the idea, and it generalizes to the other queries. For instance, > > you can imagine putting up an HTTP validation file that contains a list > > of

Re: [Acme] Should the DNS challenge be deterministic?

> I think one would also have to include the endorsed EESPKI (End-Entity > SubjectPublicKeyInfo, a.k.a. the server public key) too (or at least > collision-resistant hash of it)? > > That should rarely change, so it should be quasi-constant. That works, but I'm not convinced it's necessary.

Re: [Acme] Spec change to allow retrieval of Terms of Service URL

On Wed, Nov 11, 2015 at 7:06 PM Daniel Kahn Gillmor wrote: > Doesn't this depend on the nature of the data fetched at the given URL? > I'd hope that any inclusion of some mechanism like this would be tightly > constrained with guidance that makes the data both

Re: [Acme] Should the DNS challenge be deterministic?

> > On Thu, Nov 12, 2015 at 4:05 PM, Hugo Landau wrote: > >> Currently, the DNS challenge uses a random token which changes every >> time an authorization is performed. >> >> This seems problematic, however. Changes to DNS can take time to >> propagate, > > > If the issuer of

Re: [Acme] Should the DNS challenge be deterministic?

On Thu, Nov 12, 2015 at 4:05 PM, Hugo Landau wrote: > Currently, the DNS challenge uses a random token which changes every > time an authorization is performed. > > This seems problematic, however. Changes to DNS can take time to > propagate, If the issuer of the DNS

Re: [Acme] Open issues on GitHub

Yup. I'm working up PRs on the issues we resolved at the F2F last week. I'll take a look at these issues next. On Thu, Nov 12, 2015 at 5:43 PM, Martin Thomson wrote: > Others might disagree, but those look largely editorial to my reading. > My guess is that the