Subject: Re: [Acme] Support for domains with redundant but not immediately synchronized servers

From: Jonas Wielicki <[email-masked]>
Date: Tue, 9 Feb 2016 11:22:16 +0100

On 21.01.2016 15:13, Salz, Rich wrote:
> 
>> I am not at all familiar with the processes in an IETF WG. What
>> is the way forward to get my proposal either into the protocol or
>> officially dismissed?
> 
> This is the way it works. :)  People post to the mailing list and
> there's discussion.  At some point, the chairs will see if there is
> consensus to do it.
> 
> So things are working as designed.  It's informal and a bit messy.
> 
> What might help focus discussion is if you made a pull request with
> your specific wording changes.

I gave it a shot: https://github.com/ietf-wg-acme/acme/pull/82

I will appreciate any feedback on that proposal.

best regards,
jwi

---

From: Michael Wyraz <[email-masked]>
Date: Tue, 9 Feb 2016 12:11:48 +0100

Hello Jonas,

thank you for the proposal. I think addressing such setups is a good idea.

The solution you propose works only if dns round robin is used (i.e. all
the real server ips in A or AAAA). But there are similar setups where
the redundant servers are behind some load balancer where a completely
different ip is used. Another widely used scenario is geo-based dns. In
this case, the Acme server would only see his "nearest" ip address.

IMO a better way to support your scenario as well as those I described
above would be to check for an SRV-Record before checking A-Records.
This would be 100% compatible with existing acme http-01 clients. In
your case you would resolve the SRV record to the machine that has the
acme client running on. The acme-server would check for the SRV-Record
for an address to lookup the challenge's response at. If no SRV record
is specified, it would continue with A and AAAA records.

Kind regards,
Michael.

> > _______________________________________________ > Acme mailing list >
[email-masked] > https://www.ietf.org/mailman/listinfo/acme

---

From: Jonas Wielicki <[email-masked]>
Date: Tue, 9 Feb 2016 14:08:11 +0100

Hello Michael,

(re-sent to include the list, sorry for the noise, Michael)

> thank you for the proposal. I think addressing such setups is a 

Thank you for your feedback!

> The solution you propose works only if dns round robin is used 
> (i.e. all the real server ips in A or AAAA). But there are similar 
> setups where the redundant servers are behind some load balancer 
> where a completely different ip is used. Another widely used 
> scenario is geo-based dns. In this case, the Acme server would
> only see his "nearest" ip address.

I agree.

> IMO a better way to support your scenario as well as those I 
> described above would be to check for an SRV-Record before
> checking A-Records. This would be 100% compatible with existing
> acme http-01 clients. In your case you would resolve the SRV record
> to the machine that has the acme client running on. The acme-server
> would check for the SRV-Record for an address to lookup the
> challenge's response at. If no SRV record is specified, it would
> continue with A and AAAA records.

I am not entirely sure I get what you want to say here. SRV records
contain not only a host name, but also priorities, weights and ports,
so I wonder how that information would be used in this context.

Do you suggest to have the client use an SRV record to specify the
address (including the port?) to which the server connects to complete
the challenge? In that case, what would the effect of multiple SRV
records for the target name be?

best regards,
jwi

---

From: Michael Wyraz <[email-masked]>
Date: Tue, 9 Feb 2016 14:53:18 +0100

Hello Jonas,
> > described above would be to check for an SRV-Record before checking
> > A-Records. This would be 100% compatible with existing acme http-01
> > clients. In your case you would resolve the SRV record to the
> > machine that has the acme client running on. The acme-server would
> > check for the SRV-Record for an address to lookup the challenge's
> > response at. If no SRV record is specified, it would continue with
> > A and AAAA records.
>
correct, that's exactly what I meant. Example:

_acme.http-01._tcp.mydomain.com. 3600 IN    SRV    10 1 80
acme.mydomain.com.

For multiple SRV weight/priority should be respected.

Four your case you would resolve www.mydomain.com to several ip addresses:
www.mydomain.com. IN A IP-Address-Server1
www.mydomain.com. IN A IP-Address-Server2

