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

["Adam Gensler (agensler)" <[e-mail]>]

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" <[e-mail]>
wrote:

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


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


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


[adam] This sounds good to me.


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


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


>
>Regards,
>
>Christer
>
>