Subject: [Tzdist] security consideration: why do we need an insecure version of the timezone service?

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Aug 2014 11:41:56 +0200

<no hat>

Hi,

In draft-douglass-timezone-service there is the following text:

>
>    Example: service record for server without transport layer security
>
>    _timezone._tcp     SRV 0 1 80 tz.example.com.
>
>    Example: service record for server with transport layer security
>
>    _timezones._tcp    SRV 0 1 443 tz.example.com.

If every enterprise and his mother is going to be running one of these
things, then it makes sense to consider a plain text version of the
service.  However, if it's going to be the big calendar providers that
are distributing, then it seems to me that this is not a substantial
barrier to deployment.

On the THIRD hand...

This draft seems to suffer POSH problems.

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 19 Aug 2014 10:40:15 -0400

Hi Eliot,

> are distributing, then it seems to me that this is not a substantial

I would be OK with making TLS a MUST and doing away with the plain text 
version - my only question is whether that would be OK for truly 
lightweight devices ("internet of things"). It definitely seems like some 
types of smart devices (thermostats being an obvious example) would need to 
be kept up to date with time zone DST changes. So maybe we should get input 
from the CORE WG folks to make sure what we have here is easily mapped to 
CoAP.

> This draft seems to suffer POSH problems.

Can you elaborate?

-- 
Cyrus Daboo

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Aug 2014 16:48:07 +0200

>> This draft seems to suffer POSH problems.

Yes.  What does the certificate look like for the "timezones" service? 
Presumably it matches the QNAME for the SRV record.  If that's the case
my question is whether various HTTP libraries that people are likely to
depend on will croak.  I think POSH (Matt Miller's work) was meant to
address this sort of thing when the XMPP folk hit it.

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 19 Aug 2014 10:57:02 -0400

Hi Eliot,

> address this sort of thing when the XMPP folk hit it.

We tried to address some of that in the srv-caldav document 
<http://tools.ietf.org/html/rfc6764#section-8>. I thought we had copied the 
security considerations from there almost verbatim, but I see we "lost" the 
text referring to Section 6 of RFC6125. Now, I don't know whether that is 
still considered best practice, or whether POSH or perhaps UTA WG work will 
be what we need to reference.

-- 
Cyrus Daboo

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Aug 2014 17:26:47 +0200

On 8/19/14, 4:57 PM, Cyrus Daboo wrote:
> <http://tools.ietf.org/html/rfc6764#section-8>. I thought we had
> copied the security considerations from there almost verbatim, but I
> see we "lost" the text referring to Section 6 of RFC6125. Now, I don't
> know whether that is still considered best practice, or whether POSH
> or perhaps UTA WG work will be what we need to reference.
>

The problem is really this: suppose you are a TLS server who serves more
than a single domain via an SRV record.  What do you do?  You send the
cert you're configured with and you have no idea what cert the other guy
is expecting.  One could make use of separate ports or one can do more.

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 19 Aug 2014 11:47:35 -0400

Hi Eliot,

> is expecting.  One could make use of separate ports or one can do more.

Won't the SNI (Server Name Indication) extension to TLS take care of that?

-- 
Cyrus Daboo

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Aug 2014 17:55:23 +0200

> Won't the SNI (Server Name Indication) extension to TLS take care of

Sorry, there's more.  In the field it is often hard to get a customer to
share keying material for their domain.  And so some form of referral
service is used.  I'm not sure how far to go with this.  It may be that
SNI is enough.

Eliot