IETF Logo Mail Archive

Re: [rtcweb] DTLS version for RTCweb

"Olle E. Johansson" <oej@edvina.net> Fri, 10 May 2013 10:02 UTC

Return-Path: <oej@edvina.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6221021F8CEC for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 03:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 meu5WSD-0-Tk for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 03:02:19 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 8541321F8BBC for <rtcweb@ietf.org>; Fri, 10 May 2013 03:02:19 -0700 (PDT)
Received: from [IPv6:2001:16d8:cc57:1000::42:1004] (unknown [IPv6:2001:16d8:cc57:1000::42:1004]) by smtp7.webway.se (Postfix) with ESMTPA id 6B77093C1AF; Fri, 10 May 2013 10:02:18 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <28F36C49-E542-4AD6-9124-8325744FC5A4@phonefromhere.com>
Date: Fri, 10 May 2013 12:02:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1133B8BC-610C-4E2C-99A2-BCAFBB301349@edvina.net>
References: <518C1921.1010606@acm.org> <CEDD7FB9-8183-41D7-B771-DF38A747D4A0@phonefromhere.com> <2EFCE543-0532-4F6F-8E67-1109DA5DA257@edvina.net> <3A89513C-534A-44CD-914F-D2D533BF6687@edvina.net> <28F36C49-E542-4AD6-9124-8325744FC5A4@phonefromhere.com>
To: Tim Panton <tim@phonefromhere.com>
X-Mailer: Apple Mail (2.1503)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] DTLS version for RTCweb
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 May 2013 10:02:20 -0000

10 maj 2013 kl. 11:47 skrev Tim Panton <tim@phonefromhere.com>:

> 
> On 10 May 2013, at 10:24, Olle E. Johansson wrote:
> 
>> 
>> 10 maj 2013 kl. 11:12 skrev "Olle E. Johansson" <oej@edvina.net>:
>> 
>>> 
>>> 10 maj 2013 kl. 11:08 skrev Tim Panton <tim@phonefromhere.com>:
>>> 
>>>> 
>>>> 
>>>> On 9 May 2013, at 22:46, Marc Petit-Huguenin wrote:
>>>> 
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>> 
>>>>> I read the various security drafts and it looks like they all reference DTLS
>>>>> 1.0 (RFC 4347), but RFC 4347 was obsoleted by RFC 6247.  So will the
>>>>> references being updated to use DTLS 1.2 as the base version, or will DTLS 1.0
>>>>> stay as the base version, with possibility of negotiation to 1.2 and higher?
>>>> I think we should move to 1.2 - There are specific cases where 1.0 doesn't exactly do what we
>>>> want. 
>>>> 
>>>> e.g. I think for a server to ask for a client cert, technically in 1.0 you are supposed to list the CA's
>>>> you are interested in and you'll only receive certs from those CAs. In 1.2 you can leave this
>>>> empty and get a list of all certs (effectively a CA wildcard). 
>>> 
>>> What? Will any server get a list of all my private certs? That sems to me like a big fat privacy issue.
>> From RFC 5246 (TLS 1.2) that DTLS 1.2 refers to:
>> 
>> "If
>>     the certificate_authorities list is empty, then the client MAY
>>     send any certificate of the appropriate ClientCertificateType,
>>     unless there is some external arrangement to the contrary."
>> 
>> This doesn't mean that you will get all, but that the client can select any certificate in the 
>> cert store to present to the server. Previously the server had to present a list of 
>> acceptable CAs. It does open for self-signed certs, really. If you by other means have
>> established trust for a self-signed cert, you can use it as a client cert in TLS 1.2. The
>> server doesn't have to trust a CA, but can trust a specific cert.
>> 
>> This goes hand in hand with DANE.
>> 
>> /O
> 
> But that language isn't in TLS 1.0 - the list can't be empty.

Right. It's a good improvement but doesn't really work as you say - that you will et a list
of all my certs...

/O

v2.23.0 | Report a Bug | By Email