Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt

Martin Rex <mrex@sap.com> Thu, 28 July 2011 16:58 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5382D21F8BBF for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 09:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.921
X-Spam-Level:
X-Spam-Status: No, score=-9.921 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbQ3yN3ftNPp for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 09:58:54 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA1521F8BB4 for <tls@ietf.org>; Thu, 28 Jul 2011 09:58:54 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6SGwqOp020185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 18:58:52 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107281658.p6SGwpYY017791@fs4113.wdf.sap.corp>
To: paul@xelerance.com (Paul Wouters)
Date: Thu, 28 Jul 2011 18:58:51 +0200 (MEST)
In-Reply-To: <alpine.LFD.1.10.1107281000420.648@newtla.xelerance.com> from "Paul Wouters" at Jul 28, 11 10:06:30 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 28 Jul 2011 16:58:55 -0000

Paul Wouters wrote:
> 
> Eric Rescorla wrote:
> 
> >> I'm interested in knowing why you consider it "clumsy". Especially because
> >> it closely follows the RFC 6066 section 6 extension for supressing of
> >> sending CA bundles with "trusted_ca_keys".  That apparent clumsiness
> >> passed WGLC and IESG.

To be fair, the trusted_ca_keys extension was originally proposed
in rfc3546, and the document update 6066 simply did not change it.

The trusted_ca_keys TLS extension itself is a simple/lightweight extension
in that it does _not_ modify the syntax or semantics of any other
TLS handshake messages (besides the TLS extensions container in
ClientHello and ServerHello).


>
> > What's clumsy is:
> >
> > (1) It's not generic, even though generic caching is useful.
> 
> 1) It's generic for allowing an arbitrary authentication method
>    outside PKIX, which generic caching does not, as it requires
>    the TLS client to compute hashes over PKIX information.
>    In fact, the TLS client has to lie about already having the CA
>    bundle in order not to receive the PKIX blob.

In TLS WG we definitely need to keep an eye on TLS extension not
duplicating each other resulting in conflicts an interop problems.

The TLS WG had previously adopted a work item (currently dormant,
primarily because of fights over hash algorithm agility that haven't
been settled) to do caching in a generic fashion, so caching
of data from TLS handshake messages, and in particular _existing_
TLS handshake messages should IMO not be duplicated in any newly
proposed TLS extension.
 

> 
> "something better" only works with your other assumption of "sending
> and signing cruft in PKIX is fine". I strongly disagree with that.

You seem to be thinking purely about a niche area

  1) that does not have TLS at all today
  2) where you want to implement TLS newly from scratch and having
     to implement _all_ of ASN.1-ladden PKIX as a huge burden
  3) and where you do not care the slighest about interop with the
     installed base of TLS.

But in case that interop with the installed base of TLS is or may
ever become an issue, it might be worthwile thinking about implementing
the subset "X.509v1 self-signed cert" as an alternative to inventing
a new bare key format, because that is still fairly trivial to
implement and fully interoperable with the existing installed base
(OK, newer browsers have a braindead nag-ware warning page, but
 I haven't lost hope yet that they grok it one day and offer sensible
 cert pinning -- and having to regularly update bug-ridden web browsers
 is a sad fact of life we've all become used to, it's not nearly as bad
 with TLS implementations used by programmatic TLS clients and servers).


I see not having to modify syntax and semantics of existing TLS handshake
messages in order to implement a TLS extension as a big plus.

-Martin