Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 03 May 2021 18:06:20 +0000

Russ,

I apologize for the late reply.  Reply below:

------ Original Message ------
From: "Russ Housley" <[email-masked]>
To: [email-masked]
Sent: 4/19/2021 2:19:17 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

>Section 2: Your reference to BCP 14 does not include "NOT RECOMMENDED". 
>Please use:
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in
>    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.

Corrected.

>Section 4: I do not know the meaning of "abbrev" in: "... inside abbrev 
>"TunneledDtls" message."  Please clarify.

Should just be "a".  That is a keyword used in the document template I 
use, so I think my editor decided to expand that for me.  Very odd, 
indeed.

>Section 5.3: Please reference Section 4.4 of [RFC4122] for random UUID 
>creation.

I'll make the change as you suggest.

>Section 5.4 says: "The key distributor MUST correlate the certificate 
>fingerprint ...".  What does correlate mean?  I was expecting a 
>requirement for exact match?  What hash algorithm(s) are used for 
>fingerprints?

Match is a better word.  I don't think we should prescribe hashing 
algorithms to use in this document.

>Section 6.1: MKI is optional in RFC 3711.  What is carried in MediaKeys 
>when there is no MKI present?

MediaKeys is a structure with a number of elements inside, and MKI is 
optional.  The other things include an association ID, SRTP protection 
profile, master keys, and salt values.

>NITS:
>
>The document uses "hop-by-hop" and "HBH" in many places.  Please pick 
>one and use it everywhere.

OK, will do.

Thanks!
Paul

>
>
>
>
>Russ
>
>>On Apr 1, 2021, at 4:44 PM, Suhas Nandakumar <[email-masked]> 
>>wrote:
>>
>>Hello All
>>We totally missed on finishing one last Informational WG document : "DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange"
>>This is an announcement for the WGLC for the same, the document is available for inspection here:
>>https://datatracker.ietf.org/doc/html/draft-ietf-perc-dtls-tunnel-07
>>
>>Please help review the document and send your comments by  April 16, 2021.
>>
>>Please Note there are IPR declaration at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-perc-dtls-tunnel <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-perc-dtls-tunnel%E2%80%9D>
>>
>>Suhas Nandakumar
>>For the Chairs
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 03 May 2021 18:15:07 +0000

Cullen,

Comments below:

------ Original Message ------
From: "Cullen Jennings" <[email-masked]>
To: [email-masked]
Cc: "Suhas Nandakumar" <[email-masked]>; "Paul Jones" 
<[email-masked]>
Sent: 4/26/2021 7:26:35 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

>
>This document is easy to understand and very detailed. I think it is ready for publication.
>
>There are a few small changes I would recommend:
>
>1. The way SDP is used, I think RFC 4566 needs to be a normative reference ( it is currently an informative reference )

OK, I'll move that reference.

>2. I would sugest that the IANA section say that the update procedure for the table is "IETF Review" as defined in RFC 8126. (and add normative ref). This is not much of a change from what is there but I think it makes it more concrete and clear.

OK, I'll make that comment.

>
>3. In section 5.1 when talking about the tls-id, the document should include a normative reference to RFC 8842

I'll update that, as well as the other draft reference that is now an 
RFC.

Thanks!
Paul

---

From: Russ Housley <[email-masked]>
Date: Mon, 3 May 2021 14:19:16 -0400

>> Section 6.1: MKI is optional in RFC 3711.  What is carried in MediaKeys when there is no MKI present?
> 
> MediaKeys is a structure with a number of elements inside, and MKI is optional.  The other things include an association ID, SRTP protection profile, master keys, and salt values.

You answered the wrong question.  I know that there are other elements in MediaKeys.  However, if the MKI element is absent, what is used in Section 6.1.

Russ

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 03 May 2021 19:05:36 +0000

Russ,

The MediaKeys structure would carry all the other useful bits for SRTP 
keying material even if the MediaKeys.mki field contains no data.  I 
guess I still do not understand the question.

Paul

------ Original Message ------
From: "Russ Housley" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]
Sent: 5/3/2021 2:19:16 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

>You answered the wrong question.  I know that there are other elements 
>in MediaKeys.  However, if the MKI element is absent, what is used in 
>Section 6.1.
>
>Russ
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 3 May 2021 16:12:20 -0400

Paul:

