Skip to content

Commit

Permalink
Added asides for different experimental aspects
Browse files Browse the repository at this point in the history
  • Loading branch information
BrianSipos committed Sep 12, 2022
1 parent 6469f12 commit 43f7ccb
Show file tree
Hide file tree
Showing 4 changed files with 32 additions and 133 deletions.
110 changes: 5 additions & 105 deletions .cproject
Original file line number Diff line number Diff line change
Expand Up @@ -3,128 +3,28 @@

<storageModule moduleId="org.eclipse.cdt.core.settings">

<cconfiguration id="de.marw.cmake.cdt.lsp.config.cmake.318172198">
<cconfiguration id="org.eclipse.cdt.core.default.config.415645785">

<storageModule buildSystemId="org.eclipse.cdt.managedbuilder.core.configurationDataProvider" id="de.marw.cmake.cdt.lsp.config.cmake.318172198" moduleId="org.eclipse.cdt.core.settings" name="Default">
<storageModule buildSystemId="org.eclipse.cdt.core.defaultConfigDataProvider" id="org.eclipse.cdt.core.default.config.415645785" moduleId="org.eclipse.cdt.core.settings" name="Configuration">

<externalSettings/>

<extensions>

<extension id="org.eclipse.cdt.core.MachO64" point="org.eclipse.cdt.core.BinaryParser"/>

<extension id="org.eclipse.cdt.core.Cygwin_PE" point="org.eclipse.cdt.core.BinaryParser"/>

<extension id="org.eclipse.cdt.core.PE" point="org.eclipse.cdt.core.BinaryParser"/>

<extension id="org.eclipse.cdt.core.GNU_ELF" point="org.eclipse.cdt.core.BinaryParser"/>

<extension id="org.eclipse.cdt.core.ELF" point="org.eclipse.cdt.core.BinaryParser"/>

<extension id="org.eclipse.cdt.core.GASErrorParser" point="org.eclipse.cdt.core.ErrorParser"/>

<extension id="org.eclipse.cdt.core.GmakeErrorParser" point="org.eclipse.cdt.core.ErrorParser"/>

<extension id="org.eclipse.cdt.core.GLDErrorParser" point="org.eclipse.cdt.core.ErrorParser"/>

<extension id="org.eclipse.cdt.core.MakeErrorParser" point="org.eclipse.cdt.core.ErrorParser"/>

<extension id="org.eclipse.cdt.core.VCErrorParser" point="org.eclipse.cdt.core.ErrorParser"/>

<extension id="org.eclipse.cdt.core.CWDLocator" point="org.eclipse.cdt.core.ErrorParser"/>

<extension id="org.eclipse.cdt.autotools.core.ErrorParser" point="org.eclipse.cdt.core.ErrorParser"/>

<extension id="org.eclipse.cdt.core.GCCErrorParser" point="org.eclipse.cdt.core.ErrorParser"/>

</extensions>

</storageModule>

<storageModule moduleId="cdtBuildSystem" version="4.0.0">

<configuration artifactName="${ProjName}" buildArtefactType="de.marw.cmake.cdt.lsp.buildArtefactType.cmake" buildProperties="org.eclipse.cdt.build.core.buildArtefactType=de.marw.cmake.cdt.lsp.buildArtefactType.cmake" description="Default coming from cmake" id="de.marw.cmake.cdt.lsp.config.cmake.318172198" name="Default" parent="de.marw.cmake.cdt.lsp.config.cmake">

<folderInfo id="de.marw.cmake.cdt.lsp.config.cmake.318172198." name="/" resourcePath="">

<toolChain id="de.marw.cmake.cdt.lsp.config.cmake.toolChain.691452843" name="CMake driven" nonInternalBuilderId="de.marw.cmake.cdt.lsp.builder.portable" superClass="de.marw.cmake.cdt.lsp.config.cmake.toolChain">

<targetPlatform id="de.marw.cmake.cdt.lsp.targetPlatform.cmake.988723344" name="Any Platform" superClass="de.marw.cmake.cdt.lsp.targetPlatform.cmake"/>

<builder buildPath="/acme-dtnnodeid/build/Default" id="de.marw.cmake.cdt.lsp.builder.portable.1793867226" name="CMake Builder" superClass="de.marw.cmake.cdt.lsp.builder.portable"/>

<tool id="de.marw.cmake.cdt.lsp.toolchain.tool.dummy.675438756" name="CMake driven Languages Proxy" superClass="de.marw.cmake.cdt.lsp.toolchain.tool.dummy">

<inputType id="de.marw.cmake.cdt.lsp.inputType.c.1143374457" superClass="de.marw.cmake.cdt.lsp.inputType.c"/>

