Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 13 May 2015 10:23 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114CA1B2A94 for <tls@ietfa.amsl.com>; Wed, 13 May 2015 03:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 RCD5yCA_so2z for <tls@ietfa.amsl.com>; Wed, 13 May 2015 03:23:24 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438421B2A93 for <tls@ietf.org>; Wed, 13 May 2015 03:23:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1431512604; x=1463048604; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=GK/fhZ+Q6tsn85i9MKABB44aNSZK9zzydd13we2zP3c=; b=ZPMuHG9WgXY7mbPq4teIBeo+VLLN/4ZLvBZcb6nC6Ynll7efq8U9ICp0 j7TKQETBK1Y7EfcqeY1+wUBp9BGXJEbHDTwlyNls14S9989p/EyJvaHMP 7f2H0Nd4grL/8xasiUhDrfJRbq6cYKZ49Z6DCIlMpDzoVLrHq2QO3UA/F U=;
X-IronPort-AV: E=Sophos;i="5.13,420,1427713200"; d="scan'208";a="5008525"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 13 May 2015 22:23:22 +1200
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 13 May 2015 22:23:21 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
Thread-Index: AdCNZtX0Kozv4h0+SPSSG9VnfrD5Ww==
Date: Wed, 13 May 2015 10:23:20 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB01D53C@uxcn10-tdc05.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/oHU7UBgMsjFc9UAd7ciF-EViHMs>
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2015 10:23:29 -0000

Martin Rex <mrex@sap.com> writes:

>When you use the AIA OCSP or CRLDP information from a certificate during
>certificate path validation, you do this only after you have verified the CA
>signature on the certificate,

Possibly, but when you use the AIA CA information to find the CA cert to
validate the one you've got, you're using unvalidated data.

Also, OCSP has a great facility (serviceLocator) for an untrusted client to
tell the server to access any location the client tells it to [0].  It's a
great way to scan the CA's internal network, walk up the IP address range at
port 445 and time the responses.  I didn't try any further tricks, but if I'd
passed it on to some pen-tester friends I'm sure they could have had some fun
with the capability.

>but the issues that you listed do not make the OCSP responder location and
>CRLDP info within that certificate untrustworthy.

No, OCSP has its own built-in mechanisms for doing that.  In addition the CA
AIA is untrustworthy, because you need to process the cert and use the AIA in
order to verify whether the information that you've just acted on is legit.

Peter.

[0] Another one of the many "what *were* they thinking" things you can find by
    reading PKI RFCs.