jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-external-psk-importer

Commentary: Make registry title explicit and point to request procedures 8447 . 
 Thanks ,  !
Paragraph (version B):
This specification introduces a new registry for TLS KDF identifiers,
titled "TLS KDF Identifiers", under the existing "Transport Layer
Security (TLS) Parameters" heading.
Paragraph (version B):
Values in the range 0xff00-0xffff are reserved for Private Use
RFC8126.
Draft: draft-ietf-tls-external-psk-importer

Commentary: This is n't perfect either , but it concentrates on the functional side , namely that we use a sequence of bytes to identify PSKs .
Paragraph (version A):
External Identity: The identity of an EPSK.
Paragraph (version B):
External Identity: A sequence of bytes used to identify an EPSK.
Paragraph (version A):
Imported Identity: The identity of an Imported PSK as sent on the
wire.
Paragraph (version B):
Imported Identity: A sequence of bytes used to identify an IPSK.
Draft: draft-ietf-tls-external-psk-importer

Commentary: This includes a pointer to formal analysis , once complete . 
 Partially fixed by . Closing for now .
Paragraph (version A):
DISCLAIMER: This is a WIP draft and has not yet seen significant
security analysis.
Paragraph (version B):
The Key Importer security goals can be roughly stated as follows:
avoid PSK re-use across KDFs while properly authenticating endpoints.
When modeled as computational extractors, KDFs assume that input
keying material (IKM) is sampled from some "source" probability
distribution and that any two IKM values are chosen independently of
each other Kraw10.  This source-independence requirement implies that
the same IKM value cannot be used for two different KDFs.
Paragraph (version B):
PSK-based authentication is functionally equivalent to session
resumption in that a connection uses existing key material to
authenticate both endpoints.  Following the work of BAA15, this is a
form of compound authentication.  Loosely speaking, compound
authentication is the property that an execution of multiple
authentication protocols, wherein at least one is uncompromised,
jointly authenticates all protocols.  Authenticating with an
externally provisioned PSK, therefore, should ideally authenticate
both the TLS connection and the external provision process.
Typically, the external provision process produces a PSK and
corresponding context from which the PSK was derived and in wihch it
should be used.  We refer to an external PSK without such context as
"context free".
Paragraph (version B):
Externally provisioned PSKs imported into TLS achieve compound
authentication of the provision step(s) and connection.
Paragraph (version B):
Context-free PSKs only achieve authentication within the context
of a single connection.
Paragraph (version B):
Imported PSKs are used as IKM for two different KDFs.
Paragraph (version B):
Imported PSKs do not collide with existing PSKs used for TLS 1.2
and below.
Paragraph (version B):
Imported PSKs do not collide with future protocol versions and
KDFs.
Draft: draft-ietf-tls-external-psk-importer

Commentary: To make external psk importers more featureful it makes sense to take advantage of the HKDF already in use . By providing a field for extra context we can avoid protocol layering attacks . For example this change allows us to securely bind one TLS session to another , providing layered context . 
 See : 
 This was addressed with the slot via and . Closing ! 
 Thanks ! This is much more understandable than the previous PR . : -)LGTM with the suggested name change !
Paragraph (version B):
ImportedIdentity.context MUST include the context used to derive the
EPSK, if any exists.  If the EPSK is a key derived from some other
protocol or sequence of protocols, ImportedIdentity.context MUST
include a channel binding for the deriving protocols RFC5056.  If any
secrets are agreed in earlier protocols they SHOULD be included in
ImportedIdentity.context CCB.
Draft: draft-ietf-tls-external-psk-importer

Commentary: Discussed in Singapore ; will merge and add security considerations motivation in a followup to . 
 The document says : Aside from this statement needing update in light of the changes to the binder label , the core statement here is n't expanded upon . The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of . 
 Fixed in . 
 This seems harmless , but it is predicated on a need to separate keys that I do n't understand . Is there more rationale somewhere ?
Paragraph (version B):
This new label differentiates non-imported and imported external
PSKs.  Specifically, a client and server will negotiate use of an
external PSK if and only if (a) both endpoints import the PSK or (b)
neither endpoint imports the PSK.  The "binder_key" is a leaf key.
Therefore, changing its computation doesn't affect any other key.