Re: [Acme] Mail regarding draft-ietf-acme-tls-alpn

[Ben Sykes]

Ah ok. Got it.
That's good.
On Fri, May 25, 2018 at 11:07 AM Roland Shoemaker 
wrote:

> The validation certificate should only ever be served for requests that
> negotiate the amce-tls/1 application protocol, which browsers or equivalent
> user software should never do. This allows the server (or load balancer) to
> continue serving normal traffic to users while also serving validation
> traffic to the ACME server.
>
> > On May 25, 2018, at 8:09 AM, Ben Sykes 

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

On Tue, May 15, 2018 at 2:37 AM Ilari Liusvaara 
wrote:

> On Tue, May 15, 2018 at 01:20:14AM +, Richard Barnes wrote:
> >  [ Adding the mailing list ]
> >
> > > S 6.6.
> > > >  |
> > | |
> > > >  | serverInternal  | The server experienced an
> > internal  |
> > > >  | |
> > error   |
> > > >  |
> > | |
> > > >  | tls | The server received a TLS error
> > during  |
> > > >  | |
> > validation  |
> > >
> > > Can you expand on what this means? Suppose instead I got a 500 during
> > > validation?
> >
> > [[ EDIT - 272c754 ]]
> >
> > I think this goes back to when the TLS-SNI challenge.  It's no longer
> > relevant here, so I've removed it.  The new TLS-based challenge can
> re-add
> > it if they need it.
>
> This is incorrect. It is neeed by HTTP-01 already, because that can
> redirect to https://, which then tries to set up TLS, which can fail
> even when the TCP connection succeeded. And given flakyness of
> validation in general, one does not want misleading errors to make
> things even harder.
>

Good point.  I've backed out this change in my working copy.

--Richard



>
> One of the more creative ones I have heard about is misconfigured
> servers that interpret the TLS ClientHello as malformed HTTP request
> and sends back HTTP 400 Bad Request, which the TLS client then tries
> to parse as ServerHello and obviously chokes. This issue is apparently
> not that rare, in fact, Let's Encrypt specifically checks for TLS
> ServerHellos that look like HTTP replies.
>
>
> -Ilari
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Ryan Sleevi]

On Fri, May 25, 2018 at 12:08 PM, Eric Rescorla  wrote:
>
> > > IMPORTANT
> > > S 6.2.
> > > > algorithm in its "alg" field
> > > >
> > > >  o  The JWS Payload MUST NOT be detached
> > > >  o  The JWS Protected Header MUST include the following fields:
> > > >
> > > > *  "alg" (Algorithm)
> > >
> > > Do you want to specify a set of acceptable signature algorithms here?
> >
> > I am inclined not to.  We have already forbidden "none" and MAC.  We
> > shouldn't specify "MUST"s here, because CABF sets their own list of
> > required algorithms, and we don't want to conflict.  I guess you
> > could specify some MUST NOTs pretty safely, but given that they're
> > already forbidden by CABF, it seems kind of duplicative.
>
> This is about the signatures that ACME accepts, not the signatures
> in certs. Does CABF have a position on what signature algorithms
> that ACME uses?
>

The Baseline Requirements do not establish any policies here regarding
proof of key possession (which is not required, strictly speaking) or
domain name validation methods, or on the authentication channel between
the Applicant and CA.

For example, 3.2.2.4.6 of the BRs (at time of writing,
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.7-29-Apr-2018.pdf
) allow the use of MD2 or MD4 as part of their request token construction
or within the use of CSRs.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Mail regarding draft-ietf-acme-tls-alpn

[Roland Shoemaker]

The validation certificate should only ever be served for requests that 
negotiate the amce-tls/1 application protocol, which browsers or equivalent 
user software should never do. This allows the server (or load balancer) to 
continue serving normal traffic to users while also serving validation traffic 
to the ACME server.

> On May 25, 2018, at 8:09 AM, Ben Sykes 

Re: [Acme] Mail regarding draft-ietf-acme-tls-alpn

[Ilari Liusvaara]

On Fri, May 25, 2018 at 08:09:01AM -0700, Ben Sykes wrote:
> Hi there,
> 
> Having read through the draft spec, I have a concern over certificate
> renewals.
> As I read it, the server would have to temporarily use a customized
> self-signed certificate while the check is pending. Won't this mean any
> regular user connecting to that server over TLS at the time be presented
> with the self-signed certificate? This would manifest as downtime for the
> service.
> Is there a provision for renewal using this method?

AFAIK, there is no way to construct a validation method that is all of:

- Can be used by "public" CAs.
- TLS-level.
- Operates on port 443.
- No downtime.
- No special application or TLS library support required.


TLS-ALPN fails the last line (if you do not have special application or
TLS library support, you take downtime).

I have cooked an experimental version of TLS library I have written,
with the needed support to answer the validation queries with no
downtime (also internally generating the needed certificate from name
-> key authorization mapping). 


-Ilari

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

Re: [Acme] Mail regarding draft-ietf-acme-tls-alpn

[Salz, Rich]

  *   As I read it, the server would have to temporarily use a customized 
self-signed certificate while the check is pending.

If you renew before the current cert expires, that’s not an issue, right?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Mail regarding draft-ietf-acme-tls-alpn

[Ben Sykes]

Hi there,

Having read through the draft spec, I have a concern over certificate
renewals.
As I read it, the server would have to temporarily use a customized
self-signed certificate while the check is pending. Won't this mean any
regular user connecting to that server over TLS at the time be presented
with the self-signed certificate? This would manifest as downtime for the
service.
Is there a provision for renewal using this method?

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