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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 18 Jan 2017 16:08:24 -0800

Stephen Farrell 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:
----------------------------------------------------------------------

Why is sha-256 hardcoded? You could easily include a hash
alg-id even as an option and in that way get algorithm
agility, as called for by BCP201.  (Or you could use something
like ni URIs but that's a bit of a self-serving suggestion;-)
Anyway, what's the plan for replacing sha-256 here? (This is a
bit of a subset of Alissa's discuss with which I agree.)

One possible way to handle this here is to identify sha-256 as
the default hash algorithm but to re-define the ABNF for hash
to allow an alg-id of some sort to be included there. Or have
some generic versioning text somewhere that calls for a
version bump if sha-256 is not to be used.

(If the authors want to include this as a part of the
discussion of Alissa's discuss, I'm fine with that and with
clearing this discuss and letting the disucsion happen on that
thread. But since the solutions could differ, I wanted to at
least start a separate discussion on alg. agility.)

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

- general: I think a design that uses https with mutual auth
would have been better and easier. But given that this is
implemented and deployed, I guess it's too late for this one.

- As with the oob spec, the xmlns values get me a 404.

- section 6: I don't agree that CMS signed data means that
https is not needed. The latter provides confidentiality and
integrity and server auth which the former does not.  And even
ignoring the security reasons, https is arguably much easier
to deploy and requires less development. And http is
vulnerable to middlebox messing (e.g. a client using http is
more likely to be forced to support cleartext proxy-auth
passwords).  I would encourage you to encourage use of https
with server auth in addition to CMS signed data payloads.

---

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

At Wed, 18 Jan 2017 16:08:24 -0800, Stephen Farrell wrote:
...
> Why is sha-256 hardcoded?

Real answer: because it's hard-coded in RFC 6486 and we were trying to
use the same hashing algorithm for manifests, this, and RRDP
(draft-ietf-sidr-delta-protocol).

>  You could easily include a hash alg-id even as an option and in
> that way get algorithm agility, as called for by BCP201.  (Or you
> could use something like ni URIs but that's a bit of a self-serving
> suggestion;-) Anyway, what's the plan for replacing sha-256 here?
> (This is a bit of a subset of Alissa's discuss with which I agree.)
> 

I had been assuming that an algorithm change would be a protocol
version bump.  Given that the server is probably storing these hashes
in a database, changing the algorithm is probably a bit more involved
than just changing the bits on the wire.

The design goals included offline authentication for audit purposes,
possibly years after the fact.  That's hard to do with any sort of
channel security mechanism, hence this approach.

> - As with the oob spec, the xmlns values get me a 404.

Don't think this is critical, but I can put up a vhost for this at
some point if it will make people happier.

> with server auth in addition to CMS signed data payloads.

Er, the CMS signatures do provide integrity, I think.

Having implemented both application code using both HTTPS and CMS as
part of this project, I will have to respectfully disagree on relative
difficulty of implementation.  CMS is a format hairball, true, but
it's all signed objects which can be signed and verified calmly at the
implementation's convenience.  TLS authentication tends to involve
callbacks at awkward times, requiring one to make authentication
decisions at a time chosen by somebody at the other end of a network
connection, which can get pretty nasty.

That said, I don't really object to HTTPS as a transport protocol, so
long as we don't have to change the authentication mechanism.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Jan 2017 01:20:21 +0000

Hi Rob,

> (draft-ietf-sidr-delta-protocol).

Hmm. I don't see sha-256 mentioned in 6486 never mind
hardcoded. Is there some indirection I'm missing? (But this
may be moot, see below.)

> than just changing the bits on the wire.

WRT clearing the discuss, if the draft said that then I'd
be happy to clear. (Meaning that I don't care how the spec
achieves alg. agility so long as it does somehow.)

Cheers,
S.

PS: I'm happy to chat about stuff below, but no need if we
don't need to:-)

---

From: Rob Austein <[email-masked]>
Date: Mon, 30 Jan 2017 20:46:09 -0500

> hardcoded. Is there some indirection I'm missing? (But this

OK, strictly speaking it's not hard coded in 6486, it's a reference to
6485.  Works out to the same thing for practical purposes: sha-256
now, upgrade theoretically possible but likely to be somewhat painful.

> achieves alg. agility so long as it does somehow.)

Will do, thanks.