Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-dtls-tunnel-10: (with DISCUSS and COMMENT)

["Paul E. Jones" <[e-mail]>]

Ben,

>>  >As far as I can tell, the certificate fingerprint is in the
>>  >"external_id_hash" TLS extension in the ClientHello, but this document
>>  >does not mention that extension name in any location.  I strongly
>>  >suggest noting somewhere (possibly earlier) that the fingerprint hash
>>  >used here is conveyed in the "external_id_hash" extension.  (Also, 4752
>>  >is obsoleted by 8122, and does not cover the TLS conveyance of the
>>  >fingerprint at all.) One way to do that would be
>>  >
>>  >NEW:
>>  >
>>  >     The Key Distributor MUST match the certificate fingerprint [RFC8122]
>>  >     and unique session identifier received in the "external_id_hash"
>>  >     [RFC8844] and "external_session_id" [RFC8844] TLS extensions
>>  >     (respectively) of the endpoint's ClientHello message with the values
>>  >     received from the SDP transmitted by the endpoint [RFC8122].
>>
>>  Actually, that was not the intended behavior. The intent was for the Key
>>  Distributor to match what it sees from the endpoint via DTLS with the
>>  expected values received via SDP.
>
>Hmm, okay.  I admite that I do not have all of WebRTC in my head, so I may
>well just be wrong, but I had thought that the "tls-id" values from SDP
>were themselves sent in a TLS extension per RFC 8844, as a way to
>authenticate the binding between the SDP exchange and the TLS handshake.

The "tls-id" is first sent in SDP from the endpoint as it tries to 
establish a call or join a conference.  The endpoint will receive an 
answer to that SDP containing, among other things, the transport 
address(es) to which DTLS packets should be sent.  The initiating 
endpoint then initiates a DTLS handshake and includes the "TLS ID" value 
in the "external_session_id" extension.  This is how the Key Distributor 
is able to differentiate between a plurality of "calls" that might be 
initiated at or about the same time from the same endpoint.  (There are 
perhaps other security benefits described in the associated RFCs, but 
this is the primary benefit for the tunnel draft).  I think this is all 
correct, but if you or others see a glaring hole or error, I'm happy to 
correct it.  Maybe the language still is not clear enough.


>
>>  I modified the text as follows, including repeated references to
>>  hopefully make this clearer:
>>
>>       The Key Distributor **MUST** match the certificate fingerprint and
>>       `external_session_id` [@!RFC8844] received from endpoint via DTLS
>>  with the
>>       expected fingerprint [@!RFC8122] and `tls-id` [@!RFC8842] values
>>  received via
>>       SDP.  It is through this process that the Key Distributor can be
>>  sure to
>>       deliver the correct conference key to the endpoint.
>>
>>  Hopefully this helps.  The certificate fingerprint is computed by the
>>  KD, but using the same method as would have been performed in generating
>>  the "fingerprint" SDP value described in RFC 8122.
>
>This helps in that it removes mention of the ClientHello (if the
>fingerprint isn't in an extension, it's not available from just the
>ClientHello).  This formulation is still not very satisfying for me (in a
>rather pedantic way that probably doesn't bother many people), since the
>certificate is what's received via DTLS, and the fingerprint is computed
>from the certificate.  If you're up for more changes, I would propose "MUST
>match the fingerprint of the certificate, and the "external_session_id"
>[RFC8844], received from the endpoint via DTLS".

I'm always open to improvements.  How is this?

     The Key Distributor **MUST** match the fingerprint of the 
certificate and
     `external_session_id` [@!RFC8844] received from endpoint via DTLS 
with the
     expected fingerprint [@!RFC8122] and `tls-id` [@!RFC8842] values 
received via
     SDP.  It is through this process that the Key Distributor can be 
sure to
     deliver the correct conference key to the endpoint.

Paul