Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd)
Ondřej Surý <ondrej.sury@nic.cz> Thu, 17 November 2011 17:07 UTC
Return-Path: <ondrej.sury@nic.cz>
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 1F93B21F9A06; Thu, 17 Nov 2011 09:07:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3]
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 RotQlMHMpD83; Thu, 17 Nov 2011 09:06:59 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D540721F9A01; Thu, 17 Nov 2011 09:06:58 -0800 (PST)
Received: from [192.168.100.100] (61-220-70-183.HINET-IP.hinet.net [61.220.70.183]) by mail.nic.cz (Postfix) with ESMTPSA id BF2442A2B86; Thu, 17 Nov 2011 18:06:55 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321549617; bh=F9MqqeIRy7vogaW/a9XrXqD5vuigSSEAVvnJAYptl3o=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pBYYJIlt4LGR7sE+HJjO8/hD96e+jaCh7MN4tBL1WLciIG4d3PWwUrIc4NO6RuU0I I7vxZZoi+gPaNi0I3GvOX6Luc9gODk9hk0rBwSX4NsmxTNy4d8oSK4CyFPRaG8eyLb Fuwkz70FOHg6zCYDo0Xlk+ofSv6dCzdqgo85GSCo=
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="utf-8"
From: Ondřej Surý <ondrej.sury@nic.cz>
In-Reply-To: <alpine.DEB.2.00.1111171111410.19177@mail.xelerance.com>
Date: Fri, 18 Nov 2011 01:06:52 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA59D9A0-5A74-4ADC-B5F6-161B5A14AC8E@nic.cz>
References: <alpine.DEB.2.00.1110311914480.17385@mail.xelerance.com> <8766068B-882E-41F9-B908-49088E451F03@nic.cz> <alpine.DEB.2.00.1111171111410.19177@mail.xelerance.com>
To: Paul Wouters <paul@xelerance.com>
X-Mailer: Apple Mail (2.1251.1)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: tls@ietf.org, dane@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: Thu, 17 Nov 2011 17:07:11 -0000
On 18. 11. 2011, at 0:20, Paul Wouters wrote: > On Thu, 17 Nov 2011, Ondřej Surý wrote: > > The -02 draft went out before I could respond to this.... > >> could you please drop this sentence from your draft? >> >> For example, if public keys were obtained using [DANE] it >> is appropriate to use DNSSEC to authenticate the public keys. >> >> I know that it's just an example, but I can see that this could >> lead to chaos and mayhem if the DANE protocol makes different >> assertion in the future. So unless DANE protocol blooms into the >> RFC before your draft, please don't make any assumptions, thanks. > > Though I see your point, I cannot really see any case where a TLS > implementation would obtain a public key from DNS without any PKIX > information and without any DNSSEC protection. In this case there is > not even the PKIX fallback information to go on, so regardless of what > DANE decides to do for "validatable PKIX", a TLS client MUST NOT use > a TLSA record containing just a public key if it did not authenticate > that data with DNSSEC. I think it's perfectly fine to say, what you are saying in the first part of the paragraph: Depending on exactly how the public keys were obtained, it may be appropriate to use authentication mechanisms tied to the public key transport. but I object to saying what that means in the other (DANE) protocols. Or speak about the protocols which have the security properties already defined (LDAPS?). > Perhaps it can be reworded? But I think it is a valid security concern > to point out people should not just pluck spoofable TLSA records from > DNS and build a TLS trust relationship based on that. I agree with you, but this is not the place to say that. > Even if DANE > decided to always mandata DNSSEC, I think it is a good reminder to > make that explicit in the Security Considerations here? You can reword it to make it more general - less DANE-centric. >> And one minor nit, change >> >> Some small embedded devices use the UDP based [CoAP], a specialized >> constrained networks and nodes for machine-to-machine applications. >> >> to >> >> Some small embedded devices use the UDP based Constrained Application >> Protocol [CoAP], a specialized web transfer protocol for use with >> constrained networks and nodes for machine-to-machine applications. >> >> or simpler >> >> Some small embedded devices use the UDP based Constrained Application >> Protocol [CoAP] for use with constrained networks and nodes for >> machine-to-machine applications. >> >> for better readability. > > Thanks. I've made the changes and the will be in the next draft. > > Paul > >> On 1. 11. 2011, at 7:21, Paul Wouters 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 >> >> -- >> Ondřej Surý >> vedoucí výzkumu/Head of R&D department >> ------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC >> Americka 23, 120 00 Praha 2, Czech Republic >> mailto:ondrej.sury@nic.cz http://nic.cz/ >> tel:+420.222745110 fax:+420.222745112 >> ------------------------------------------- >> -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------
- [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