[mdx] Joe on section 2.1

[Ian Young]

On 26 Sep 2013, at 16:22, Joe St Sauver <joe at oregon.uoregon.edu> wrote:

> Ian commented:
> #Personally, I
> #don't understand why HTTP 1.1 should preclude TLS 1.2 per RFC5246, but
> #perhaps someone can explain why they think that might be the
> #implication.

Perhaps I wasn't clear about what I was asking.  I don't think that the text in section 2.1 is ambiguous or open to an interpretation that it requires HTTP to be run over an unencrypted transport.  Unless it is actually unclear, I don't think that adding to what's in the current text is beneficial.

Here's my reasoning:

There is no such thing as an encrypted HTTP protocol vs. an unencrypted HTTP; encryption is not part of HTTP but of the transport over which it is run.  The HTTP protocol is agnostic about the transport over which it is run.  This is the relevant text from RFC 2616, I think:

>    HTTP communication usually takes place over TCP/IP connections. The
>    default port is TCP 80 [19], but other ports can be used. This does
>    not preclude HTTP from being implemented on top of any other protocol
>    on the Internet, or on other networks. HTTP only presumes a reliable
>    transport; any protocol that provides such guarantees can be used;
>    the mapping of the HTTP/1.1 request and response structures onto the
>    transport data units of the protocol in question is outside the scope
>    of this specification.

That's the context in which I'm reading our text.  We're saying that the md-query protocol is layered on HTTP and that to me implies nothing about the transport protocol other than the above from the HTTP spec, which clearly does not require a particular transport protocol.  I'd prefer to preserve those properties in this specification as far as possible.

Of course, there's a separate discussion required about SSL/TLS in the Security Considerations section.

> Perhaps just add a note, "Specifying HTTP 1.1 is NOT meant to specify
> use of unencrypted HTTP protocols only; whever possible, encryption of
> traffic is encourage. The most recent version of TLS (currently TLS 1.2 
> per RFC5246) SHOULD be used.

As I say, I don't think this belongs in the *protocol* section of the document, but we will come back to this again when we talk about the Security Considerations (in another thread, probably).

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20130926/dc1b9f3c/attachment.bin>