Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd)
Badra <mbadra@gmail.com> Fri, 18 November 2011 20:02 UTC
Return-Path: <mbadra@gmail.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 033691F0C6A for <tls@ietfa.amsl.com>; Fri, 18 Nov 2011 12:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bylk0Z8PcGNh for <tls@ietfa.amsl.com>; Fri, 18 Nov 2011 12:02:08 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E3E6F1F0C58 for <tls@ietf.org>; Fri, 18 Nov 2011 12:02:07 -0800 (PST)
Received: by vbbfc26 with SMTP id fc26so600962vbb.31 for <tls@ietf.org>; Fri, 18 Nov 2011 12:02:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t6fPIQmfYE0Zvopmj4FLAr3R6gmwx96D/24oXS+Eq5c=; b=MMV+Ee7MKaYcXshve6mWj8xN4OdEKMS7yKYOdMbL6cqj7V4xddaHcGQTsZK73GAJMq 4v5I21RIBSXTnaPb37iLMYBbWm7+tolMxApnvrRc9hOvLPMKAXoWOLTRWcNI8Jb1s0Pw DbbxlcSOkdpB4IcZ/I4fVWIXhq+65z/+xiYMM=
MIME-Version: 1.0
Received: by 10.52.73.39 with SMTP id i7mr1443594vdv.44.1321646527133; Fri, 18 Nov 2011 12:02:07 -0800 (PST)
Received: by 10.220.201.71 with HTTP; Fri, 18 Nov 2011 12:02:07 -0800 (PST)
In-Reply-To: <CABcZeBOqziPWk5Je=Ld+Fa0i-vz+HXKaFTDyswptfKG6dXJkxw@mail.gmail.com>
References: <alpine.DEB.2.00.1110311914480.17385@mail.xelerance.com> <CABcZeBOqziPWk5Je=Ld+Fa0i-vz+HXKaFTDyswptfKG6dXJkxw@mail.gmail.com>
Date: Fri, 18 Nov 2011 21:02:07 +0100
Message-ID: <CAOhHAXyMneJv_-gsKiKkXcyd+03VZdBbaiamyuWm3Y2QNaxtSw@mail.gmail.com>
From: Badra <mbadra@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="bcaec5016115c4b60b04b207cf12"
Cc: tls@ietf.org
Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 18 Nov 2011 20:02:09 -0000
Hi, What happened to draft-ietf-tls-cached-info-09? And how does draft-wouters-tls-oob-pubkey differ from draft-ietf-tls-cached-info-09? 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 >
- [TLS] New Version Notification for draft-wouters-… Paul Wouters
- Re: [TLS] New Version Notification for draft-wout… Eric Rescorla
- Re: [TLS] New Version Notification for draft-wout… Ondřej Surý
- Re: [TLS] New Version Notification for draft-wout… Paul Wouters
- Re: [TLS] New Version Notification for draft-wout… Ondřej Surý
- Re: [TLS] New Version Notification for draft-wout… Marsh Ray
- Re: [TLS] New Version Notification for draft-wout… Badra
- Re: [TLS] New Version Notification for draft-wout… Paul Wouters
- Re: [TLS] New Version Notification for Martin Rex
- Re: [TLS] New Version Notification for draft-wout… Badra
- Re: [TLS] New Version Notification for draft-wout… Paul Wouters