<inputType id="de.marw.cmake.cdt.lsp.inputType.cpp.1766741800" superClass="de.marw.cmake.cdt.lsp.inputType.cpp"/>

</tool>

</toolChain>

</folderInfo>

</configuration>
<extensions/>

</storageModule>

<storageModule moduleId="org.eclipse.cdt.core.externalSettings"/>

<storageModule moduleId="de.marw.cdt.cmake.core.settings">

<linux command="cmake" generator="UnixMakefiles" use-default="true">

<defs/>

<undefs/>

</linux>

</storageModule>

</cconfiguration>

</storageModule>

<storageModule moduleId="cdtBuildSystem" version="4.0.0">

<project id="acme-dtnnodeid.de.marw.cmake.cdt.lsp.projectType.395084649" name="CMake driven" projectType="de.marw.cmake.cdt.lsp.projectType"/>

</storageModule>

<storageModule moduleId="scannerConfiguration">
<storageModule moduleId="org.eclipse.cdt.core.pathentry">

<autodiscovery enabled="true" problemReportingEnabled="true" selectedProfileId=""/>
<pathentry excluding="**/CMakeFiles/**" kind="out" path="build"/>

</storageModule>

<storageModule moduleId="org.eclipse.cdt.core.LanguageSettingsProviders"/>

<storageModule moduleId="refreshScope" versionNumber="2">

<configuration configurationName="Default">

<resource resourceType="PROJECT" workspacePath="/acme-dtnnodeid"/>

</configuration>

<configuration configurationName="Debug">

<resource resourceType="PROJECT" workspacePath="/acme-dtnnodeid"/>

</configuration>

<configuration configurationName="Release">

<resource resourceType="PROJECT" workspacePath="/acme-dtnnodeid"/>

</configuration>

</storageModule>

<storageModule moduleId="org.eclipse.cdt.make.core.buildtargets"/>

<storageModule moduleId="org.eclipse.cdt.internal.ui.text.commentOwnerProjectMappings"/>

