Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
On Tue, Apr 16, 2019 at 9:55 PM Corey Bonnell wrote: > Hello, > > Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge, an > SNI value with the in-addr/ipv6.arpa domain name corresponding to the > iPAddress being validated MUST be specified. I have a concern that this > requirement suffers the same problem that rendered tls-sni-01 insecure: > namely, an arbitrary user on a shared hosting provider could upload an > arbitrary certificate for the required .ip-addr/ipv6.arpa domain, thus > circumventing any security provided by the mandatory SNI extension. > > The mandatory ALPN extension prevents this from being exploited to obtain > fraudulent certificates, but given how trivially the SNI requirement can be > defeated in the same manner as for tls-sni-01, I don’t believe that > requiring SNI provides any security value and is not necessary. If the > intent for requiring the SNI extension is to convey to the TLS server that > an IP address is being validated, couldn’t that similarly be accomplished > by *not* specifying any SNI extension at all? Tls-apln-01 (for dNSNames) > requires that a SNI value be specified, so TLS servers could differentiate > between challenge requests for dNSNames and iPAddress based on the presence > (or absence) of the SNI extension. > I’m not sure I follow the attack scenario you’re describing.. The value proposition of the ALPN method is that it’s indicative that the server does not “suffer the same problem that rendered sni-01 insecure”, precisely because it does not allow an arbitrary user to upload an arbitrary certificate while also responding with that ALPN identifier. Perhaps I misunderstood your question, but with the above invariant being the reason for the introduction of the ALPN method, if we assume it holds, do you still have concerns? > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
Hello, Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge, an SNI value with the in-addr/ipv6.arpa domain name corresponding to the iPAddress being validated MUST be specified. I have a concern that this requirement suffers the same problem that rendered tls-sni-01 insecure: namely, an arbitrary user on a shared hosting provider could upload an arbitrary certificate for the required .ip-addr/ipv6.arpa domain, thus circumventing any security provided by the mandatory SNI extension. The mandatory ALPN extension prevents this from being exploited to obtain fraudulent certificates, but given how trivially the SNI requirement can be defeated in the same manner as for tls-sni-01, I don’t believe that requiring SNI provides any security value and is not necessary. If the intent for requiring the SNI extension is to convey to the TLS server that an IP address is being validated, couldn’t that similarly be accomplished by *not* specifying any SNI extension at all? Tls-apln-01 (for dNSNames) requires that a SNI value be specified, so TLS servers could differentiate between challenge requests for dNSNames and iPAddress based on the presence (or absence) of the SNI extension. Thanks, Corey ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] draft-ietf-acme-ip-05
Hey Kathleen, I'm not clear on what you're after here. Do you see something in here forbidding use for client certificates that needs to be removed? Do you think there needs to be some explanation of how to put the right EKU in the CSR? It might help if you could submit a PR. --Richard On Tue, Apr 16, 2019 at 12:25 PM Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > Hello, > > In the ACME meeting, I had asked if this draft could have text added to > address how client certificates could be generated since this was written > specific to server certificates, but could easily be extended as the > difference in most cases would just be in the CSR. Could this text be > added so the IP address use case for devices could be covered in one > document? > > Thank you! > > -- > > Best regards, > Kathleen > ___ > 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
[Acme] draft-ietf-acme-ip-05
Hello, In the ACME meeting, I had asked if this draft could have text added to address how client certificates could be generated since this was written specific to server certificates, but could easily be extended as the difference in most cases would just be in the CSR. Could this text be added so the IP address use case for devices could be covered in one document? Thank you! -- Best regards, Kathleen ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] AD review: draft-ietf-acme-ip-05
Hi! I'm pickup up where ekr left off on draft-ietf-acme-ip. I see that -05 addressed some of the feedback from: https://mailarchive.ietf.org/arch/msg/acme/bGQtdDZ8i75t3dCt3EjPHxsGoG4 I have a few other items: (1) A bit of clean-up is needed in the references: ** [FIPS180-4] [RFC4291] [RFC4648] appear in the references but are not cited in the text ** [I-D.ietf-acme-acme] is now RFC8555 (2) Missing security considerations. It appears that in pruning the text from -04 to -05, this required section was dropped. Among other things, please include the clarity suggested here: https://mailarchive.ietf.org/arch/msg/acme/j8peTskrxupK0AyJyJomS99iOqw (3) Section 8.1 -- I recommend clearer language in the IANA considerations 8.1 by fully spelling out the registry names and ensure the registry column names align with this text: OLD: Adds a new type to the Identifier list defined in Section 9.7.7 of [I-D.ietf-acme-acme] with the label "ip" and reference I-D.ietf-acme-ip. NEW: Adds a new type to the "ACME Identifier Types" registry defined in Section 9.7.7 of [RFC8555] with a Label "ip" and Reference to this draft. (4) Section 8.2 - I think the intent of this IANA action is to have "ip" be an Identifier Type for the Labels "http-01" and "tls-alpn-01" in "ACME Validation Methods" registry. This text isn't clear to me on execution - is text proposing (option #1) to modifying the existing entry in the registry (my read of the text, but two identifier types doesn't seem to be supported in the RFC8555 text), or (option #2) add another registry entry? Is it: (option #1) http-01, dns and ip OR (option #2) http-01, dns http-01, ip Regards, Roman ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
