Service Information over HTTPS?

[nicholas...@bbc.co.uk]

Hi,

The BBC currently publishes Service Information to here:

http://radio-service-information.api.bbci.co.uk:80/

We have a single '_radioepg._tcp' SRV record pointing to that server on port 80.

We don't advertise this, but it is also available over HTTPS and has a valid certificate:

https://radio-service-information.api.bbci.co.uk:443/

The ETSI TS 102 818 specification says to use '_radiospi._tcp' for application servers supporting client identification. The sequence diagram in Figure 4 shows a client falling back to using plain HTTP, having failed to do a GET with a Client Identifier over HTTPS.

Would it be unreasonable to have slightly different server behaviour:

• Have SRV records for both radiospi pointing to port 443 and radioepg pointing to port 80 on the same server
• Ignore Client Identifiers when connecting over plain HTTP
• If a client doesn't provide a Client Identifier when connecting over HTTPS, then return the 'unauthenticated' / basic version of the SI.xml document - the same as plain HTTP
• If a client provides valid a Client Identifier when connecting over HTTPS, then return the enhanced/extended version of the SI.xml document
• If a client provides an invalid Client Identifier over HTTPS, then return 403

I think this is compatible with what the specification says, so should be fine?

Should clients also honour HSTS headers?

Thanks,

nick.

[Nick Piggott (RadioDNS)]

Hello Nick

I'll ask Ben Poor, the Tech Group chair, to have a look at this, but I think the sequence you're describing is entirely legitimate, and could be expressed by expanding the existing Figure 4 (or maybe modifying Figure 5) to include that potential exchange of a request over HTTPS but without providing an Client Identifier, and receiving the 'unauthenticated' version.

That would make it clear that the current mode of operation over HTTP is fully supported over HTTPS as well, and provide a pathway to a future deprecation of HTTP as a transport.

We're about to file a new version of TS 102 818, so this is a good time to look at it.

Thanks

Nick

[nicholas...@bbc.co.uk]

Thanks Nick.

Before implementing Client Identification support, does it seem reasonable to add a _radiospi._tcp SRV record, as an indication that the content is available over HTTPS?

My reading of the specification is that radiospi is most closely associated with Client Identifiers but with the world moving everything to HTTPS, it would make sense if was associated with connecting over HTTPS? (and using Client Identifiers requires connecting over HTTPS).

[Nick Piggott (RadioDNS)]

Hello

Yes, in my opinion there's absolutely no downside to implementing a _radiospi._tcp SRV record now. The client should recognise that it's pointing to an HTTPS resource and use it even if it doesn't have a Client Identification for that FQDN.

The support for SPI over HTTPS was triggered by the addition of Client Identification (as it needs that secure pathway), but it's generally available as a transport layer for SPI (anonymous or otherwise).

Nick

Nick Piggott
Project Director
RadioDNS


www.radiodns.org // @radiodns // +44 (0) 1600 888335 // +1 (850)-888 8335

RadioDNS Limited is a not-for-profit company owned by its members, and registered in England and Wales with number 08818015. The registered office is 113 Parson St, Bristol BS3 5QH, United Kingdom

--
You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to
radiodns-develo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/radiodns-developers/9c9e4880-7666-4790-aac6-df3d3c83da9cn%40googlegroups.com.

[Ben Poor]

Hello,

Good points, right now the flow is fairly rigid and doesn't cover the case of:

* Client requests document to HTTPS endpoint without specifying a Client Identifier and the server wanting to return a basic document

What we can do is amend the guidance to give the service provider *the option of* responding to the client with a basic XML document. I remember there was some discussion that the existing rigid guidance should be there to allow clients to work out when a client provides an invalid client identifier, but this would seem a distinct case.

The option for the service provider to respond with an error should be kept, for service providers that absolutely need a client identifier with the HTTPS endpoint, but I can add a paragraph explaining the choice to the service provider.