Section 6.1 says:

   struct {
       uuid association_id;
       SRTPProtectionProfile protection_profile;
       opaque mki<0..255>;
       opaque client_write_SRTP_master_key<1..255>;
       opaque server_write_SRTP_master_key<1..255>;
       opaque client_write_SRTP_master_salt<1..255>;
       opaque server_write_SRTP_master_salt<1..255>;
   } MediaKeys;

If the MRI is absent, I am assuming that a zero-length value goes in this structure, but the spec does not say one way or the other.

If the MRI is absent, then there is not anything that is present here to provide binding.

Russ

> On May 3, 2021, at 3:05 PM, Paul E. Jones <[email-masked]> wrote:
> 
> Russ,
> 
> The MediaKeys structure would carry all the other useful bits for SRTP keying material even if the MediaKeys.mki field contains no data.  I guess I still do not understand the question.
> 
> Paul
> 
> From: "Russ Housley" <[email-masked] <mailto:[email-masked]>>
> To: "Paul E. Jones" <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 03 May 2021 20:46:10 +0000

Russ,

The zero-length would indicate there is no MKI.  Section 5.4 mentions 
the values in that structure and says "MKI value (if any)".  The field 
itself cannot be optional in the syntax (as far as I know), but a 
zero-length would indicate there is no value present.  There is a 
one-octet length field that would be set to zero.  Are you suggesting a 
different syntax or an explicit statement in the MKI field description 
that says "a zero-length MKI value indicates absence of an MKI value" or 
similar?

Paul

------ Original Message ------
From: "Russ Housley" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]
Sent: 5/3/2021 4:12:20 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

>If the MRI is absent, I am assuming that a zero-length value goes in 
>this structure, but the spec does not say one way or the other.
>
>>>>MediaKeys is a structure with a number of elements inside, and MKI 
>>>>is optional.  The other things include an association ID, SRTP 
>>>>protection profile, master keys, and salt values.
>>>
>>>You answered the wrong question.  I know that there are other 
>>>elements in MediaKeys.  However, if the MKI element is absent, what 
>>>is used in Section 6.1.
>>>
>>>Russ
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 3 May 2021 16:51:23 -0400

Paul:

Yes, I think that an explicit statement is needed.  I am not suggesting a syntax change.  However, if the MRI is absent, there may be something to say in the security considerations.

Russ

> On May 3, 2021, at 4:46 PM, Paul E. Jones <[email-masked]> wrote:
> 
> Russ,
> 
> The zero-length would indicate there is no MKI.  Section 5.4 mentions the values in that structure and says "MKI value (if any)".  The field itself cannot be optional in the syntax (as far as I know), but a zero-length would indicate there is no value present.  There is a one-octet length field that would be set to zero.  Are you suggesting a different syntax or an explicit statement in the MKI field description that says "a zero-length MKI value indicates absence of an MKI value" or similar?
> 
> Paul
> 
>>> On May 3, 2021, at 3:05 PM, Paul E. Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Russ,
>>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 03 May 2021 20:59:54 +0000

Russ,

OK, I'll add this to the syntax section:

"A zero-length field indicates that  no MKI value is present."

What security consideration do you think is needed?  Presence or 
absence, either way, is normal.

Paul

------ Original Message ------
From: "Russ Housley" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]
Sent: 5/3/2021 4:51:23 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

>Paul:
>
>Yes, I think that an explicit statement is needed.  I am not suggesting 
>a syntax change.  However, if the MRI is absent, there may be something 
>to say in the security considerations.
>
>Russ
>
>
>>one-octet length field that would be set to zero.  Are you suggesting 
>>a different syntax or an explicit statement in the MKI field 
>>description that says "a zero-length MKI value indicates absence of an 
>>MKI value" or similar?
>>
>>Paul
>>
>>>>The MediaKeys structure would carry all the other useful bits for 
>>>>SRTP keying material even if the MediaKeys.mki field contains no 
>>>>data.  I guess I still do not understand the question.
>>>>
>>>>Paul
>>>>

---

From: Russ Housley <[email-masked]>
Date: Mon, 3 May 2021 18:13:59 -0400

Paul:

The MKI, when present, identifies the master key from which the four keys that follow are derived. 

Is the key derivation completely a local matter?  If so, please say that.  Is the technique in Appendix B.3 of RFC 3711 required?  If so, pleas say so.

What are the consequences if the identified master key is disclosed?  I would guess that is equivalent to the disclosure of all keys that were ever derived from it.

Russ

