IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-09-29. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
Telechat::
Telechat::
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
Amy: several items close tomorrow, get at least a placeholder
Amy: BoF coordination next Thursday
Spencer: what's the biggest room in Seoul
Amy: grand ballroom split
Spencer: was 400 last time (for QUIC), currently says 250
Amy: probably will be 300
1106 EDT Adjourned
(at 2016-09-29 06:00:07 PDT)
draft-ietf-pals-rfc4447bis
I would prefer to see the IANA section retained and specify the fields in the IANA registry. It is useful to know which registry to find and where the values are defined.
- It would be nice to see a mention that this advances the status to Internet Standard somewhere near the top of the document. Section 10 is sufficient for that, but it sort of buries the lede. (It's too late to matter now, but it would have been helpful to have the status change called out more strongly in the shepherd writeup and last call announcement. ) I would rather strongly like to see the IANA considerations from the obsoleted RFCs to be copied forward, perhaps with a preface that these were originally in 4447, etc. Especially since this draft requests the references point to it, effectively orphaning the 4447 IANA considerations. There are a few odd uses of 2119 keywords, all of which I think existed in the original text: - 7.1: normative REQUIRED the section title - 7.2: Unattached "NOTs" - 9.1 : "there is a perception that security MUST be " seems like a statement of fact.
I agree with Alexey's Discuss on bringing the IANA section forward.
This doc obsoletes RFC6723. RFC6723 upadtes RFC6073 but this doc doesn't. Is that correct?
It is an embarrassment that we can't do better than TCP MD5. TCP MD5 (from 1998, RFC2385) has been obsoleted by TCP-AO (RFC 5925, from 2010), but that hasn't seen deployment. Back in 1998 (18 years ago!) RFC 2385 included an IESG note that says: "This document describes current existing practice for securing BGP against certain simple attacks. It is understood to have security weaknesses against concerted attacks." And all these years later we can still do no better when promoting a document to IS. Sigh. However, I see no point in trying to block this document on that basis. I would argue for an IESG note along the above lines if I thought that'd have any impact, but I guess it won't if, as seems to be the case, people won't move until there's a catastrophic break.
I share Stephen's concerns on the use of MD5 and would like to see a deprecation process begin.
I am glad that you are moving this document to Internet Standard. My earlier DISCUSS below: I have a simple issue with the IANA Considerations section which should be easy to address: The IANA section seem to be suggesting that IANA should do full search of its registries to update all references to RFC 4447 to point to rfc4447bis. I don't think it is easy for IANA to do that. This document is obsoleting RFC 4447, which means that there is no need to ever read RFC 4447 in order to implement this document. For that reason, you should copy and paste content of the original RFC 4447's IANA Considerations into this document. After that, add a sentence saying that the only change is updating references to point to this document.
draft-ietf-softwire-unified-cpe
Maybe be slightly more specific in the abstract, e.g.: OLD ... this memo specifies a DHCPv6 option whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services. NEW ... this memo specifies a DHCPv6 option whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services by providing a prioritization mechanism.
Thanks for addressing my comments!
I agree with that the title is still not that descriptive of the actual content. (It seems to promise more:-)
mohamed.boucadair@orange.com performed the opsdir review.
draft-ietf-tsvwg-gre-in-udp-encap
I'm balloting no objection, but I have a few comments that may be worth considering: - general: The draft has a structure where you mention requirements in one section, then go into more detail in later sections. While this is a perfectly reasonable structure, it has resulted in a fair bit of redundant 2119 language. In general it's better to avoid that because it can make future updates more error prone. In this case, most of the language is consistent, so it's probably not worth changing. But there are a few cases where the language appears inconsistent, or is restated in sufficiently different ways to be potentially confusing. I've tried to call out specifics, but may have missed some. -1, paragraph 5, first sentence: I found the sentence structure confusing. I think you mean to say that GRE-in-UDP tunnels are not safe to carry arbitrary traffic over the Internet, but it can be read to mean to say that since the internet is an arbitrary traffic environment, it's not safe to use GRE-in-UDP on it. -1, paragraph 6: When might security not be a concern? Would it make sense to start with an assumption that security _is_ a concern, then consider situations for which it might not be? - 6.1, paragraph 1: Previous sections said UDP checksums SHOULD be used for IPv4. Should this section be interpreted to mean that _if_ the checksum is used, it MUST be processes this way? If so, that could use clarification. -6.2, paragraph 2: Does the allowance to use the zero-checksum in some cases violate the MUST for UDP checksums over IPv6? -8, third paragraph: Isn’t this just a restatement of the previous requirement that all traffic carried over default gre-in-udp tunnels must be congestion controlled? -8, paragraph 5: This also seems a restatement of the requirement that traffic on generic tunnels MUST be congestion controlled. Given that you probably don’t select your network path based on the nature of the data, I think it’s better stated in the original terms. -8, last paragraph: Do circuit-breakers really keep non congestion-controlled traffic from “escaping”, or does it mitigate the damage if it does escape? -11, 2nd paragraph: Previous sections just said DTLS can be used if there are security concerns. This is not consistent with that. (I prefer the SHOULD to a "can") -11, last paragraph: Is SHOULD sufficient for this case?
Thanks for the well-written document.
- Section 5: Do you need to say that (non-handshake?) traffic that is not properly protected with DTLS MUST be discarded? - Does 6.2(c) (in the 1st list) suggest some form of new DoS vector? Not sure myself.
Thank you, Lucy for the proposed text on using encryption and DTLS.
I agree with Ben's comments about Section 1.
Rick Casarez <rick.casarez@gmail.com> performed the opsdir review
draft-ietf-6lo-paging-dispatch
I found this text
A Page (say Page N) is said to be active once the Page N Paging
Dispatch is parsed, and as long as no other Paging Dispatch is
parsed.
somewhat unclear. Is it saying
A Page (say Page N) is said to be active once the Page N Paging
Dispatch is parsed, and remains active until another Paging
Dispatch is parsed.
?
I wasn't quite sure what "so far" meant in this text (and temporal references
in RFCs that live forever are somewhat confusing, anyway).
As a result, there is no need so far for restoring the Page 0
parsing context after a context was switched to Page 1, so the
value for the Page 0 Paging Dispatch of 11110000 may not actually
occur in those packets that adhere to 6LoWPAN specifications
available at the time of writing this specification.
Would this be just as correct with "so far" deleted, or am I not understanding
the point you're making?
Thanks for explaining why you're choosing "Specification Required" as your IANA
policy.
draft-ietf-cose-msg
I think this is a fine design and well documented, (though long) and I'm sure we'll clear up the points below quickly enough. Some of them may need some discussion but others are mostly checking. (1) general: I think the inclusion of CDDL is an error here and we'd be better off having someone (if interested) generate the CDDL schema stuff later on when/if CDDL is standardised/stabilised. Including it now creates the potential for breakage unnecessarily IMO. However, the WG did explicitly discuss iirc, so this is just a personal comment that I'm also in the rough on inclusion of CDDL in this spec. (As an example, for someone not familiar with CDDL, the inclusion of fragments interspersed in the text is distracting and potentially puzzling when one gets to the end of section 3.) However, I do think there are places where the CDDL is effectively normative despite what is said in the introduction, the ones I've spotted are below. (Happy to chat about 'em as I may be mistaken.) I also wondered if one could really implement this if all the CDDL was removed from the text, which is what I think would be required if CDDL were really to be informative. Anyway the places I think some more text may be needed are: (1.1) table 2: As-is the value type column seems to me to make CDDL normative. I don't see the natural language version that you said would be normative. (1.2) 4.4, 2nd list point 1: the use of Sig_structure makes the CDDL normative. (Same with the use in 4.5 and Enc_structure in 5.3.) (1.3) 7.1, the key_ops value is only specified in CDDL, in Table 3. (It is well-defined below the table in text though, so this one's borderline.) (1.4) 11.2: it's not clear to me that a reader knows how to handle decoding of the two optional fields at the end (other and SuppPrivInfo) without looking at the CDDL. Can you explain? (That might be just my ignorance of CBOR, but wanted to check.) (2) 3.1, alg: so you're disallowing a setup where the kid alone identifies the key and algorithm to the recipient? That is used in some IETF protocols (OSPF iirc) so rhat's a pity, and will in those (maybe less common) cases consume a few bytes that could otherwise be saved. I think, but am not sure, that the WG already discussed this, but if not, maybe worth a thought? (Or even a 2nd thought:-) And appendix A.1 is really puzzling - as it provides instructions for how to not follow a MUST in the body of the document. (3) 7.1: key_op 8, "derive bits" - I don't think this usage is clear enough, can you say what's meant here? (4) Why not make deterministic ECDSA a MUST? 8.1.1 says: "Applications that specify ECDSA should evaluate the ability to get good random number generation and require deterministic signatures where poor random number generation exists." I don't think that is sufficiently clear, nor realistic, and I don't recall this being discussed on the list (sorry if I'm forgetting) and bad random values are a killer flaw here that has happened in the wild. (5) Table 6, is this 25519 or 448? Where does it say? Sorry if I'm being dumb here, but I don't see where you say which curve is specified, the definition of 'crv' says defined for this alg which I assume means listed in Table 6. (6) section 10: why MUST the kty values be present always? That seems unnecessary in some contexts and I don't get a security reason why it's needed e.g. if there's an alg id somewhere - can you explain? I can see folks omitting this leading to interop problems for not useful reasons. (Same comment applies in other cases where kty is a MUST, e.g. 12.1.2, 12.2.1.) (7) section 11: given that we know people will use human memorable secrets, why have you not defined codepoints for PBES2 (or the more commonly supported?) PBDKF2? I'm fine if there's a reason, or even if it was discussed by the WG, but just wanted to check as I'd worry that folks will use the ones defined here with human memorable secrets no matter what the spec says so giving 'em something more tailored might be better. (OTOH, one could argue that making this apparent might be worse too I guess.) (8) 12.4: Why is no ephemeral-ephemeral (E-E) variant supported? Some protocols will allow for that and it seems wrong to disallow it when it could relatively easily be supported. For some applications where content is dealt with in store-and-forward mode, there may be situations (e.g. provisioning, "introduction") where E-E could be used. As-is, applications wanting that will have to hack the recipient DH-public into a home-grown structure (or use one of the COSE_Key labels from Table 19) and then treat that as ES-DH. That seems likely to lead to non-interop or security errors being made. I'd be fine if you even said how to re-use the structures currently defined for E-E btw and didn't introduce new structures. (9) 16.4: I'm not sure expert review is right here. What if the expert is asked to add SM2/SM4 while there is still no widely available non-Chinese text to describe those? I think the expert ought enforce a "specification required" rule at least and maybe more. (And ought never allow an algorithm with no specification publicly available.) (10) 16.4 (and elsewhere maybe) I think this registry is missing a column - as is being done in the TLS WG, I think there should be a column saying if the IETF is happy enough with an algorithm and that getting a "Y" in that ought require standards action. (Or some similar scheme.) I don't think the standards-track range of codepoints is enough here, e.g. at some time we will want to deprecate things, and at other times we may want to define things for the future on the standards-track but not (yet) recommend their use. The last bullet in 16.11 does help here, but I'd argue that we need to do more to protect the expert (and implementers) from the trickle of vanity/national algorithms/curves that are always being proposed.
- 1.4: the 2nd last paragraph is unclear to me. Probably just
needs re-phrasing.
- 1.5: I'd add a reference to RFC5116.
- 3.1, crit: The statement that security libraries or
application code can handle this is odd - isn't that an API
requirement? (I'm not objecting, but it's odd.)
- 3.1, "content type" is the space there intended? If so,
maybe add quotes or a comma or something to disambiguate the
name and descriptive text? Same for other multi-word names
here.
- 3.1, "all the keys may need to be checked" - really? Or do
you mean all the keys associated with this kid?
- 3.1, IV/Partial IV - I think it's an error to define this
here. What if some algorithm can't use that kind of
(0|partial)^IV but needs something else instead? Shouldn't
all mechanism for handling IVs be defined by the
algorithm/mode? (This isn't a discuss because I can't think
of a good counter example and there'd be other ways around
the problem too probably.)
- 4.1: signingTime is often needed with signatures. Isn't that
common enough to want to define a way to do it, as an option?
- 4.1: If I sign with a private key corresponding to a 2047
or 2049 bit RSA public key modulus, then is it clear what to
put where in the signature bstr? (Yes, that'd be dumb, but I
wonder is what to do well enough defined, as I don't think
you can rule it out in all cases.) Since you don't include
RSA here I guess it's ok to skip this, but maybe you need to
say that such issues need to be handled in the definition of
signature algs.
- 4.3: "cannot bleed" isn't clear enough maybe, give an
example perhaps where the decoder can fail to disambiguate a
boundary?
4.4, last para: I disagree that one must (even lowercase
must) check the signing identity. That's application
behaviour and should be stated here in such concrete terms.
At least s/must also/may also want to/
(Note - the above were comments on -18, but also seem to work
based on -19. Subsequent comments are on -19.)
- 7.1: "starting at the same base IV" - are you missing
"and incrementing" or something? Otherwise I think this
seems unclear.
- 8.2.1: is the phrasing of the 1st para right? would it be
better to say that the value of a key for EdDSA MUST NOT be
used for ECDH and vice-versa. (Or maybe points instead of
keys?)
- 8.2.1: you need a reference for batch signing. (Or could it
be omitted?)
- section 9: I think it'd be good to be clearer about the
strength of truncated MAC values. (And I can't recall the
right thing to say off the top of my head:-)
- 11: RFC2898 is about to be obsoleted by [1]. I suspect it'd
be better to refer to the draft as that should be published
soon. (Same for RFC3447 btw.)
[1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/
- 12.4: Why "OKP"? And saying there's no "simple way" to do
point validation seems fairly opaque, a reference there or
explanatory text would be good. (Ah, it's in section 13,
maybe shuffle the text or include a pointer.) Octet key pair
doesn't seem like that good a name to me btw.
- 12.5: The 1st para seems wrong. (Or at least is unclear to
me.) "Encrypted with <foo> and <bar>" seems ambiguous anyway,
does it mean double encryption or two parallel ciphertexts?
(I assume the former.) What's the algebraic thing you're
trying to explain? It'd be good to provide that for such
relatively complex operations I think. Is this what you mean?
KW(KDF(DH-shared),CEK)
- Table 22: The EC2 or OKP value is fixed per curve and the
cryptographic function being performed so seems unnecessary.
Do you really need it so? Why? (I'm not buying that some
future form of ECC might mean this is needed btw - and
codepoints aren't expensive here, right? So other forms of
ECC can burn codepoints when that's needed and in the
meantime we'd save bytes and complexity.)
- Section 15: Do we have any examples of such a profile? I
think it'd be great if we did and could add an informative
reference here (even if that's to an early I-D).
- section 19: I don't get how ECDSA is normative and the cfrg
curves are not. Same for RFC6979. Maybe these all could do
with checking? (No big deal IMO but maybe worth it.)
- Appendices A.1 (as already noted) and A.2 are a puzzle.
Why say in the body of the document to do <foo> and then an
appendix that says how to do <not-foo>?
- Appendix C and the implementation status section: Many
thanks - great to see that! (I didn't check 'em though:-)
- Thanks also for speedily handling the extensive secdir
review.
[2] https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html
A few minor comments:
Substantive:
-1.3, definition of "int": Is that really _unsigned_ or negative? Or is it a
signed integer than can be negative or non-negative? (contrasting with uint?)
(Or is int merely a parent of nint and uint?)
-3: What is the scope of uniqueness for map labels? I expected it to be the
map, but the text immediately aftewards suggests the scope may be the whole
message. Whatever the answer, it would help to be explicit.
- Informative References: [I-D.irtf-cfrg-eddsa]: Other algorithm references are
normative. Why not this one?
Editorial:
"Contributing to this Memo" section: Is this intended to stay in the final RFC?
If not, it might be worth a note to the RFC editor.
-1, first paragraph, last sentence: Comma splice.
-1, 2nd paragraph: MAC usually expands to Message Authentication _Code_.
-2, 6th paragraph, last sentence: s/method/methods (assuming the following
list is a list of methods, and not steps in a method.
-3, definition of protected:
-4.1, "COSE_Sign_Tagged = #6.991(COSE_Sign) ; Replace 991 with TBD1": Is the
comment intended as a note to the RFC editor? If so, it might be helpful to
label it as such.
-4.3, first bullet: "If multiple items are included, care needs to be taken
that data
cannot bleed between the items."
Is this talking about data framing, or something else?
I'm going to be a No Objection for this doc no matter what, so it's safe to answer my question :-) This is for use with CoAP, right? Would you rely on CoAP for fragmentation, if that's required?
Stephen, I've seen several documents recently that "reference CDDL informatively" and I don't believe that. So the whole situation with CDDL makes me rather unhappy. Comments on the document: This is a well written document, despite its length. Thank you for that. Some specific comments: I am pretty sure that the CDDL reference is normative. On page 13: media type syntax reference is outdated, you should reference RFC 6838, Section 4.2 has relevant ABNF. In Media type registrations: Applications that use this media type: To be identified This answer is not useful, please specify types of applications that will be using these media types. Something along the lines of what you specified in the Introduction.
draft-ietf-ipsecme-ddos-protection
Some questions:
1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator should
ignore it and try to send reply without the puzzle solution, as there might be
still a change to get served…? If it then received another packet with puzzle
it can still solve it and reply.
2) sec 7.1.4: Does „the Responder MUST verify the puzzle solution“? Maybe there
are cases where the burden for the initiator is high enough by requesting the
solution that there is already an effect even if the responder decides to not
verify it…?
3) also sec 7.1.4: Does the following sentence really makes sense? How doe the
responser know? Maybe just remove it?
„The more time the Initiator spent solving the puzzles, the higher
priority it should receive.“
4) sec 7.2.1.1 says „the Responder would be able to estimate the computational
power of the Initiator and select the difficulty level accordingly.“ How would
it estimate the computational power? Based on the reply time? Wouldn’t it also
need to know the RTT and current congestion level then?
5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the PUZZLE
notification and the Initiator supports puzzles, it MUST solve the puzzle.“
Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“?
Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the
PUZZLE notification…“)
Two general comments/questions:
1) What’s about the additional cpu load of the responder to calculate the
puzzle. Can that be a problem? Are there any strategies to keep that low
(recalculation/caching/reuse)? How long should things be cached/used? Maybe add
a few sentences in the Operational Considerations section!
2) Would it make sense to also give a field to change the number of requested
keys to scale load? Or why was it decided to use a fixed number of 4 here?
I tempted to ballot Yes on on the document. I hope it will get widespread deployment. Please excuse my ignorance: Puzzle Solution Payload format - I don't see the new payload type specified in the diagram. Where is it included?
This is a nicely written document... thanks!
- I vaguely recalled that puzzles and IPR rang a bell. Did
the WG consider [1]? If not, and if it helps, I'm fine with
making a 3rd party declaration on that and last call could be
done again. Or maybe there's a better way to handle it. Or
maybe the WG considered it and are happy enough already that
it's not relevant or about to expire or abandoned or
something. ("Not relevant" would puzzle me:-)
[1] https://datatracker.ietf.org/ipr/417/
- section 3: "if certificates are involved" - you could note
here that involving certificates can introduce a network
based delay (OCSP, CRLs etc) that's a little different from
CPU consumption. (But it's a nit, and you do note a similar
issue in 4.7.)
- 4.2: "ratelimits should be done based on either the /48 or
/64" - would it be better to say "something between a /48 and
a /64" maybe? Don't some ISPs assign things in-between?
- 4.4: Did you consider making the "4 keys" requirement tied
to the PRF algorithm identifier? That would allow for a
future where e.g. 6 keys are needed for the same PRF, if that
were ever useful. (Without changing current implementations.)
I guess you'd need a separate IANA registry that'd initially
duplicate stuff in that case so maybe not worth doing. (And
could be done later.)
- 7.1.1 - you don't clearly say if the cookie value here can
be a new one or should be the same as one previously used (if
one was previously used). That may just be my ignorance of
IPsec cookies though, but I wondered if there are any cases
where the initiator gets to work away on the puzzle ahead of
time if the same cookie is used for multiple interactions.
There's not much (or zero) of an improvement to the attack
here, though maybe the attacker could more easily offload
puzzle solving to someone else in that case?
"A typical Initiator or bot-net member in 2014 can perform slightly less than a million hashes per second per core" Is this supposed to say 2014? Struck me as a little weird.
draft-ietf-i2rs-protocol-security-requirements
Version 8 resolved my discuss point for section 3.4. Thanks! I don't think it resolved my discuss point for 3.2. I'm clearing anyway, because I think my point has been made. I would prefer the language to say that anything not explicitly marked as non-confidential in the relevant data model MUST be sent over a protected transport. But I will leave it to the authors to do the right thing. I will leave my non-discuss comments below for reference. I think version 8 resolves at least some of them. Any remaining are up to you; none of them are show stoppers. -2.1: I am on the fence about other's comments about copying definitions here--but if you do copy them here, it seems strange to not mention "client" or "agent". I agree with Alissa about equating privacy and confidentiality. -3.1,: I’m confused by the first paragraph. I don’t find strings of the form of SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right? It’s not clear to me how 5 and 6 differ. Is it just a matter of the additional “before establishing a connection” part in 6? -3.4: Isn't 15 simply a restatement of the third item under 14? 3.5: The MAYs in 19 and 20 seem like statements of fact. (That is, do they simply recognize reality, or to they grant permission?)
A few comments: 1) I don't think copy&paste from RFC4949 is necessary. I would recommend to remove this part and just name the definitions that are needed. 2) The following sentence seems to indicate that the refernce to RFC4949 should be normative. "The transfer of data via the I2RS protocol has the property of data integrity described in [RFC4949]." As I don't think this is needed, I would recommend to rather spell out the properties here in this sentence. Also, to be honstest I not sure what this sentence tells me at all. So maybe stating clearing what you mean (instead of just having the reference) would help anyway. 3) To me it's not really clear why there are several requirments docs (that also are connected and refer each other; see e.g. section 3.6 and SEC-REQ-16). The actually context of this doc is only 4 pages (3.1-3.6). Couldn't those docs be combined to one requiremnet doc? 4) Section 3.1 says: "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements:" Why is this needed is RFC7921 already sets these requirements?
Thanks for adding REQ-16. Comments below are unchanged from my previous discuss ballot. - The topic of marking things as allowing insecure read access has been discussed a lot so I won't get into it again. - section 4: "Data passed over the insecure transport channel MUST NOT contain any data which identifies a person or any "write" transactions." I don't get what identifying a write transaction might mean? - 4.1: "AAA protocols MAY be used to distribute these identifiers, but other mechanism can be used." If I'm doing TLS with mutual-auth, then I need a private key and certificate. I don't think AAA protocols can transport those (and they probably ought not) so I'm not sure what's meant here. - 4.2: What do "valid identity" and "valid identifier" mean? If the same then use the same terms. But I think you need to define "validity" or else say that work needs to be done later. - 4.3: I think you're saying here that the i2rs client is trusted to simply assert the secondary identifier. If so, then saying that would be good. If not, then I don't know what you mean. - 4.4: I still don't see why it'd not be better to use a different protocol for the non-secure stuff and avoid all the potential discussion and pitfalls of trying to do all this in one protocol. - 4.4: "It is mandatory to use (MTU) on any I2RS client's Write transaction or the configuration of an Event Scope transaction." Which "it" do you mean? - 4.4: The BCP107 stuff is still not useful. - 4.5: "detect when the data integrity is questionable" - I've no idea what that means. Nor what it could mean. Can you explain?
I have the same concerns as others around the secure transport, but I'm not
putting in a DISCUSS because the concerns are already well represented. Just
one additional comment on the topic:
I think there is a contradiction between SEC-REQ-09 ("The I2RS protocol MUST be
able to transfer data over a secure transport and optionally MAY be able to
transfer data over a non-secure transport") and this text from Section 3.
(Security-Related Requirements): "…MUST be able to exchange data over a secure
transport, but some functions may operate on a non-secure transport." The
latter text talks bout "some functions" using a non-secure transport, while
SEC-REQ-09 implies that everything may use it.
Other comments from Section 3.1. (Mutual authentication of an I2RS client and
an I2RS Agent)
-- The text says that the "I2RS architecture [I-D.ietf-i2rs-architecture] sets
the following requirements". I'm not sure what you mean my "sets", as there
are no requirements (labeled as such) in the architecture document. If there
are, then this section doesn't seem to be needed (as others have mentioned).
Maybe "these requirements are derived from the architecture", or something
similar may be more appropriate.
-- What is a "valid identifier"? A couple of requirements where a "valid
identifier" "MUST" be confirmed are listed, but no indication as to what that
may be in this document or the architecture one. The definition of identifier
doesn't help…
-- SEC-REQ-05 and SEC-REQ-06 sound the same to me. What is the difference?
BTW, if there is a difference, instead of "IETF" I think that "standardized"
may be better.
s/One mechanism such mechanism/One such mechanism/
Thank you very much for your re-write of this draft. It reads much better and as such, should be a more helpful document for the WG. The requirements are more clearly listed and the new section breaks with explanations are also a positive improvement. I do appreciate the new language in section 3.2. I still don't agree with the model, but I wouldn't block on the scope and method with the way this is currently written. I favor marking when data is confidential, but you've been careful in how you have scoped this requirement.
Thanks for addressing my DISCUSS and COMMENTs.
draft-ietf-tictoc-multi-path-synchronization
Does this increase the DDoS amplification potential of NTP (and/or PTP)? Seems like it must, to at least some extent. I'd suggest noting that and warning, in particular dual-ended masters, to consider that.
I thought Stewart's "chicken and egg" response to Mirja's Discuss was worth considering as an addition to the document that explains why the document is making this assumption.
"Each NTP clock has a set of N IP addresses. The assumption is that
the server information, including its multiple IP addresses is
known to the NTP clients."
A protocol specification should not make this assumption but describe a
mechanism how a client gets to know about these IP addresses. However, this
draft does not read like a protocol specification anyway; it rather reads like
an informational document leaveraging existing mechanisms to use multiples
pathes (see further below).
Further, this draft claims in the abstract that this mechanism could enhance
security which is not further discussed (should be added to the security
considerations section!). However, I would guess that it depends on the choosen
combining algorithm if it enhances security or not (or even worsens it). If so
that really needs to be further discussed!
This drafts reads rather like a research paper than an RFC. Especailly saying that "The Multi-Path Precision Time Protocol (MPPTP) and Multi-Path Network Time Protocol (MPNTP) define an additional layer that extends the existing PTP and NTP without the need to modify these protocols. " is completely overstating. I really don't see that this doc defines new protocols or a new layer. I would strongly recommend to not give the describe mechanisms a name (like Multi-Path Precision Time Protocol (MPPTP) and Multi-Path Network Time Protocol (MPNTP)) as these are no protocols. I further recommend to publish this document instead as an informational RFC that describes how to leverages multiple pathes without protocol changes. Also section 6 that only gives references to other docs would be acceptable for an informational draft but for a protocol spec. A spec should provide an implementation recommendation by provding a default algorithm. Some editorial commenta: I would recommend to shorten the abstract by removing or moving the first part, potentially into the introduction instead, and only leave this part: "This document describes a multi-path approach to the Network Time Protocol (NTP) and the Precision Time Protocol (PTP) over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks. The multi-path approach can significantly contribute to clock accuracy, security and fault tolerance." Also section 3 and 4 could be completely removed or shorten to 2-3 paragraph that could also be integarted into the introdcution.