Does this prevent an advisory from setting up their own "hosting provider"
and getting certificates for any domain on the internet?  We can’t assume
all landlords are good.

Doug

> -----Original Message-----
> From: Sebastian Nielsen [mailto:sebast...@sebbe.eu]
> Sent: Friday, February 23, 2018 9:43 AM
> To: Doug Beattie <doug.beat...@globalsign.com>; 'Roland Bracewell
> Shoemaker' <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> Cc: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> <martin.thom...@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-boun...@ietf.org] För Doug Beattie
> Skickat: den 23 februari 2018 14:18
> Till: Roland Bracewell Shoemaker <rol...@letsencrypt.org>; Rich Salz
> <rs...@akamai.com>
> Kopia: IETF ACME <acme@ietf.org>; Martin Thomson
> <martin.thom...@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-boun...@ietf.org] On Behalf Of Roland Bracewell
> > Shoemaker
> > Sent: Friday, February 23, 2018 3:00 AM
> > To: Rich Salz <rs...@akamai.com>
> > Cc: IETF ACME <acme@ietf.org>; Martin Thomson
> > <martin.thom...@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 <rs...@akamai.com> wrote:
> > >
> > > Yes, like Martin said, submit the individual draft and we can call for
> adoption.
> > >
> >
> > _______________________________________________
> > 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to