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

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 17 Jan 2017 07:46:06 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-sidr-publication-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/

----------------------------------------------------------------------
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?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(Hit the send button too quickly, sorry for the multiple emails.)

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.

---

From: Rob Austein <[email-masked]>
Date: Mon, 30 Jan 2017 19:33:28 -0500

At Tue, 17 Jan 2017 07:46:06 -0800, Alissa Cooper wrote:
...

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 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.

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.