Subject: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt

From: [email-masked]
Date: Fri, 02 Mar 2018 18:35:03 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment WG of the IETF.

        Title           : ACME TLS ALPN Challenge Extension
        Author          : Roland Bracewell Shoemaker
	Filename        : draft-ietf-acme-tls-alpn-00.txt
	Pages           : 7
	Date            : 2018-03-02

Abstract:
   This document specifies a new challenge for the Automated Certificate
   Management Environment (ACME) protocol which allows for domain
   control validation using TLS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-00
https://datatracker.ietf.org/doc/html/draft-ietf-acme-tls-alpn-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 6 Mar 2018 00:37:41 +0000

I'm generally supportive of this, but one concern I do have, and I admit
I'm mostly just thinking aloud here, is that we are slowly accumulating a
larger and larger number of things that look like certificates, but aren't
due to people playing games with critical extensions.

I think we may come to regret using that trick so much.  Such schemes
are only one software bug away from having rather profound effects
on trust decisions and the entire ecosystem.

The trick is one of the more ugly parts of certificate transparency, and I 
would encourage people to think about whether it is possible to 
accomplish what this draft is trying to accomplish without repeating that 
mistake.

-Tim

> -----Original Message-----
> From: Acme [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Friday, March 2, 2018 7:35 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt
> 
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 5 Mar 2018 16:42:15 -0800

> on trust decisions and the entire ecosystem.
This is a good point, but an important mitigating factor is that these
are self-signed certificates, as compared to CT's precertificates, which
are signed by a trusted issuer but poisoned. And they are only presented
when the acme/1 ALPN is negotiated. So you'd need three software bugs,
each of which would be a game-over bug on its own:

 - ignoring a critical extension
 - trusting a self-signed certificate
 - sending acme/1 ALPN for non-validation traffic

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 6 Mar 2018 00:49:19 +0000

That's a fair point.  Although note that critical extension bugs don't tend
to be
of the "ignore critical extension" variety (though that happens), they tend
to be 
of the "understand the critical extension for the purposes of rejecting it
and then 
getting the logic backwards" or something similar.

The self-signedness is probably the most important mitigating factor ... we
might
want to make sure that the draft has enough requirements to make sure that
the margin of error is two to three software bugs in all compliant
implementations, 
and is never just one.

-Tim

> From: Jacob Hoffman-Andrews [mailto:[email-masked]]
> Sent: Monday, March 5, 2018 5:42 PM
> To: Tim Hollebeek <[email-masked]>; [email-masked]
> Subject: Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt
> 
> > are only one software bug away from having rather profound effects on
> > trust decisions and the entire ecosystem.
> This is a good point, but an important mitigating factor is that these are
self-
> signed certificates, as compared to CT's precertificates, which are signed
by a
> trusted issuer but poisoned. And they are only presented when the acme/1
> ALPN is negotiated. So you'd need three software bugs, each of which would
be
> a game-over bug on its own:
>

---

From: Corey Bonnell <[email-masked]>
Date: Fri, 9 Mar 2018 16:22:22 +0000

Hello,
I read over draft-ietf-acme-tls-alpn-00 and noticed two things:
1) Section 3 states, " If all of the above steps succeed then the validation is successful, otherwise it fails.  Once the handshake has been completed the connection should be immediately closed and no further data should be
   exchanged". Perhaps I'm reading this too literally, but I think this is ambiguous, where "handshake" can mean either the TLS handshake in its entirety (such as sending ChangedCipherSpec/Finished messages, etc.) or if the connection should be terminated upon the client receiving the ServerHello message (which is the entirety of the "handshake" described in steps 1-3). I imagine the former is preferable, so the wording should perhaps explicitly specify "TLS handshake".
2) Section 5 (IANA considerations) has no mention of updating the IANA "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids) with the new ALPN identifier "acme-tls/1". For consistency with other documents that define ALPN identifiers, "acme-tls/1" should probably be added to the registry.

Thanks,
Corey
 
Corey Bonnell
Trustwave | SMART SECURITY ON DEMAND

On 3/2/18, 9:35 PM, "Acme on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    
    Abstract:

    The IETF datatracker status page for this draft is:
    https://scanmail.trustwave.com/?c=4062&d=3oma2gDctiWeny5cn5DkGORX4VGQZeWcDcJBnrjUUw&s=5&u=https%3a%2f%2fdatatracker%2eietf%2eorg%2fdoc%2fdraft-ietf-acme-tls-alpn%2f
    
    There are also htmlized versions available at:
    https://scanmail.trustwave.com/?c=4062&d=3oma2gDctiWeny5cn5DkGORX4VGQZeWcDcUSzejVAQ&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2fdraft-ietf-acme-tls-alpn-00
    https://scanmail.trustwave.com/?c=4062&d=3oma2gDctiWeny5cn5DkGORX4VGQZeWcDZYWlLnWVQ&s=5&u=https%3a%2f%2fdatatracker%2eietf%2eorg%2fdoc%2fhtml%2fdraft-ietf-acme-tls-alpn-00

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at http://scanmail.trustwave.com/?c=4062&d=3oma2gDctiWeny5cn5DkGORX4VGQZeWcDcRGzujXDg&s=5&u=http%3a%2f%2ftools%2eietf%2eorg

    _______________________________________________
    Acme mailing list
    [email-masked]
    https://scanmail.trustwave.com/?c=4062&d=3oma2gDctiWeny5cn5DkGORX4VGQZeWcDcJEnbHYBQ&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2facme