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

mrex@sap.com (Martin Rex) Tue, 12 May 2015 19:29 UTC

Return-Path: <mrex@sap.com>
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 CF4011A87BB for <tls@ietfa.amsl.com>; Tue, 12 May 2015 12:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 t_ez1OFkvWCz for <tls@ietfa.amsl.com>; Tue, 12 May 2015 12:29:54 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93CC1A87B0 for <tls@ietf.org>; Tue, 12 May 2015 12:29:53 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 69BEE2A8C0; Tue, 12 May 2015 21:29:51 +0200 (CEST)
X-purgate-ID: 152705::1431458991-0000413A-C2791023/0/0
X-purgate-size: 2724
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D8EAB41399; Tue, 12 May 2015 21:29:50 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C93F21B2EB; Tue, 12 May 2015 21:29:50 +0200 (CEST)
In-Reply-To: <8d15ecf26f59aecebe0e210c95e68cea.squirrel@webmail.dreamhost.com>
To: ryan-ietftls@sleevi.com
Date: Tue, 12 May 2015 21:29:50 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PTgn7s4Cn6JSVcP4IcWkS4Vlxw0>
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
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
Reply-To: mrex@sap.com
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: Tue, 12 May 2015 19:29:56 -0000

Ryan Sleevi wrote:
> On Tue, May 12, 2015 11:54 am, Martin Rex wrote:
> >  X.509 would require an omniscient trusted directory to perform certificate
> >  path discovery, and the Certificate Path Validation algorithm in
> >  rfc5280 section 6.1 clearly rules out AIA chasing as a permissible
> >  approach for certificate path discovery, because this approach would
> >  be clearly insecure and irresponsible.
> 
> Again, Martin, you're making unsubstantiated and inaccurate claims.
> 
> To the extent it's relevant to the discussion for the TLS WG, I will
> simply note that RFC 5280 does not say anything about path discovery
> precisely because discovery is out of scope for validation. Validation is
> consistent, while discovery depends on a myriad of cases and protocols
> outside of the narrow view of TLS. e.g. the validation of certificates in
> PKCS#7 or in S/MIME.
> 
> So yes, RFC 5280 doesn't discuss how to do path discovery, because it's
> out of scope, even though it repeatedly describes extensions and options
> for how to do path discovery *that rely on parsing the untrusted
> certificate*

*Parsing* an untrusted certificate is not the problem.

But doing _more_ than comparing contents to something you trust is
where the security problem starts.  


> 
> RFC 5280 does not call AIA chasing as insecure, and in fact, acknowledges
> it exists precisely to make discovery possible.


With the prerequisite of a conscious and informed active consent by a human
administrator during out-of-band maintenance/administration, using AIA to
download a certificate can be an accetable security trade-off.

But a machine/automata/algorithm that will automatically download objects
from URLs from still-untrusted data provided by the peer is definitely
insecure and irresponsible.


> 
> However, to the points at hand, at least it establishes why you object to
> the change. You view it as predicated upon a fundamentally insecure
> algorithm. While I (and many others, as evidenced by implementation and
> discussion) would disagree with you, and I personally feel your claims of
> standards imprimatur to be lacking, it at least provides a clear rationale
> for your disagreement.
> 
> I don't think it'd be helpful for consensus building for me to try and
> demonstrate where I think even RFC 5280 would disagree with your
> conclusions, but if others feel themselves swayed by Martin's arguments, I
> would be happy to add that fuel to the discussion.
 

I'm still waiting for an example why you would need to send junk in
the Certificate handshake message, which could not be avoided by the
offending CAs issuing proper crossCAs instead.

-Martin