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

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 22 Jan 2014 19:19:40 +0000

Thanks very much for your detailed review, Adam.  I'm copying the MMUSIC@ list for awareness.

Cheers,

Gonzalo

On Jan 22, 2014, at 2:16 PM, Adam Gensler (agensler) <[email-masked]> wrote:

> Gonzalo, Christer,
> 
> 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. 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? Given the overall complexity of PKI in general I think being extra
> clear here would help avoid any confusion.
> 
> 
> 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.
> 
> 
> 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.
> 
> If there's any questions or concerns about the above please let me know.
> 
> Best regards,
> Adam Gensler
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2014 01:43:38 +0000

Hi Adam,

Thank You very much for the review! I am currently on a business trip, but I'll address your comments asap.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Gonzalo Salgueiro (gsalguei) [mailto:[email-masked]] 
Lähetetty: 22. tammikuuta 2014 21:20
Vastaanottaja: Adam Gensler (agensler)
Kopio: Gonzalo Salgueiro (gsalguei); Christer Holmberg; mmusic
Aihe: Re: Review of draft-ietf-mmusic-udptl-dtls-03
Tärkeys: Suuri

Cheers,

Gonzalo

On Jan 22, 2014, at 2:16 PM, Adam Gensler (agensler) <[email-masked]> wrote:

> 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:
> 
> "If the endpoint supports, and is willing to use, a cipher suite with 
> an associated certificate, it MUST include an SDP fingerprint 
> attribute
> "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. 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? Given the overall complexity 
> of PKI in general I think being extra clear here would help avoid any confusion.
> 
> 
> 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 
> 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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Jan 2014 09:58:09 +0000

Hi Adam,

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

> 1. In section 3.1, secure channel establishment, there is the 
> following text:
> 
> attribute [RFC4572 <http://tools.ietf.org/html/rfc4572>] in the SDP."
> 
> 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
> 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.

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

> 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"

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

> T.38 packets would never be my preference.

We can change it to MUST.

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

Regards,

Christer

---

From: "Adam Gensler (agensler)" <[email-masked]>
Date: Fri, 31 Jan 2014 17:09:51 +0000

Christer,

Sorry for the delay, I've been offline for a few days. See inline with
[adam]:

On 1/29/14, 4:58 AM, "Christer Holmberg" <[email-masked]>
wrote:

>The intention of the text is NOT to indicate that a particular cipher
>suites are associated with a particular 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
>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.
>
>------------------------

[adam] Thanks for the clarification here. Given this extra context I agree
and I'm not sure how to adjust this any further.

>                "...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

[adam] This sounds good to me.

>We can change it to MUST.

[adam] Perfect, I think that will help avoid any confusion around this,
should the situation occur.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Jan 2014 17:46:55 +0000

Hi Adam,

Thanks for your reply!

We'll submit a new version of the draft, with the changes implemented, asap :)

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

"Adam Gensler (agensler)" <[email-masked]> wrote:

Christer,