Subject: Re: [Ice] ICE on the side IETF98 summary

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 28 Mar 2017 22:05:58 +0000

> On 28 Mar 2017, at 11:32, Roman Shpount <[email-masked]> wrote:
> 
> On Tue, Mar 28, 2017 at 10:29 AM, Pal Martinsen (palmarti) <[email-masked]> wrote:
> ICE TLS
> - Demux point when running 443. What call is the incomming connection for?
> 
> This can be no different then ICE-TCP. TLS connection is accepted and once STUN BIND message is received this connection, connection is assigned to a specific call based on ufrag in the STUN message.
> 

+1
> I have a related question -- do we want to validate certificates for this TLS connection, i.e. do something similar to fingerprint? I would assume not.
> 

The current text n the draft says:
"The certificates exchanged as part of the TLS handshake should be
   validated against the given fingerprint as a means of identifying the
   remote TLS participant.”

should = SHOULD in the section. Is that to strong?

On a side note the ABNF allows SHA-1
"extension-att-name = "fingerprint"
 extension-att-value = hash-func ";" fingerprint
 hash-func =  "sha-1" / "sha-224" / "sha-256" / token
 fingerprint =  2UHEX *(“:” 2UHEX)"

Remove SHA-1 altogether?

.-.
Pål-Erik

---

From: Roman Shpount <[email-masked]>
Date: Tue, 28 Mar 2017 19:04:03 -0400

On Tue, Mar 28, 2017 at 6:05 PM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

> > This can be no different then ICE-TCP. TLS connection is accepted and
> once STUN BIND message is received this connection, connection is assigned
> to a specific call based on ufrag in the STUN message.
> >
>
> +1
> > I have a related question -- do we want to validate certificates for
> this TLS connection, i.e. do something similar to fingerprint? I would
> assume not.
> >
>

1. Please remove SHA-1. It should not be used for anything new.

2. Do end points really MUST include fingerprint in TLS candidates?

I would prefer to make fingerprint optional. Fingerprint MUST match the
certificate if fingerprint is included. The reason for optional is that
typically TLS candidate is only needed for NAT traversal and will carry
DTLS-SRTP which will be encrypted and authenticated as well. I do not think
we will gain a lot by double checking the certificates. Also, if we are
serious about authentication, we will need tls-id (see
https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/ for more
details).

3. Is there ever a use case for more then one fingerprint per candidate?
I do not think so, but I might be missing something like situations when it
is not known in advance which server gets the TCP connection because of the
load balancer.

4. Finally, what is the m= line transport when TLS candidate is used? Are
we going to use TLS/DTLS/RTP/SAVPF and TLS/DTLS/SCTP? This needs to be
defined somewhere.

Regards,
_____________
Roman Shpount