Subject: [rtcweb] DTLS version for RTCweb

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 09 May 2013 14:46:09 -0700

I read the various security drafts and it looks like they all reference DTLS
1.0 (RFC 4347), but RFC 4347 was obsoleted by RFC 6247.  So will the
references being updated to use DTLS 1.2 as the base version, or will DTLS 1.0
stay as the base version, with possibility of negotiation to 1.2 and higher?

Thanks.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Tim Panton <[email-masked]>
Date: Fri, 10 May 2013 10:08:50 +0100

On 9 May 2013, at 22:46, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
I think we should move to 1.2 - There are specific cases where 1.0 doesn't exactly do what we
want. 

e.g. I think for a server to ask for a client cert, technically in 1.0 you are supposed to list the CA's
you are interested in and you'll only receive certs from those CAs. In 1.2 you can leave this
empty and get a list of all certs (effectively a CA wildcard). 

T.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 10 May 2013 11:12:46 +0200

> empty and get a list of all certs (effectively a CA wildcard). 

What? Will any server get a list of all my private certs? That sems to me like a big fat privacy issue.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 10 May 2013 11:24:30 +0200

> What? Will any server get a list of all my private certs? That sems to me like a big fat privacy issue.
From RFC 5246 (TLS 1.2) that DTLS 1.2 refers to:

"If
      the certificate_authorities list is empty, then the client MAY
      send any certificate of the appropriate ClientCertificateType,
      unless there is some external arrangement to the contrary."

This doesn't mean that you will get all, but that the client can select any certificate in the 
cert store to present to the server. Previously the server had to present a list of 
acceptable CAs. It does open for self-signed certs, really. If you by other means have
established trust for a self-signed cert, you can use it as a client cert in TLS 1.2. The
server doesn't have to trust a CA, but can trust a specific cert.

This goes hand in hand with DANE.

/O

---

From: Tim Panton <[email-masked]>
Date: Fri, 10 May 2013 10:47:13 +0100

> This goes hand in hand with DANE.

But that language isn't in TLS 1.0 - the list can't be empty.

T.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 10 May 2013 12:02:17 +0200

> But that language isn't in TLS 1.0 - the list can't be empty.

Right. It's a good improvement but doesn't really work as you say - that you will et a list
of all my certs...

/O

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 May 2013 09:27:57 -0700

In an attempt to clarify:

1. DTLS 1.0 is actually based on TLS 1.1 (it's confusing, I know.)
DTLS 1.2 is based on TLS 1.2 so it won't be confusing in the
future.

2. The client only ever sends one certificate chain. This is just
about how the chain is selected.

3. The language Olle quotes appears in TLS 1.1 (RFC 4346)
as well was TLS 1.2, so it's fine to send an empty certificate
list with TLS 1.1/DTLS 1.0. In truth, people do this with TLS 1.0
though it's not officially sanctioned.

To go to the bigger question:
DTLS 1.2 deployment is still a work in progress, and it's possible
to negotiate versions. We should mandate DTLS 1.0 (remember,
there is no 1.1).

-Ekr

On Fri, May 10, 2013 at 3:02 AM, Olle E. Johansson <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>