Security Considerations: a first stab at #1460 #1461
Conversation
draft-ietf-taps-interface.md
Outdated
| @@ -3556,6 +3556,8 @@ in {{security-parameters}}. It does not recommend use (or disuse) of specific | |||
| algorithms or protocols. Any API-compatible transport security protocol ought to work in a Transport Services system. | |||
| Security considerations for these protocols are discussed in the respective specifications. | |||
|
|
|||
| {{I-D.ietf-taps-arch}} outlines general security considerations and requirements for any system that implements the Transport Services architecture. These include recommendations of relevance to the API, e.g. regarding the use of keying material. | |||
There was a problem hiding this comment.
/outlines/provides/ ? (i didn't much like "outlines ... requirements"
There was a problem hiding this comment.
ok by me (I don't see the problem, but I'm not a native speaker). This applies to the -impl draft as well, I'll propose a fix to both.
draft-ietf-taps-interface.md
Outdated
| @@ -3598,6 +3600,7 @@ of potentially limited scope for alternate path discovery during Connection | |||
| establishment, as well as potential additional information leakage about | |||
| application interest when used with a resolution method (such as DNS without | |||
| TLS) which does not protect query confidentiality. | |||
| Names used with the Transport Services API SHOULD be fully-qualified domain names (FQDNs); not providing an FQDN will result in the Transport Services Implementation needing to resolve using DNS search domains, which might lead to inconsistent or unpredictable behavior. | |||
There was a problem hiding this comment.
/needing to resolve/needing it to be resolved/
There was a problem hiding this comment.
Side note, this particular wording, from @tfpauly, exists in two places.
I think "needing it to be resolved" makes the sentence structure a little complex... how about:
"needing to use DNS search domains for name resolution" ?
There was a problem hiding this comment.
I am thinking the whole time whether a "with FQDN" in addition to "with hostname" would be a better solution here. that makes it totally clear whether a programmer expects canonisation or not
| @@ -1154,7 +1154,7 @@ This document has no actions for IANA. | |||
|
|
|||
| # Security Considerations | |||
|
|
|||
| {{I-D.ietf-taps-arch}} outlines general security consideration and requirements for any system that implements the Transport Services architecture. {{I-D.ietf-taps-interface}} provides further discussion on security and privacy implications of the Transport Services API. This document provides additional guidance on implementation specifics for the Transport Services API and as such the security considerations in both of these documents apply. The next two subsections discuss further considerations that are specific to mechanisms specified in this document. | |||
| {{I-D.ietf-taps-arch}} provides general security consideration and requirements for any system that implements the Transport Services architecture. {{I-D.ietf-taps-interface}} provides further discussion on security and privacy implications of the Transport Services API. This document provides additional guidance on implementation specifics for the Transport Services API and as such the security considerations in both of these documents apply. The next two subsections discuss further considerations that are specific to mechanisms specified in this document. | |||
There was a problem hiding this comment.
JFYI, for others: this was a wording suggestion from @gorryfair - and this text appears in both the interface and the implementation drafts, so this is why I suggest to change it here too.
#1460 raises three points:
"I'm not sure that the model really expands from netflows to IP flows (or TOR)
in the future." => not addressed here.
re-using the same credentials with different protocols/auth mechanisms. => I think the fourth paragraph of the -arch Security Considerations speaks to this; instead of repeating it, I thought it would be better to point at this document (similar to how the implementation draft does it), as its security considerations should apply to all of the API draft anyway.
not using an FQDN punts a security risk mostly to the application: I more or less copied the wording about the no-FQDN security risk from section 6.1, it seems fair to repeat this here as a warning.