IETF Logo Mail Archive

Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-01

Oscar Ohlsson <oscar.ohlsson@ericsson.com> Fri, 22 November 2013 09:18 UTC

Return-Path: <oscar.ohlsson@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C80C1AE337 for <mmusic@ietfa.amsl.com>; Fri, 22 Nov 2013 01:18:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZLzBq4_ueUq for <mmusic@ietfa.amsl.com>; Fri, 22 Nov 2013 01:18:44 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 660811AE32A for <mmusic@ietf.org>; Fri, 22 Nov 2013 01:18:40 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-ed-528f216854a9
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 91.84.27941.8612F825; Fri, 22 Nov 2013 10:18:32 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.247]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Fri, 22 Nov 2013 10:18:31 +0100
From: Oscar Ohlsson <oscar.ohlsson@ericsson.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: Draft new version: draft-ietf-mmusic-udptl-dtls-01
Thread-Index: Ac7mkSk0zo3yfrWATZqATJzetabOTAAyKbLg
Date: Fri, 22 Nov 2013 09:18:31 +0000
Message-ID: <C643F355C8D33C48B983F1C1EA702A4512620BF9@ESESSMB301.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C54A8AC@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C54A8AC@ESESSMB209.ericsson.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvrW6GYn+QwYe7RhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpx3DcwFu4UqOmZ8ZWlgfMLXxcjJISFgInHj5FQmCFtM4sK9 9WwgtpDAEUaJV33mXYxcQPYSRonuf4vAitgEDCRu3T/JAmKLCMRKfF33HiwuLOAgMfP0QiaI uKPEk9a17BC2kcTp5u9g9SwCqhLPLx1hBLF5BXwlLvTdZYJY5itx4tE8MJtTwE+ie0UXWC+j gKzE/e/3wHqZBcQlbj2ZD3WogMSSPeeZIWxRiZeP/7F2MXIA2YoSy/vlIMp1JBbs/sQGYWtL LFv4mhliraDEyZlPWCYwis5CMnUWkpZZSFpmIWlZwMiyipGjOLU4KTfdyGATIzDsD275bbGD 8fJfm0OM0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgPLJuq0yKzOOsg1mc BxsnvtVofvLTKUsgu3SH3GauNfaRKhcXREwOytNgWd6ZmGC+vpZRl/fBXutzK3b0zv/G161d 7ayhwH6vUNq4zEGDR/LYRHPL5bs0tvJGf7m0O5A1ZeP1uKt9bDdn5q8z0d9hvptziey7MFur M61b71xgkJvuorT9s0CVEktxRqKhFnNRcSIAEwAz5kkCAAA=
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2013 09:18:45 -0000

Hi,

I have a comment on the usage of the fingerprint attribute in draft-ietf-mmusic-udptl-dtls-01. In future versions of 3GPP TS 33.328 we would like to use UDPTL-DTLS in combination with MIKEY-TICKET.  In that case there is no exchange of certificate fingerprints; instead the offerer and answerer negotiates a secret key over SDP and then runs a DTLS-PSK handshake. The problem is that draft-ietf-mmusic-udptl-dtls-01 currently forbids other types of key management protocols:

   o  The certificate presented during the DTLS handshake MUST match the
      fingerprint exchanged via the signaling path in the SDP.

   o  If the fingerprint does not match the hashed certificate, then the
      endpoint MUST tear down the media session immediately.  Note that
      it is permissible to wait until the other side's fingerprint has
      been received before establishing the connection; however, this
      may have undesirable latency effects.

I would suggest that you make the requirements related to certificate fingerprints conditional, e.g. by adding a statement similar to this:

   In case DTLS is used with a pre-shared key ciphersuite (RFC 4279) the requirements related to certificate verification 
   and inclusion of certificate fingerprints do not apply. How the pre-shared key is made available to the endpoints 
   is out of scope of this specification. 

Regards,

Oscar Ohlsson


From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: den 21 november 2013 09:15
To: mmusic@ietf.org
Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-01

Hi fax lovers,

We've submitted a new version (-01) of draft-ietf-mmusic-udptl-dtls.

CHANGES:

In addition to some editorial fixes, the changes, based on e-mail discussions, are:

- SDP offerer is allowed to assign an a=setup:active or a=setup:passive value, in addition to the recommended a=setup:actpass 
- The example for secure fax replacing audio stream in audio-only session added 
- Editor's note on the connection attribute resolved by prohibiting usage of the SDP connection attribute 


OPEN ISSUES:

There is still an open issue in section 4.2, which is more editorial than technical. Comments and input is welcome.


Regards,

Christer

v2.23.0 | Report a Bug | By Email