Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

On Feb 25, 2016, at 2:18 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

Hi,

Personally, I have no problem updating RFC 4572 within draft-ietf-mmusic-dtls-sdp, depending on how big the update would be.

The currently identified potential updates are:

1)      Define the semantics of associating multiple SDP ‘fingerprint’ attributes with an “m=” line.
2)      Update the preferred cipher suite in order to align with DTLS (SHA-1 -> SHA-256).

Another potential update would be to remove (or relax) the requirement that the fingerprint use the same hash algorithm as the certificate.  This seems like a necessary corollary to 1), but is also useful on its own.

Regarding 1), I’d be happy if someone could commit to providing text (even if it is simply copying something from Martin’s draft). Also, is it enough to update section 5 of RFC 4572, or do we need to update some other sections too?

Regards,

Christer

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 25 February 2016 20:59
To: Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>>; Jonathan Lennox <jonathan@vidyo.com<mailto:jonathan@vidyo.com>>
Cc: mmusic <mmusic@ietf.org<mailto:mmusic@ietf.org>>; Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

3. Write a separate draft that updates 4572.

Regards,

Christer

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 25 February 2016 20:57
To: Jonathan Lennox <jonathan@vidyo.com<mailto:jonathan@vidyo.com>>
Cc: Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>; mmusic <mmusic@ietf.org<mailto:mmusic@ietf.org>>; Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>>; Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

There are two options possible here:

1. Make current draft-ietf-mmusic-dtls-sdp draft update 4572 and cover TLS as well, essentially making it draft-ietf-mmusic-tls-and-dtls-sdp

2. Limit the scope of draft-ietf-mmusic-dtls-sdp to DTLS only. Completely define how setup and fingerprint attributes are used there for DTLS only. Let some future draft update RFC 4572.

What is the preference here given that either option will require another major edit for draft-ietf-mmusic-dtls-sdp?

Regards,

_____________
Roman Shpount

On Thu, Feb 25, 2016 at 10:41 AM, Jonathan Lennox <jonathan@vidyo.com<mailto:jonathan@vidyo.com>> wrote:
I can certainly agree that 4572 could use an update. I didn’t completely understand what I was doing when I wrote it; in particular, the idea that the certificate was just a repository for the public key wasn’t something I had completely grasped, and the hash agility was confused.

> On Feb 24, 2016, at 5:01 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
>
> On 24 February 2016 at 13:47, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote:
>> If we are going to make normative references to multiple fingerprints we
>> need some place authoritative to reference for the details.
>
> I recommend judicious use of copy and paste.  Feel free to steal text
> that I wrote.
>
> FWIW, my reading of 4572 is that it permits multiple fingerprints: one
> for each certificate that might be used.  Its failing is that a) it
> doesn't allow for hash agility, and b) it's unclear, perhaps in the
> extreme.
>
> However, I see this:
>
>   Endpoints MUST support SHA-256 for generating and verifying the
>   fingerprint value associated with the DTLS association.  The use of
>   SHA-256 is preferred.
>
> Which doesn't mention that this requires an update of 4572.
>
> And this:
>
>   The certificate received during the DTLS handshake MUST match the
>   fingerprint received in the SDP "fingerprint" attribute.
>
> Which should say '*a* fingerprint', to allow for there being multiple.
>
> And this:
>
>   [...]  In addition, the offerer
>   MUST insert an SDP 'setup' attribute according to the procedures in
>   [RFC4145], and an SDP 'fingerprint' attribute according to the
>   procedures in [RFC4572], in the offer.
>
> Which doesn't deal with multiple certificates.
>
> I also see:
>
>   The
>   subjectAltName is not an important component of the certificate
>   verification.
>
> Which is true but insufficient; the text can simply say that the
> certificate is only a receptacle for a public key and authentication
> is tied to an a=fingerprint line in the SDP.
>
> And this:
>
>   This offer includes, as part of the SDP payload, the fingerprint of
>   the certificate that the endpoint wants to use.  The endpoint SHOULD
>
> Which should be plural fingerprint*s*.
>
> The pattern repeats throughout.

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic