Merge pull request #1461 from ietf-tapswg/mw-api-securitycons

Security Considerations: a first stab at #1460

draft-ietf-taps-impl.md

@@ -1154,7 +1154,7 @@ This document has no actions for IANA.
 
 # Security Considerations
 
-{{I-D.ietf-taps-arch}} outlines general security considerations 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.
 
 ## Considerations for Candidate Gathering
 

draft-ietf-taps-interface.md

@@ -766,7 +766,7 @@ is equivalent to `WithIPAddress` with an unscoped address and `WithInterface ` t
 
 Applications creating Endpoint objects using `WithHostName` SHOULD provide 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
+needing to use DNS search domains for name resolution, which might lead to inconsistent or unpredictable
 behavior.
 
 The design of the API MUST NOT permit an Endpoint object to be configured with multiple Endpoint Identifiers of the same type.
@@ -3630,6 +3630,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}} provides 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.
+
 The described API is used to exchange information between an application and the Transport Services system. While
 it is not necessarily expected that both systems are implemented by the same authority, it is expected
 that the Transport Services Implementation is either provided as a library that is selected by the application
@@ -3672,6 +3674,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 to use DNS search domains for name resolution, which might lead to inconsistent or unpredictable behavior.
 
 These communication activities are not different from what is used today. However,
 the goal of a Transport Services system is to support