Regarding the pre-emptive use of the _radiospi SRV record, I agree this is more than just using the Client Identifier - it indicates that the endpoint adheres to the later versions of the specification and requires HTTPS. As you mention, this is now becoming the norm so we should transition away from HTTP in the longer term.

Ben

[Nick Piggott (RadioDNS)]

Hello

It sounds like we have a consensus on behaviour here. 

Ben - shall we draft those amendments and circulate them to the Technical Group, with a view to inclusion in the forthcoming update?

Nick

To view this discussion on the web visit https://groups.google.com/d/msgid/radiodns-developers/a0b6f603-ede2-430d-a7d6-89df8477a047n%40googlegroups.com.

[Paul Webster]

An a non-practicing observer ... a quick question ... and apologies in advance if irrelevant.

Given the recent issues with Let's Encrypt highlighting the importance of having up to date root certificates etc ... a move to https-only could become an issue in the future for embedded clients that no longer receive updates from manufacturers.

Is that something that is addressed?

e.g. keeping http fallback, user selectable option for not checking certificate chain (at own risk)

Paul Webster

To view this discussion on the web visit https://groups.google.com/d/msgid/radiodns-developers/CAPAzv-twdhPcga2Xsj6U-tuBSLVdyoChNcvsLjqx3WAVqFY3Nw%40mail.gmail.com.

[Nick Piggott (RadioDNS)]

Hello,

We won't be removing support for http (non-encrypted) transports. We'll recommend that service providers provide it, and that clients use it where they can, and use of TLS (https) remains mandatory if you're using Client Identifier.

So it's a move to enabling more use of HTTPS without removing the option to use HTTP.

(If the client wants to provide an option to the user to force use / not-use of HTTPS, that's an option too!)

Nick Piggott
Project Director
RadioDNS


www.radiodns.org // @radiodns // +44 (0) 1600 888335 // +1 (850)-888 8335

RadioDNS Limited is a not-for-profit company owned by its members, and registered in England and Wales with number 08818015. The registered office is 113 Parson St, Bristol BS3 5QH, United Kingdom

To view this discussion on the web visit https://groups.google.com/d/msgid/radiodns-developers/670D2206-8704-426C-8864-5A2CB21C957A%40dabdig.com.

[Nicholas Humfrey]

Hi,

 

Just a followup to say that the BBC is now publishing a SRV record for ‘radiospi’:

 

$ host -t SRV _radiospi._tcp.radiodns.api.bbci.co.uk.

_radiospi._tcp.radiodns.api.bbci.co.uk has SRV record 0 100 443 radio-service-information.api.bbci.co.uk.

 

And it is currently pointing at the same server / SI.xml document as for plain HTTP.

 

$ host -t SRV _radioepg._tcp.radiodns.api.bbci.co.uk.

_radioepg._tcp.radiodns.api.bbci.co.uk has SRV record 0 100 80 radio-service-information.api.bbci.co.uk.

 

The number of incoming HTTPS requests is currently tiny.

 

 

nick.

To view this discussion on the web visit https://groups.google.com/d/msgid/radiodns-developers/CAPAzv-sC%3D4Yhd-X8WEuccuqmUg%2BN2AbXSG1a3gUYSE5xbfr2dw%40mail.gmail.com.

 

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

[Nick Piggott (RadioDNS)]

Hi Nick

That's great. Let's see if we can up the number of https requests, and make it more widely understood that https is preferred where available, even if Client Identification isn't in use.

Thanks

Nick Piggott
Project Director
RadioDNS


www.radiodns.org // @radiodns // +44 (0) 1600 888335 // +1 (850)-888 8335

RadioDNS Limited is a not-for-profit company owned by its members, and registered in England and Wales with number 08818015. The registered office is 113 Parson St, Bristol BS3 5QH, United Kingdom

To view this discussion on the web visit https://groups.google.com/d/msgid/radiodns-developers/0DCE4861-529C-484B-9D2A-8122504F63F2%40bbc.co.uk.