Re: [sidr] Alissa Cooper's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

> On Jan 30, 2017, at 7:33 PM, Rob Austein <[e-mail]> wrote:
> 
> At Tue, 17 Jan 2017 07:46:06 -0800, Alissa Cooper wrote:
> ...
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> What is the upgrade path for the future when new versions of this
>> protocol get published? How are clients and servers meant to agree on
>> which version to use?
> 
> The schema includes a version number, so a new protocol version would
> be detectable; in the most straightforward implementation, attempting
> to parse an unknown protocol version would result in a schema
> validation error.

I think it would be useful to note that expectation (also since the document talks about existing older versions of the protocol, presumably not standardized).

Thanks,
Alissa

>  I don't think it's really possible to specify the
> upgrade path in detail until one knows what the newer version looks
> like, ie, what changed, so I'd defer this until the (hypothetical) new
> version.
> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Although I understand why Section 6 says transport security is not
>> strictly required, given that the authentication and authorization
>> mechanisms that this protocol relies on are outside of the scope here,
>> isn't it possible that clients and servers may be exchanging cookies or
>> other headers in the course of using this protocol that would benefit
>> from transport encryption? It seems like mentioning that transport
>> security may still be beneficial although not required might be a good
>> idea.
> 
> Um, the authentication is CMS signatures, it's just the authorization
> that's out of scope.
> 
> I can't think of any sane reason for stuffing cookies or the like into
> this protocol, but yes, it's theoretically possible.
> 
> The protocol is currently specified in terms of plain HTTP because an
> earlier version using HTTPS included a horrible authentication
> hairball in which HTTPS and CMS were required to use the same BPKI
> certificates for authentication, which turned out to be an
> implementation nightmare.  So we backed off to plain HTTP to cut free
> of that mess, and we didn't think there were any privacy issues in the
> real data (if there had been, we would have been using CMS encryption
> too).
> 
> That said, the world has changed, and I see at least one other discuss
> asking for HTTPS, so I guess we'll be going down that path, but this
> time with no required linkage between CMS and HTTPS, and with the
> authentication (still) just based on CMS.