Subject: [Acme] Benjamin Kaduk's Yes on draft-ietf-acme-tls-alpn-06: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 30 Sep 2019 18:07:28 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-tls-alpn-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please respond to the ARTART review; there's some good comments in there
about constraining the permitted TLS versions/algorithms, the specifics
of the acme-tls/1 (non-)protocol, the use of a different certificate
model than RFC 5280, and the (non-)need to complete the TLS handshake.

Section 1

"Because no existing software implements this protocol" is not going to
age well; perhaps an approach more like "Because this protocol does not
build on a preexisting deployment base" would do better.

Section 7

   the provider.  When the TLS SNI challenge was designed it was assumed
   that a user would only be able to respond to TLS traffic via SNI for
   domain names they controlled (i.e. if User A registered Host A and
   User B registered Host B with a service provider that User A wouldn't
   be able to respond to SNI traffic for Host B).  This turns out not to
   be a security property provided by a number of large service
   providers.  [...]

Perhaps I'm misremembering, but I don't think this characterizes exactly
the situation that led to the TLS SNI challenge being deemed
irredeemable: the issues arise when User B *has not yet* registered Host
B, and either the registration validation at the provider was lax or
User A could connive to get into the default-SNI handler.  The *attack*
was possible even when User B has registered Host B, because the
validation used a subdomain, as we discuss below, but here we are
talking about the SNI routing, which needed to be for an unregistered
(or not-validly-registered) name.