Re: Firefox cannot act as DHE server

[ors . szabo . hu]

Hi Martin,

Let me clarify: remote node is acting as DTLS client and sends DTLS client 
hello with DHE_RSA. Firefox replies with handshake failure.

What shall be done to solve this? I didn't get how the '2048-bit share' relates 
to this. You also mentioned the RTCCertificate API, for which there is no basic 
support in FF.

Thanks a lot!
Ors
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Firefox cannot act as DHE server

[ors . szabo . hu]

Martin, just to double-check: by 'client' you mean WebRTC client, and not the 
remote node which is sending the DTLS client hello towards FF, right?

Thanks,
Ors
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: Firefox cannot act as DHE server

[ors . szabo . hu]

Thanks a lot Martin, will look into that!

Regards,
Ors
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Firefox cannot act as DHE server

[ors . szabo . hu]

Hello,

I'm getting DTLS handshake failure basically with all FF versions (even with 
latest nightly build) for a DTLS client hello with the following cipher suites:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) 
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

Is this a known fault in FF?

Regards,
Ors
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: SDP offer with IP 0.0.0.0 from Firefox 41

[ors . szabo . hu]

Thanks Eric.
According to: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-02, 
Chapter 5.1:
" As mentioned earlier in this section, Offers and Answers can contain
   any set of candidates, which means that a trickle ICE session
   description MAY contain no candidates at all.  In such cases the
   agent would still need to place an address in the "c=" line(s).  If
   the use of a host address there is undesirable (e.g. for privacy
   reasons), the agent MAY set the connection address to IP6 ::. In this
   case it MUST also set the port number to 9 (Discard).  There is no
   need to include a fictitious candidate for the IP6 :: address when
   doing so."

I interpret this that the browser MAY use IP6 :: in the SDP c-line in case 
there are no ICE candidates. In my case, host candidates exist, still the 
c-line contains no IP. Is this correct behavior? 
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Re: WebRTC DTLS cipher suite selection logic

[ors . szabo . hu]

Thanks Martin, but i suppose that doesn't mean that Firefox only includes these 
two cipher suites in the ClientHello:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

I remember seeing many more earlier, e.g. DHE-RSA and ECDHE-RSA. I know that 
non-PFS ciphers are removed, but im wondering if now only ECDHE-ECDSA is 
included or also e.g. TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 
TLS_DHE_RSA_WITH_AES_256_CBC_SHA is supported? At least those are not part of 
the DisabledCiphers[]. 
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

SDP offer with IP 0.0.0.0 from Firefox 41

[ors . szabo . hu]

Hi,

Can you tell me what is the reasoning behind this?
Thanks.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

WebRTC DTLS cipher suite selection logic

[ors . szabo . hu]

Where can i find information on how Firefox is selecting the cipher suite to be 
used from the list of cipher suites it receives in DTLS ClientHello ?
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media