</cproject>
17 changes: 1 addition & 16 deletions .project
Original file line number Diff line number Diff line change
Expand Up @@ -5,31 +5,16 @@
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>org.eclipse.cdt.managedbuilder.core.genmakebuilder</name>
<triggers>clean,full,incremental,</triggers>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.cdt.core.cBuilder</name>
<triggers>clean,full,incremental,</triggers>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.cdt.managedbuilder.core.ScannerConfigBuilder</name>
<triggers>full,incremental,</triggers>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.eclipse.cdt.cmake.core.cmakeNature</nature>
<nature>org.python.pydev.pythonNature</nature>
<nature>org.eclipse.cdt.core.cnature</nature>
<nature>org.eclipse.cdt.core.ccnature</nature>
<nature>org.eclipse.cdt.managedbuilder.core.managedBuildNature</nature>
<nature>org.eclipse.cdt.managedbuilder.core.ScannerConfigNature</nature>
<nature>org.eclipse.cdt.cmake.core.cmakeNature</nature>
</natures>
</projectDescription>
17 changes: 10 additions & 7 deletions spec/dictionary.txt
Original file line number Diff line number Diff line change
Expand Up @@ -7,17 +7,19 @@ BCB
BCP
BP
BPbis
BPSec
BPSEC
BPSec
BPv
bstr
bundleEID
bundleSecurity
CAs
CBOR
cddl
CDDL
cddl
chal
correlator
COSE
CRC
CRLs
cryptographic
Expand All @@ -27,17 +29,18 @@ dereference
digitalSignature
disambiguating
DKIM
dns
DNS
dtn
dns
DTN
dtn
EID
extensionRequest
FIPS
HTTPS
IANA
IETF
incorrectResponse
interoperable
ip
ipn
JSON
Expand All @@ -60,8 +63,8 @@ POSTs
pre
rejectedIdentifier
RKF
rtt
RTT
rtt
SHA
SHS
SMI
Expand All @@ -73,10 +76,10 @@ unicast
unicode
uniformResourceIdentifier
untrusted
uri
URI
uri
URIs
url
Wireshark
xFFFF
XPath
XPath
21 changes: 16 additions & 5 deletions spec/draft-ietf-acme-dtnnodeid.xml
Original file line number Diff line number Diff line change
Expand Up @@ -53,11 +53,11 @@ Once an ACME server validates a Node ID, either as a pre-authorization of the "b
Because a single order can contain multiple identifiers of multiple types, there can be operational issues for a client attempting to, and possibly failing to, validate those multiple identifiers as described in <xref target="sec-multiple-claims"/>.
Once a certificate is issued for a Node ID, how the ACME client configures the Bundle Protocol (BP) agent with the new certificate is an implementation matter.
</t>
<t>
<aside><t>
The emergent properties of DTN naming and BP security are still being developed and explored, especially between different organizational and administrative domains, so the "experimental" status of this document is related more to the practical utility of this kind of Node ID validation than to the validation method itself.
The original use case is in large or cross-organizational networks where a BP node can be trusted to be allocated and added to a network, but the method of certificate validation and issuance is desired to be in-band on the network rather than configured solely through a side channel using bespoke or manual protocols.
Because this mechanism is so similar to other validation methods, specifically <xref target="RFC8823"/>, it is expected to have few implementation difficulties or interoperability issues.
</t>
</t></aside>
<section>
<name>Scope</name>
<t>
Expand Down Expand Up @@ -511,7 +511,7 @@ See <xref target="RFC4086"/> for additional information on randomness requiremen
One pair <bcp14>SHALL</bcp14> consist of key 4 with value of an array containing acceptable hash algorithm identifiers.
The array <bcp14>SHALL</bcp14> be ordered in descending preference, with the first item being the most preferred.
The array <bcp14>SHALL</bcp14> contain at least one item.
Each algorithim identifier <bcp14>SHALL</bcp14> correspond to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry of <xref target="IANA-COSE"/>.
Each algorithm identifier <bcp14>SHALL</bcp14> correspond to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry of <xref target="IANA-COSE"/>.
</li>
</ul>
</dd>
Expand Down Expand Up @@ -601,7 +601,7 @@ One pair <bcp14>SHALL</bcp14> consist of key 2 with value of ACME challenge <tt>
</li>
<li>
One pair <bcp14>SHALL</bcp14> consist of key 3 with value of a two-element array containing the pair of a hash algorithm identifier and the hash byte string.
The algorithim identifier <bcp14>SHALL</bcp14> correspond to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry of <xref target="IANA-COSE"/>.
The algorithm identifier <bcp14>SHALL</bcp14> correspond to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry of <xref target="IANA-COSE"/>.
</li>
</ul>
</dd>
Expand Down Expand Up @@ -652,9 +652,15 @@ The lack of a response within the expected response interval, as defined in <xre
<section anchor="sec-multi-perspective">
<name>Multi-Perspective Validation</name>
<t>
To avoid possible on-path attacks in certain networks, an ACME server can perform a single validation using multiple challenge bundle sources or via multiple routing paths.
To avoid on-path attacks in certain networks, an ACME server can perform a single validation using multiple challenge bundle sources or via multiple routing paths.
This technique is called multi-perspective validation as recommended in <xref section="10.2" target="RFC8555"/> and an implementation used by Let's Encrypt is described in <xref target="LE-multi-perspective"/>.
</t>
<aside><t>
Part of the experimental nature of this validation method, and the bundle protocol more generally, is understanding its vulnerability to different kinds of on-path attacks.
Some attacks could be based on the topology of the BP overlay network, while others could be based on the underlying (internet protocol) network topology.
Because not all of the attack surfaces of this validation method are known or fully understood the usefulness of the technique described in this section is also not assured.
The point of these requirements is so that both the ACME client and server have consistent logic for handling this technique.
</t></aside>
<t>
When required by policy, an ACME server <bcp14>SHALL</bcp14> send multiple challenge bundles from different sources in the DTN network.
When multiple Challenge Bundles are sent for a single validation, it is a matter of ACME server policy to determine whether or not the validation as a whole is successful.
Expand All @@ -678,6 +684,11 @@ In this mechanism a routing node in a DTN sub-network attests to the origination
The bundle receiver then need not trust the source of the bundle, but only trust this security source node.
The receiver needs policy configuration to know which security sources are permitted to attest for which bundle sources.
</t>
<aside><t>
The usefulness of the integrity gateway to this validation method is experimental because it is not a settled matter how naming authority in a DTN is either allocated, delegated, or enforced.
It is also not defined how the organization running the CA (and its ACME server) can delegate some level of trust to a different organization running a connected DTN with a security gateway.
The organization running the integrity gateway would need to apply some minimal amount of policy to nodes running behind it, such as patterns to their Node IDs, which would behave conceptually similar to delegation of sub-domains in the domain name system (DNS) but without the online interaction of DNS.
</t></aside>
<t>
An integrity gateway <bcp14>SHALL</bcp14> validate the Source Node ID of a bundle, using local-network-specific means, before adding a BIB to the bundle.
The exact means by which an integrity gateway validates a bundle's source is network-specific, but could use physical-layer, network-layer or BP-convergence-layer authentication.
Expand Down

0 comments on commit 43f7ccb

Please sign in to comment.