Re: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-03

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 29 January 2014 09:58 UTC

Return-Path: <christer.holmberg@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 80D3C1A04DA for <mmusic@ietfa.amsl.com>; Wed, 29 Jan 2014 01:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 56yTXIx-XhB5 for <mmusic@ietfa.amsl.com>; Wed, 29 Jan 2014 01:58:14 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9A21A037D for <mmusic@ietf.org>; Wed, 29 Jan 2014 01:58:14 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-1d-52e8d0b2f224
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E5.C8.10875.2B0D8E25; Wed, 29 Jan 2014 10:58:11 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0387.000; Wed, 29 Jan 2014 10:58:10 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, "Adam Gensler (agensler)" <agensler@cisco.com>
Thread-Topic: Review of draft-ietf-mmusic-udptl-dtls-03
Thread-Index: AQHPF6Z7X1rBlQF7JUm0AYYGqOYxvZqRgxMAgAn+m0A=
Date: Wed, 29 Jan 2014 09:58:09 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D148F76@ESESSMB209.ericsson.se>
References: <CEFF0353.44C3%agensler@cisco.com> <A3B5E35A-BE7B-41F2-84C6-BF4565772A95@cisco.com>
In-Reply-To: <A3B5E35A-BE7B-41F2-84C6-BF4565772A95@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje7mCy+CDB6FWCz9fofNYu4UP4up yx+zODB7TPm9kdVjyZKfTAFMUVw2Kak5mWWpRfp2CVwZ/X8amQq2yVWcvtHG2sC4XaKLkYND QsBE4tLnkC5GTiBTTOLCvfVsXYxcHEIChxglVr99ygrhLGaUmL9gFRtIA5uAhUT3P22QBhGB TInP05azg9jMAjISM842MoHYwgJmEufunmeDqDGXaJ56lxGkVUTASuLC0SyQMIuAqsS2+T9Z QWxeAV+JRWsmgLUKCSRK9Kw6yAJicwrYSpz/fAxsPCPQbd9PrWGCWCUucevJfCaImwUkluw5 zwxhi0q8fPyPFcJWkvix4RILRL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMbLnJmbmpJcbbmIERsnBLb91dzCeOidyiFGag0VJnPfDW+cgIYH0xJLU7NTU gtSi+KLSnNTiQ4xMHJxSDYwuOVk+8bfMp58pssrL53qkI1G98ujH2aG8PQu4+PJc7z9+ppPe yaN27gHvto4fxd92ljtXOB89NU9xU/ELXZ2J5r+4tPY9re7dtEZqB/vq4Abdm0K7qywvNe5x ieX6YWlu+jX4/aY2ibmlLk+Wq368fKjz2d9DTGnifXLc7YXXHm34537d9IcSS3FGoqEWc1Fx IgDrn07/YAIAAA==
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-03
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: Wed, 29 Jan 2014 09:58:16 -0000

Hi Adam,

Again, thanks for your review! See my comments inline.

> After speaking with Gonzalo I've reviewed draft-ietf-mmusic-udptl-dtls-03.
> Overall this draft is excellent and appears to cover all the corner 
> cases I could think of. I do have a few comments, see below:
> 
> 1. In section 3.1, secure channel establishment, there is the 
> following text:
> 
> "If the endpoint supports, and is willing to use, a cipher suite with 
> an associated certificate, it MUST include an SDP fingerprint 
> attribute [RFC4572 <http://tools.ietf.org/html/rfc4572>] in the SDP."
> 
> "If a cipher suite with an associated certificate is selected during 
> the DTLS handshake, the certificate received during the DTLS handshake 
> MUST match the fingerprint received in the SDP fingerprint attribute."
> 
> To me this seems to indicate the particular cipher suites are 
> associated with a particular certificate. While it's true that the 
> certificate plays a role in overall TLS negotiation, it does not 
> provide a list of ciphers to use.

The intention of the text is NOT to indicate that a particular cipher suites are associated with a particular certificate. 

> I think what this is saying is that
> if the client wishes to use a certificate for DTLS it should provide a 
> certificate fingerprint. Is that right?

Only if the cipher suite has an associated certificate.

But, e.g. a PSK based cipher suite  (RFC4279) has no associated certificate and thus there is no point of indicating certificate fingerprint for PSK based cipher suite.

> Given the overall complexity of PKI in general I think being extra clear here would help avoid any confusion.

We did spend quite a bit of time on this part of the text, and I can't see what modifications I should do in order to make it more clear.

------------------------

> 2. Section 4.1 describes handling anonymous faxes with freshly 
> generated self-signed certificates. It goes on to say:
> 
> "...and the content of the subjectAltName attribute inside the 
> certificate MUST NOT contain information that either allows 
> correlation or identification of the user making anonymous calls."
> 
> While the subjectAltName could potentially have identifiable data in 
> it, it is not always present as a field within the certificate. Some 
> certificates may have a subjectAltName, some may not. However, all 
> certificates should have a commonName. I think that is the item that 
> should be specifically called out as a place to avoid identifiable 
> information. Or, perhaps, simply stipulating that no fields within the 
> certificate should contain identifiable information.

That's a good point.

What about something like:

                "...and attributes inside the certificate SHALL NOT contain information that either allows correlation or
                identification of the user making anonymous calls. This is particularly important for the subjectAltName 
                and commonName attributes"

------------------------

> 3. Section 4.3 describes rekeying a connection that is established. 
> The DTLS RFC describes how to handle this, but gives two options to an 
> endpoint where out-of-order packets are received that have been 
> encrypted with different keys; discard the packet, or, retain two sets 
> of keying material for some recommended interval. DTLS is not specific 
> as to what to do here. Section 4.3 says the receiver SHOULD maintain 
> the keying material. Given the nature of T.38, I think it may be 
> prudent to say the receiver MUST maintain the keying material.
> Dropping and/or discarding
> T.38 packets would never be my preference.

We can change it to MUST.

------------------------

Regards,

Christer