[cabf_validation] FW: [Acme] ALPN based TLS challenge

[Doug Beattie]

Is anyone following this conversion about a new domain validation protocol?

https://mailarchive.ietf.org/arch/search/?email_list=acme

Doug

-----Original Message-----
From: Sebastian Nielsen [mailto:sebastian at sebbe.eu]
Sent: Friday, February 23, 2018 9:43 AM
To: Doug Beattie <doug.beattie at globalsign.com>; 'Roland Bracewell Shoemaker' <roland at letsencrypt.org>; 'Rich Salz' <rsalz at akamai.com>
Cc: 'IETF ACME' <acme at ietf.org>; 'Martin Thomson' <martin.thomson at gmail.com>
Subject: SV: [Acme] ALPN based TLS challenge

The problem was that there was hosting providers which did not know that the
SNI would be used in validation,
and did not limit or restrict which SNI names a customer could set up
content for, to the domain names that the customer had proofed ownership of.

The new ALPN based challenge, requires the server to explicitly say it do
support validation, thus it means a hosting provider needs explicit
configuration of the TLS parameters to enable Lets Encrypt validation, thus
the risk that a hosting provider unknowingly allows a adversiary to
authenticate as a another customer on the same hosting platform is
eliminated.

There is still the risk that a hosting provider explicitly sets up a server
which annouces support for TLS validation in ALPN, and still do allow
third-parties to set up validations for arbitary domain names.

But then the error is on that hosting provider. Remember that the security
issue ONLY appears if both the customer (which has legiitmate access to a
domain) and the adversiary is on the same hosting provider, and in most
cases, even the same server.

Thus there is the responsibility of the real customer to move away from any
hosting provider that have a explicit configuration that would allow a
adversiary to validate as that customer with ALPN enabled.


To make a analog comparisation:
Imagine a house with 4 apartments. Normally, each apartment should be
separate. But there is old houses with doors between apartments that are not
locked. A delivery guy comes with a package containing sensitive things, and
the delivery guy simply checks that the person receiving the package can
exit out of the correct apartment door.

Due to the security risk in the house with the unlocked door between each
apartment, any tenant can exit out of any apartment door, and thus receive
the package, creating a security risk if a evil adversiary hires one of the
apartments.

The ALPN challenge, is equvalient with a new sign the landlord can set up on
the doors, that these apartments are "Secure". The delivery guy will only
deliver to apartments that have a "Secure" sign. Thus the old apartments
lacking doors between the apartments will then not have any "Secure" sign.
Yes, the landlord can set up a "Secure" sign even on insecure apartments,
but thats an explicit action, and the passive security risk is eliminated,
which means that if the landlord sets up the "Secure" sign on insecure
apartments, its the responsibility of the tenant to move away from there.

You understand now?

-----Ursprungligt meddelande-----
Från: Acme [mailto:acme-bounces at ietf.org] För Doug Beattie
Skickat: den 23 februari 2018 14:18
Till: Roland Bracewell Shoemaker <roland at letsencrypt.org>; Rich Salz
<rsalz at akamai.com>
Kopia: IETF ACME <acme at ietf.org>; Martin Thomson <martin.thomson at gmail.com>
Ämne: Re: [Acme] ALPN based TLS challenge

I'm probably not understanding a key piece of technical info about the
protocol, but when I see this statement it makes me think it has similar
issues to tls-sni-01.  If we're relying on the hosting provider enforcing
certain constraints like this, then we're delegating a critical piece of
domain control back to the hosting provider which would be a no-go.

4.  Security Considerations

   The design of this challenges relies on some assumptions centered
   around how a server behaves during validation.

   The first assumption is that when a server is being used to serve
   content for multiple DNS names from a single IP address that it
   properly segregates control of those names to the users on the server
   that own them.  This means that if User A registers Host A and User B
   registers Host B the server should not allow a TLS request using a
   SNI value for Host A that only User A should be able to serve that
   request.  If the server allows User B to serve this request it allows
   them to illegitimately validate control of Host A to the ACME server.

Please let me know what I'm missing.

Doug

> -----Original Message-----
> From: Acme [mailto:acme-bounces at ietf.org] On Behalf Of Roland Bracewell
> Shoemaker
> Sent: Friday, February 23, 2018 3:00 AM
> To: Rich Salz <rsalz at akamai.com>
> Cc: IETF ACME <acme at ietf.org>; Martin Thomson
> <martin.thomson at gmail.com>
> Subject: Re: [Acme] ALPN based TLS challenge
>
> Here is the ID: https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-
> alpn/
>
> > On Feb 22, 2018, at 8:38 PM, Salz, Rich <rsalz at akamai.com> wrote:
> >
> > Yes, like Martin said, submit the individual draft and we can call for
adoption.
> >
>
> _______________________________________________
> Acme mailing list
> Acme at ietf.org
> https://www.ietf.org/mailman/listinfo/acme

_______________________________________________
Acme mailing list
Acme at ietf.org
https://www.ietf.org/mailman/listinfo/acme

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 29650 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180223/c908c9fd/attachment-0001.bin>