[paws] Fwd: Stephen Farrell's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)

[Pete Resnick <[e-mail]>]

--- Begin Message ---

Stephen Farrell has entered the following ballot position for
draft-ietf-paws-protocol-14: 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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Hi, I've a few things to discuss, but I think only the first
is possibly tricky...

(1) 4.4.1 - why are location and deviceOwner required? The FCC
may require those but why does the protocol? I don't see that
those are needed for interop. Isn't that latter the right
criterion for inclusion as a required field? I could see a
reason for the location-from-which-I-want-to-use-WS but that's
not what is described I think. The discuss here is both
relating to the privacy issues with requiring exposure of
identifying information but also relating to the criteria used
to determine required vs. optional and how those map to
interop vs. to current known sets of regulatory rules.  (Same
for 5.2 serialNumber, though there a dynamic/random choice may
be needed instead.)

(2) 4.4.1 - is the location here the location of the device or
the location from which spectrum is to be used? I think you
need to disambiguate those. I continue to think there should
be a way to ask for spectrum in London, tomorrow; even whilst
still in Dublin, today. 4.5.1 seems to imply this may be
allowed sometimes, but I'm not clear if that works - how would
the "tomorrow" value be sent?

(3) Section 7: I think it'd be a good idea to either reference
the UTA TLS BCP for ciphersuites etc or else (if you'd rather
not have a dependency to another WG's I-D, which I'd
understand) to specify some here. The MTIs from 5246 are
looking pretty jaded right now. You may also want to mandate
use of OCSP or even stapling - there are a few more TLS things
you can do that help interop and to speed things up. I'm not
trying to insist you do/document all of those things, but
would like to chat about it for a bit.

(4) Section 7: You are assuming some kind of PKI is used to
authenticate DBs. Now that might work with the current Web
PKI, except that then any public Web PKI CA can fake any DB
but are regulator's ok with that? Secondly, TLS requires that
the DB nominate the acceptable CAs for client auth, so there's
a bit of specification missing here which is maybe that a DB's
description needs to include information about its acceptable
trust anchors. I don't think you necessarily need to fix all
of that in this document, but what is the plan here? (And
maybe some of it ought be fixed here, not sure.)


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


- write-up: its a pity that coders haven't gotten together more
openly and done interop, but I guess different businesses are
different. 

- section 1, last para: I realise authorized devices is what
the WG are interested in, but the protocol ought not require
that, so the last sentence here is wrong - it surely should
be: s/device is authorized to operate/device operates/

- Ruleset: I hope there's a NULL, meaning "no rules":-)

- 4.4.1 - nothing stops a device lying about location, right?

- 4.5 - the slave location vs. master location seems unclear
to me. Can you clarify?

- 4.5.1 - timestamp has to be UTC right? You only seem to
indicate that via the "Z" in the timestamp format which I
expect could be easily missed. Suggest you emphasise that. You
should probably also say if truncated timestamps are ok, for
example just to the minute granularity without specifying
seconds.  I assume that's not allowed? And lastly, please
specify if the start (resp. end) of the second (or whatever)
unit is when a device gains (resp. looses) spectrum. (Or add a
global statement on timezones where you earlier said that
identifiers are case sensitive by default.) Some of this is in
5.14, but I'm not sure if that's enough. (It could be.)

- 5.2 - I don't get why you need X.520 here.

- 5.5 - could a vCard value just be (the moral equivalent of)
"Internet" or "I'm not telling"?

- section 7: Saying the master device MUST implement server
auth is confusing, since the master device is the TLS client,
right?

- Section 10: Under the privacy bullet you should also
recognise that an authorized entity can be privacy invasive
(e.g. selling contact information, sending all on to law
enforcement without permission).

- Section 10: Given diginotar and similar (incl. by nation
states), having the master device send its identifying
information in its first message means that simply saying "use
TLS" is not enough. You need to say "TLS, assuming the PKI
used is ok,..." or similar.

--- End Message ---