Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd)

On Fri, 18 Nov 2011, Badra wrote:

> And how does draft-wouters-tls-oob-pubkey differ from draft-ietf-tls-cached-info-09?

cached-info still needs PKIX validation on the first run, and then supports caching
the authentication. oob-pubkey allows for out of bound public key authentication
with tls server suppressing the sending of its (often huge) unneeded PKIX chain.

This avoids conflicting information (eg between DANE and PKIX), removes the need for
(re)generating bogus PKIX containers with self signed certs and dozens of subjctAltnames
and enables CoAP devices with are lacking the resources for PKIX do engage in TLS.

Paul

> Best regards,
> Badra
> 
> On Thu, Nov 17, 2011 at 8:47 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>       Extending TLS to support a raw public key seems like a good idea and
>       I support taking it on.
>
>       Extending it to suppress the public key and instead send a hash from server
>       to the client seems less so; if the server sends the public key, it works
>       if the client knows either (a) the server public key or (b) a digest of the
>       public key. Sending a digest only works if the client already knows the
>       public key, which seems far less likely. If you want to suppress the
>       server sending the key, a better (and more general) solution is to
>       resurrect cached-info. This would work with both raw keys and
>       certificates.
>
>       -Ekr
> 
>
>       On Mon, Oct 31, 2011 at 4:21 PM, Paul Wouters <paul@xelerance.com> wrote:
>       >
>       > This is the new version of the draft incorporating the feedback from Quebec
>       > City
>       > and the TLS list since then. It changes the draft from a new TLS extension
>       > to a
>       > new Certificate Type for raw keys.
>       >
>       > It also merges in the unpublished draft material from Hannes Tschofenig
>       > and Tero Kivinen <kivinen@iki.fi> whom had also been working on raw RSA
>       > TLS keys for use with CoAP (eg devices with no real time clock where
>       > PKIX validation cannot work)
>       >
>       > I did not yet change the draft ofrom individual submission to working group
>       > item,
>       > as I was waiting for confirmation on the TLW WG list of the last Quebec City
>       > meeting.
>       >
>       > http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01
>       >
>       > Paul
>       >
>       > ---------- Forwarded message ----------
>       > Date: Mon, 31 Oct 2011 17:44:35
>       > From: internet-drafts@ietf.org
>       > Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com,
>       >    paul@xelerance.com, kivinen@iki.fi
>       > To: paul@xelerance.com
>       > Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt
>       > X-Spam-Flag: NO
>       >
>       > A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been
>       > successfully submitted by Paul Wouters and posted to the IETF repository.
>       >
>       > Filename:        draft-wouters-tls-oob-pubkey
>       > Revision:        01
>       > Title:           TLS out-of-band public key validation
>       > Creation date:   2011-10-31
>       > WG ID:           Individual Submission
>       > Number of pages: 11
>       >
>       > Abstract:
>       >   This document specifies a new TLS certificate type for exchanging raw
>       >   public keys or their fingerprints in Transport Layer Security (TLS)
>       >   and Datagram Transport Layer Security (DTLS) for use with out-of-band
>       >   authentication.  Currently, TLS authentication can only occur via
>       >   PKIX or OpenPGP certificates.  By specifying a minimum resource for
>       >   raw public key exchange, implementations can use alternative
>       >   authentication methods.
>       >
>       >   One such method is using DANE Resource Records secured by DNSSEC,
>       >   Another use case is to provide authentication functionality when used
>       >   with devices in a constrained environment that use whitelists and
>       >   blacklists, as is the case with sensors and other embedded devices
>       >   that are constrained by memory, computational, and communication
>       >   limitations where the usage of PKIX is not feasible.
>       >
>       >   The new certificate type specified can also be used to reduce the
>       >   latency of a TLS client that is already in possession of a validated
>       >   public key of the TLS server before it starts a (non-resumed) TLS
>       >   handshake.
>       >
>       >
>       >
>       >
>       > The IETF Secretariat
>       > _______________________________________________
>       > TLS mailing list
>       > TLS@ietf.org
>       > https://www.ietf.org/mailman/listinfo/tls
>       >
>       _______________________________________________
>       TLS mailing list
>       TLS@ietf.org
>       https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
>