While acme.mydomain.com resolves to a single ip address of the server
where the acme client runs on:
acme.mydomain.com. IN A IP-Address-Server1

---

From: Jonas Wielicki <[email-masked]>
Date: Tue, 9 Feb 2016 20:40:17 +0100

On 09.02.2016 14:53, Michael Wyraz wrote:
>>> acme http-01 clients. In your case you would resolve the SRV
>>> record to the machine that has the acme client running on. The
>>> acme-server would check for the SRV-Record for an address to
>>> lookup the challenge's response at. If no SRV record is
>>> specified, it would continue with A and AAAA records.
>> 
>> I am not entirely sure I get what you want to say here. SRV
>> records contain not only a host name, but also priorities,
>> weights and ports, so I wonder how that information would be used
>> in this context.
>> 
>> Do you suggest to have the client use an SRV record to specify
>> the address (including the port?) to which the server connects to
>> complete the challenge? In that case, what would the effect of
>> multiple SRV records for the target name be?
> Four your case you would resolve www.mydomain.com to several ip
> addresses: www.mydomain.com. IN A IP-Address-Server1 
> While acme.mydomain.com resolves to a single ip address of the
> server where the acme client runs on: acme.mydomain.com. IN A
> IP-Address-Server1

So if I understand this correctly, the ACME client would have to set
(or modify) the SRV records in such a way that the host which is
currently running the client is the one with the highest priority?
This sounds like you could just use the DNS challenge, right?

And it is a different use-case from the one I posted initially. If the
clients were able to modify the DNS properly, I could indeed use the
dns-01 challenge in my scenario. This is not the case though.

best regards,
jwi

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 9 Feb 2016 11:52:18 -0800

> https://github.com/ietf-wg-acme/acme/pull/82

I am against adding an address hint to the spec. I think it's
unnecessary complication to the spec, and introduces client control of a
critical security field. It would be too easy for implementers to
incorrectly check that the address was present in the DNS response.

Additionally, this fails to address GSLB / geo-based DNS, as Michael
Wyraz pointed out. So it winds up being a half solution.

As I said previously, I think it would be better for implementers to
query each IP they receive, until they get a success. For GSLB cases,
the subscriber would need to either (1) use an HTTP redirect to a
non-GSLB domain name, (2) ensure that every frontend is capable of
serving the challenge at the appropriate time, or (3) use the dns-01
challenge.

---

From: Jonas Wielicki <[email-masked]>
Date: Tue, 9 Feb 2016 21:15:22 +0100

On 09.02.2016 20:52, Jacob Hoffman-Andrews wrote:
> As I said previously, I think it would be better for implementers
> to query each IP they receive, until they get a success.

In fact, I’d also be pleased with that solution. If consensus could be
found for that, I’d happily retract my proposal.

However, it would have to be a MUST for servers…

best regards,
jwi

---

From: Michael Wyraz <[email-masked]>
Date: Tue, 9 Feb 2016 21:57:49 +0100

Hi Jonas,
> dns-01 challenge in my scenario. This is not the case though.
You're right, I missunderstood your use case and thought, the client
only runs on a certain of the servers. Using SRV records will not solve
this special use case.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 12 Feb 2016 15:00:04 -0800

On 02/09/2016 11:52 AM, Jacob Hoffman-Andrews wrote:
> query each IP they receive, until they get a success.
I thought some more about this from a CA implementation perspective, and
it would actually be rather painful and error-prone to implement.

In Boulder, we have a maximum amount of time we are willing to spend on
validating a challenge. Currently it's 60 seconds. We may increase it at
some point, but there will always be some limit. For hostnames that
return a large number of IP addresses, it's entirely possible we would
timeout before reaching the one IP address that is provisioned with the
challenge.

That means that instead of the nice clean "Push a challenge to any
server and it will work" guarantee, we would have a "Push a challenge to
any server, and it will work provided you don't have too many IP
addresses and the other instances respond quickly enough" guarantee.