> On May 3, 2021, at 4:59 PM, Paul E. Jones <paulej=[email-masked]> wrote:
> 
> Russ,
> 
> What security consideration do you think is needed?  Presence or absence, either way, is normal.
> 
> Paul
> 
>>> On May 3, 2021, at 4:46 PM, Paul E. Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Russ,
>>> 
> _______________________________________________
> Perc mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/perc <https://www.ietf.org/mailman/listinfo/perc>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 03 May 2021 23:31:22 +0000

Russ,

The tunneling procedures build on RFC 5764, which is where the key 
derivation process is defined.  What the tunneling spec says is that the 
key distributor hands those keys and salt values to the media 
distributor in a special message.  That is necessary since the media 
distributor is otherwise not party to the key exchange that preceded the 
key generation and derivation steps.

There is further key derivation from master keys to session keys and 
salt described in RFC 3711 Section 4.3.  However, we should not get into 
that detail in this draft.  This draft just explains how to convey the 
information needed by an SRTP implementation, not how to implement SRTP.

While MKI is encrypted in the message exchange in the tunneling spec, it 
would not matter if it wasn't exposed.  This value means nothing on its 
own and is present in SRTP packets in the clear if used; it's not a 
secret value (nor is the master salt).

Paul

------ Original Message ------
From: "Russ Housley" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]
Sent: 5/3/2021 6:13:59 PM
Subject: Re: [Perc] WGLC for draft-ietf-perc-dtls-tunnel

>Is the key derivation completely a local matter?  If so, please say 
>that.  Is the technique in Appendix B.3 of RFC 3711 required?  If so, 
>pleas say so.
>
>What are the consequences if the identified master key is disclosed?  I 
>would guess that is equivalent to the disclosure of all keys that were 
>ever derived from it.
>
>Russ
>
>
>>On May 3, 2021, at 4:59 PM, Paul E. Jones 
>><paulej=[email-masked]> wrote:
>>
>>Russ,
>>
>>>Yes, I think that an explicit statement is needed.  I am not 
>>>suggesting a syntax change.  However, if the MRI is absent, there may 
>>>be something to say in the security considerations.
>>>
>>>Russ
>>>
>>>
>>>>The zero-length would indicate there is no MKI.  Section 5.4 
>>>>mentions the values in that structure and says "MKI value (if any)". 
>>>>  The field itself cannot be optional in the syntax (as far as I 
>>>>know), but a zero-length would indicate there is no value present.  
>>>>There is a one-octet length field that would be set to zero.  Are 
>>>>you suggesting a different syntax or an explicit statement in the 
>>>>MKI field description that says "a zero-length MKI value indicates 
>>>>absence of an MKI value" or similar?
>>>>
>>>>Paul
>>>>
>>>>>If the MRI is absent, I am assuming that a zero-length value goes 
>>>>>in this structure, but the spec does not say one way or the other.
>>>>>
>>>>>>>>MediaKeys is a structure with a number of elements inside, and 
>>>>>>>>MKI is optional.  The other things include an association ID, 
>>>>>>>>SRTP protection profile, master keys, and salt values.
>>>>>>>
>>>>>>>elements in MediaKeys.  However, if the MKI element is absent, 
>>>>>>>what is used in Section 6.1.
>>>>>>>
>>>>>>>Russ
>>>
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/perc
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 3 May 2021 20:40:34 -0400

Paul:

I asked about disclosure of the master key, not the MKI.

Russ

> On May 3, 2021, at 7:31 PM, Paul E. Jones <paulej=[email-masked]> wrote:
> 
> Russ,
> 
> The tunneling procedures build on RFC 5764, which is where the key derivation process is defined.  What the tunneling spec says is that the key distributor hands those keys and salt values to the media distributor in a special message.  That is necessary since the media distributor is otherwise not party to the key exchange that preceded the key generation and derivation steps.
> 
> There is further key derivation from master keys to session keys and salt described in RFC 3711 Section 4.3.  However, we should not get into that detail in this draft.  This draft just explains how to convey the information needed by an SRTP implementation, not how to implement SRTP.
> 
> While MKI is encrypted in the message exchange in the tunneling spec, it would not matter if it wasn't exposed.  This value means nothing on its own and is present in SRTP packets in the clear if used; it's not a secret value (nor is the master salt).
> 
> Paul
> 
>>> On May 3, 2021, at 4:59 PM, Paul E. Jones <paulej=[email-masked] <mailto:paulej=[email-masked]>> wrote:
>>> 
>>> Russ,
>>>