[Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

Corey Bonnell <cbonnell@outlook.com> Wed, 17 April 2019 01:54 UTC

Return-Path: <cbonnell@outlook.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12761202B8 for <acme@ietfa.amsl.com>; Tue, 16 Apr 2019 18:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M91mG-BHTQgi for <acme@ietfa.amsl.com>; Tue, 16 Apr 2019 18:54:53 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-oln040092008029.outbound.protection.outlook.com [40.92.8.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C2C1201AB for <acme@ietf.org>; Tue, 16 Apr 2019 18:54:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hDEj2cBDXcWjsyWxSZ51+s6LaC8sdb/MMVHHDK4MdEg=; b=PKvqAq9z6bF90gW5AVgO7xexdx0mPXNyvPOQBrrdUA8kPAjpGTbHMCCb31hrgIhQbvtwCmL+nE/BotWKVO63b2wgDjgDHBqKmHo0/QQBpXzOHHLEVWM9zN81OX2WtqcKtZyU5h/axyX2AFU3ZDm9vJJs/OKf1j0KUDmJhI+A8ZqoFD88PPrdzkBqfH455S5RxxBcyaeK17eD5fzY1b5oI9WIHaPHqqqCeyR/Ile8ym7yDO9uSU22lkEMqXLC1bEv+J0duLeAhE0rAdO/G/RnKroHeRlA/dRVIIRvhyA2kwGyquBM9SXhieqPMmnRQGaXzlo/LPvQja8gFiwB7QkQTA==
Received: from BY2NAM03FT027.eop-NAM03.prod.protection.outlook.com (10.152.84.52) by BY2NAM03HT168.eop-NAM03.prod.protection.outlook.com (10.152.85.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1771.16; Wed, 17 Apr 2019 01:54:51 +0000
Received: from MN2PR18MB2845.namprd18.prod.outlook.com (10.152.84.58) by BY2NAM03FT027.mail.protection.outlook.com (10.152.84.237) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1771.16 via Frontend Transport; Wed, 17 Apr 2019 01:54:51 +0000
Received: from MN2PR18MB2845.namprd18.prod.outlook.com ([fe80::85a4:7183:e3da:d68a]) by MN2PR18MB2845.namprd18.prod.outlook.com ([fe80::85a4:7183:e3da:d68a%6]) with mapi id 15.20.1792.018; Wed, 17 Apr 2019 01:54:51 +0000
From: Corey Bonnell <cbonnell@outlook.com>
To: "acme@ietf.org" <acme@ietf.org>
Thread-Topic: SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
Thread-Index: AQHU9L+epzmXNs4yDUG9lMQgYbElSA==
Date: Wed, 17 Apr 2019 01:54:51 +0000
Message-ID: <MN2PR18MB28457CCBEF6FFE2B70E286FCC3250@MN2PR18MB2845.namprd18.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:3D365660BCF46D8650A38A4A84E53FDC36460377C73E44B48F3253E1A2056CC7; UpperCasedChecksum:083BE43410B8381DB0F3F86F98E313DDEB30DCEA6256CEA99B3A557EED8AFB1B; SizeAsReceived:6590; Count:41
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [zlEBs26RTyPVPUjYjqt870aPOCL3eG5Z]
x-ms-publictraffictype: Email
x-incomingheadercount: 41
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:BY2NAM03HT168;
x-ms-traffictypediagnostic: BY2NAM03HT168:
x-microsoft-antispam-message-info: CbYciYMQhUeFe8rMVakTULhM2Z6iGJnBS2XSFmmR9csSVIvIhzpW73h8eEBpBTo2Kax2ri+QgavTVGHlnExt5RPYKbrJV5+XAA4HM3+hrSAZOw2Kzr8P0T3HrMyrDxLNBJwCJaDoBx9M9lgNBi4a8kmHYEywnwkQ5aZ3QRRsn0cWeWpSfUN1UbA/vK00lxRP
Content-Type: multipart/alternative; boundary="_000_MN2PR18MB28457CCBEF6FFE2B70E286FCC3250MN2PR18MB2845namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: c93a8746-f12e-4c7d-1b9a-08d6c2d7ae22
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 01:54:51.4251 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM03HT168
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/ozLtQbqUUOivVFPCAAkeQ2C8MX4>
Subject: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2019 01:54:56 -0000

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