The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-rfc8446bis-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Eric Rescorla | ||
| Last updated | 2023-03-28 (Latest revision 2023-03-26) | ||
| Replaces | draft-rescorla-tls-rfc8446-bis | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | Christopher A. Wood | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | caw@heapingbits.net |
draft-ietf-tls-rfc8446bis-07
Independent Submission P. Fleming
Request for Comments: 7612 Independent
Obsoletes: 3712 I. McDonald
Category: Informational High North
ISSN: 2070-1721 June 2015
Lightweight Directory Access Protocol (LDAP):
Schema for Printer Services
Abstract
This document defines a schema, object classes, and attributes, for
Printers and print services, for use with directories that support
the Lightweight Directory Access Protocol (RFC 4510). This document
is based on the Printer attributes listed in Appendix E of "Internet
Printing Protocol/1.1: Model and Semantics" (RFC 2911). Additional
Printer attributes are based on definitions in "Printer MIB v2" (RFC
3805), "PWG Command Set Format for IEEE 1284 Device ID v1.0" (PWG
5107.2), "IPP Job and Printer Extensions - Set 3 (JPS3)" (PWG
5100.13), and "IPP Everywhere" (PWG 5100.14).
This memo is an Independent Submission to the RFC Editor by the
Internet Printing Protocol (IPP) Working Group of the IEEE-ISTO
Printer Working Group (PWG), as part of their PWG "IPP Everywhere"
(PWG 5100.14) project for secure mobile printing with vendor-neutral
Client software.
This document obsoletes RFC 3712.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7612.
Fleming & McDonald Informational [Page 1]
RFC 7612 LDAP Schema for Printer Services June 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction ....................................................4
1.1. Relationship to SLP Printer Service ........................4
1.2. Source of LDAP Printer Attributes ..........................4
1.3. Source of LDAP Printer Schema OIDs .........................5
1.3.1. IBM Assignments for RFC 3712 ........................5
1.3.2. IEEE-ISTO PWG Assignments ...........................5
1.4. Rationale for Design Choices ...............................5
1.4.1. Rationale for Using DirectoryString Syntax ..........5
1.4.2. Rationale for Using caseIgnoreMatch .................6
1.4.3. Rationale for Using caseIgnoreSubstringsMatch .......7
2. Conventions Used in This Document ...............................8
2.1. Requirements Language ......................................8
2.2. LDAP Schema Descriptions ...................................8
2.3. Abbreviations ..............................................8
3. Definition of Object Classes ....................................9
3.1. slpServicePrinter .........................................10
3.2. printerAbstract ...........................................10
3.3. printerService ............................................11
3.4. printerServiceAuxClass ....................................12
3.5. printerIPP ................................................12
3.6. printerLPR ................................................12
4. Definition of Attribute Types ..................................13
4.1. printer-uri ...............................................15
4.2. printer-xri-supported .....................................16
4.3. printer-name ..............................................18
4.4. printer-natural-language-configured .......................19
4.5. printer-location ..........................................19
4.6. printer-info ..............................................20
4.7. printer-more-info .........................................21
4.8. printer-make-and-model ....................................21
4.9. printer-ipp-versions-supported ............................22
4.10. printer-multiple-document-jobs-supported .................23
4.11. printer-charset-configured ...............................23
4.12. printer-charset-supported ................................24
Fleming & McDonald Informational [Page 2]
RFC 7612 LDAP Schema for Printer Services June 2015
4.13. printer-generated-natural-language-supported .............24
4.14. printer-document-format-supported ........................25
4.15. printer-color-supported ..................................25
4.16. printer-compression-supported ............................26
4.17. printer-pages-per-minute .................................26
4.18. printer-pages-per-minute-color ...........................27
4.19. printer-finishings-supported .............................27
4.20. printer-number-up-supported ..............................28
4.21. printer-sides-supported ..................................28
4.22. printer-media-supported ..................................29
4.23. printer-media-local-supported ............................30
4.24. printer-resolution-supported .............................30
4.25. printer-print-quality-supported ..........................31
4.26. printer-job-priority-supported ...........................32
4.27. printer-copies-supported .................................32
4.28. printer-job-k-octets-supported ...........................33
4.29. printer-current-operator .................................33
4.30. printer-service-person ...................................34
4.31. printer-delivery-orientation-supported ...................34
4.32. printer-stacking-order-supported .........................35
4.33. printer-output-features-supported ........................36
4.34. printer-aliases ..........................................37
4.35. printer-device-id ........................................37
4.36. printer-device-service-count .............................38
4.37. printer-uuid .............................................38
4.38. printer-charge-info ......................................39
4.39. printer-charge-info-uri ..................................39
4.40. printer-geo-location .....................................40
4.41. printer-ipp-features-supported ...........................41
5. Definition of Syntaxes .........................................42
6. Definition of Matching Rules ...................................42
7. IANA Considerations ............................................42
7.1. Registration of Attribute Types ...........................43
7.2. Object Classes and Attribute Types from RFC 3712 ..........44
8. Internationalization Considerations ............................45
9. Security Considerations ........................................45
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................50
Appendix A. Changes since RFC 3712 ................................52
Acknowledgments ...................................................54
Authors' Addresses ................................................54
Fleming & McDonald Informational [Page 3]
RFC 7612 LDAP Schema for Printer Services June 2015
1. Introduction
This document defines several object classes to provide Lightweight
Directory Access Protocol (LDAP) [RFC4510] applications with flexible
options in defining Printer information using an LDAP schema.
Classes are provided for defining directory entries with common
Printer information as well as for extending existing directory
entries with Service Location Protocol Version 2 (SLPv2) [RFC2608],
Internet Printing Protocol/1.1 (IPP/1.1) [RFC2911], and lineprinter
(LPR) [RFC1179] protocol-specific information.
This memo is an Independent Submission to the RFC Editor by the
Internet Printing Protocol Working Group of the IEEE-ISTO Printer
Working Group, as part of their Printer Working Group (PWG) "IPP
Everywhere" (PWG 5100.14) project for secure mobile printing with
vendor-neutral Client software.
1.1. Relationship to SLP Printer Service
The schema defined in this document is technically aligned with the
stable IANA-registered 'service:printer:' v2.0 template [SLPPRT20],
for compatibility with already-deployed SLPv2 [RFC2608] service
advertising and discovery infrastructure. The attribute syntaxes are
technically aligned with the 'service:printer:' v2.0 template;
therefore, simpler types are sometimes used (for example,
'DirectoryString' [RFC4517] rather than 'labeledURI' [RFC2079] for
the 'printer-uri' attribute).
1.2. Source of LDAP Printer Attributes
The schema defined in this document is based on:
o all of the Printer attributes listed in Appendix E ("Generic
Directory Schema") of "Internet Printing Protocol/1.1: Model and
Semantics" [RFC2911] that are defined in Section 4.4 ("Printer
Description Attributes") of [RFC2911]
o selected Printer attributes defined in "Printer MIB v2" [RFC3805],
"PWG Command Set for IEEE 1284 Device ID v1.0" [PWG5107.2], "IPP
Job and Printer Extensions - Set 3 (JPS3)" [PWG5100.13], and "IPP
Everywhere" [PWG5100.14]
See the table of Printer attributes and source documents in Section 4
("Definition of Attribute Types") of this document.
Fleming & McDonald Informational [Page 4]
RFC 7612 LDAP Schema for Printer Services June 2015
1.3. Source of LDAP Printer Schema OIDs
1.3.1. IBM Assignments for RFC 3712
In March 2000, IBM permanently assigned ASN.1 OIDs to all of the
object classes and attribute types that were defined in the original
LDAP Printer Schema [RFC3712] (see Section 7.2).
1.3.2. IEEE-ISTO PWG Assignments
In October 2011, IBM permanently delegated the base ASN.1 OID
"1.3.18.0.2.24.46" to the IEEE-ISTO PWG for use in any PWG project.
In October 2011, the IEEE-ISTO PWG permanently assigned subordinate
ASN.1 OIDs for all of the new attribute types defined in this updated
LDAP Printer Schema (see Section 7.1).
1.4. Rationale for Design Choices
1.4.1. Rationale for Using DirectoryString Syntax
The attribute syntax 'DirectoryString' (UTF-8 [STD63]) defined in
[RFC4517] is specified for several groups of string attributes that
are defined in this document:
1) URI
- printer-uri, printer-xri-supported, printer-more-info,
printer-charge-info-uri, printer-uuid
The UTF-8 encoding is compatible with deployment of (UTF-8
based) Internationalized Resource Identifiers (IRIs) [RFC3987].
2) Description
- printer-name, printer-location, printer-info,
printer-make-and-model
The UTF-8 encoding supports descriptions in any language,
conformant with the IETF Policy on Character Sets and Languages
[BCP18].
Note: The printer-natural-language-configured attribute contains
a language tag [BCP47] for these description attributes (for
example, to support text-to-speech conversions).
Fleming & McDonald Informational [Page 5]
RFC 7612 LDAP Schema for Printer Services June 2015
3) Keyword
- printer-compression-supported, printer-finishings-supported,
printer-media-supported, printer-media-local-supported,
printer-print-quality-supported
The UTF-8 encoding is compatible with the current IPP/1.1
[RFC2911] definition of the equivalent attributes, most of which
have the IPP/1.1 union syntax "") is passed to HKDF-Expand-Label. The
labels specified in this document are all ASCII strings and do not
include a trailing NUL byte.
Note: With common hash functions, any label longer than 12 characters
requires an additional iteration of the hash function to compute.
The labels in this specification have all been chosen to fit within
this limit.
Rescorla Expires 27 September 2023 [Page 87]
Internet-Draft TLS March 2023
Keys are derived from two input secrets using the HKDF-Extract and
Derive-Secret functions. The general pattern for adding a new secret
is to use HKDF-Extract with the Salt being the current secret state
and the Input Keying Material (IKM) being the new secret to be added.
In this version of TLS 1.3, the two input secrets are:
* PSK (a pre-shared key established externally or derived from the
resumption_secret value from a previous connection)
* (EC)DHE shared secret (Section 7.4)
This produces a full key derivation schedule shown in the diagram
below. In this diagram, the following formatting conventions apply:
* HKDF-Extract is drawn as taking the Salt argument from the top and
the IKM argument from the left, with its output to the bottom and
the name of the output on the right.
* Derive-Secret's Secret argument is indicated by the incoming
arrow. For instance, the Early Secret is the Secret for
generating the client_early_traffic_secret.
* "0" indicates a string of Hash.length bytes set to zero.
Note: the key derivation labels use the string "master" even though
the values are referred to as "main" secrets. This mismatch is a
result of renaming the values while retaining compatibility.
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(.,
| "ext binder" |
| "res binder",
| "")
| = binder_key
|
+-----> Derive-Secret(., "c e traffic",
| ClientHello)
| = client_early_traffic_secret
|
+-----> Derive-Secret(., "e exp master",
| ClientHello)
| = early_exporter_secret
v
Derive-Secret(., "derived", "")
Rescorla Expires 27 September 2023 [Page 88]
Internet-Draft TLS March 2023
|
v
(EC)DHE -> HKDF-Extract = Handshake Secret
|
+-----> Derive-Secret(., "c hs traffic",
| ClientHello...ServerHello)
| = client_handshake_traffic_secret
|
+-----> Derive-Secret(., "s hs traffic",
| ClientHello...ServerHello)
| = server_handshake_traffic_secret
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Main Secret
|
+-----> Derive-Secret(., "c ap traffic",
| ClientHello...server Finished)
| = client_application_traffic_secret_0
|
+-----> Derive-Secret(., "s ap traffic",
| ClientHello...server Finished)
| = server_application_traffic_secret_0
|
+-----> Derive-Secret(., "exp master",
| ClientHello...server Finished)
| = exporter_secret
|
+-----> Derive-Secret(., "res master",
ClientHello...client Finished)
= resumption_secret
The general pattern here is that the secrets shown down the left side
of the diagram are just raw entropy without context, whereas the
secrets down the right side include Handshake Context and therefore
can be used to derive working keys without additional context. Note
that the different calls to Derive-Secret may take different Messages
arguments, even with the same secret. In a 0-RTT exchange, Derive-
Secret is called with four distinct transcripts; in a 1-RTT-only
exchange, it is called with three distinct transcripts.
If a given secret is not available, then the 0-value consisting of a
string of Hash.length bytes set to zeros is used. Note that this
does not mean skipping rounds, so if PSK is not in use, Early Secret
will still be HKDF-Extract(0, 0). For the computation of the
binder_key, the label is "ext binder" for external PSKs (those
provisioned outside of TLS) and "res binder" for resumption PSKs
Rescorla Expires 27 September 2023 [Page 89]
Internet-Draft TLS March 2023
(those provisioned as the resumption secret of a previous handshake).
The different labels prevent the substitution of one type of PSK for
the other.
There are multiple potential Early Secret values, depending on which
PSK the server ultimately selects. The client will need to compute
one for each potential PSK; if no PSK is selected, it will then need
to compute the Early Secret corresponding to the zero PSK.
Once all the values which are to be derived from a given secret have
been computed, that secret SHOULD be erased.
7.2. Updating Traffic Secrets
Once the handshake is complete, it is possible for either side to
update its sending traffic keys using the KeyUpdate handshake message
defined in Section 4.6.3. The next generation of traffic keys is
computed by generating client_/server_application_traffic_secret_N+1
from client_/server_application_traffic_secret_N as described in this
section and then re-deriving the traffic keys as described in
Section 7.3.
The next-generation application_traffic_secret is computed as:
application_traffic_secret_N+1 =
HKDF-Expand-Label(application_traffic_secret_N,
"traffic upd", "", Hash.length)
Once client_/server_application_traffic_secret_N+1 and its associated
traffic keys have been computed, implementations SHOULD delete
client_/server_application_traffic_secret_N and its associated
traffic keys.
7.3. Traffic Key Calculation
The traffic keying material is generated from the following input
values:
* A secret value
* A purpose value indicating the specific value being generated
* The length of the key being generated
The traffic keying material is generated from an input traffic secret
value using:
Rescorla Expires 27 September 2023 [Page 90]
#x27;keyword' or 'name'. The keyword
attributes defined in this document are extensible by site-
specific or vendor-specific 'names' that behave like new
'keywords'.
Note: In IPP/1.1, each value is strongly typed over-the-wire as
either 'keyword' or 'name'. This union selector is not
preserved in the definitions of these equivalent LDAP
attributes.
1.4.2. Rationale for Using caseIgnoreMatch
The EQUALITY matching rule 'caseIgnoreMatch' defined in [RFC4517] is
specified for several groups of string attributes that are defined in
this document:
1) URI
These URI attributes specify EQUALITY matching with
'caseIgnoreMatch' (rather than with 'caseExactMatch') in order to
conform to the spirit of [STD66], which requires case-insensitive
matching on the host part of a URI versus case-sensitive matching
on the remainder of a URI.
These URI attributes follow existing practice of supporting
case-insensitive equality matching for host names in the
associatedDomain attribute defined in [RFC4524].
Either equality matching rule choice would be a compromise:
a) case-sensitive whole URI matching can lead to false negative
matches and has been shown to be fragile (given deployed client
applications that 'pretty up' host names displayed and
transferred in URI);
b) case-insensitive whole URI matching can lead to false positive
matches, although it is a dangerous practice to publish URI
that differ only by case (for example, in the path elements).
Fleming & McDonald Informational [Page 6]
RFC 7612 LDAP Schema for Printer Services June 2015
2) Description
Case-insensitive equality matching is more user-friendly for
description attributes.
3) Keyword
Case-insensitive equality matching is more user-friendly for
keyword attributes.
4) IEEE 1284 Device ID
Case-insensitive equality matching is mandatory for IEEE 1284
Device ID attributes.
1.4.3. Rationale for Using caseIgnoreSubstringsMatch
The SUBSTR matching rule 'caseIgnoreSubstringsMatch' defined in
[RFC4517] is specified for several groups of string attributes that
are defined in this document:
1) URI
These URI attributes follow existing practice of supporting
case-insensitive equality matching for host names in the
associatedDomain attribute defined in [RFC4524].
2) Description
Support for case-insensitive substring matching is more
user-friendly for description attributes.
3) Keyword
Support for case-insensitive substring matching is more
user-friendly for keyword attributes.
4) IEEE 1284 Device ID
Support for case-insensitive substring matching is mandatory for
IEEE 1284 Device ID attributes.
Fleming & McDonald Informational [Page 7]
RFC 7612 LDAP Schema for Printer Services June 2015
2. Conventions Used in This Document
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.2. LDAP Schema Descriptions
Schema definitions are provided using LDAP [RFC4510] description
formats. Definitions provided here are formatted (line wrapped) for
readability.
2.3. Abbreviations
This document makes use of the following abbreviations (given with
their expanded forms and references for further reading):
IANA - Internet Assigned Numbers Authority
<http://www.iana.org>
IEEE - Institute of Electrical and Electronics Engineers
<http://www.ieee.org>
IPP - Internet Printing Protocol [RFC2911] [PWG5100.12]
<http://www.pwg.org/ipp/>
ISTO - IEEE Industry Standards and Technology Organization
<http://www.ieee-isto.org/>
PWG - IEEE-ISTO Printer Working Group
<http://www.pwg.org>
RFC - Request for Comments
<http://www.rfc-editor.org>
TLS - Transport Layer Security [RFC5246]
URI - Uniform Resource Identifier [STD66]
URL - Uniform Resource Locator [STD66]
UTF-8 - Unicode Transformation Format - 8-bit [STD63]
Fleming & McDonald Informational [Page 8]
RFC 7612 LDAP Schema for Printer Services June 2015
3. Definition of Object Classes
We define the following LDAP object classes for use with both generic
Printer-related information and services specific to SLPv2 [RFC2608],
IPP/1.1 [RFC2911], and LPR [RFC1179].
slpServicePrinter - auxiliary class for SLP-registered Printers
printerAbstract - abstract class for all Printer classes
printerService - structural class for Printers
printerServiceAuxClass - auxiliary class for Printers
printerIPP - auxiliary class for IPP Printers
printerLPR - auxiliary class for LPR Printers
The following are some examples of how applications could choose to
use these classes when creating directory entries:
1) Use printerService for directory entries containing common Printer
information.
2) Use both printerService and slpServicePrinter for directory
entries containing common Printer information for SLP-registered
Printers.
3) Use printerService, printerLPR, and printerIPP for directory
entries containing common Printer information for Printers that
support both LPR and IPP.
4) Use printerServiceAuxClass and object classes not defined by this
document for directory entries containing common Printer
information. In this example, printerServiceAuxClass is used for
extending other structural classes defining Printer information
with common Printer information defined in this document.
Refer to Section 4 for the definition of attribute types referenced
by these object classes. We use attribute names instead of OIDs in
object class definitions for clarity. Some attribute names described
in [RFC2911] have been prefixed with 'printer-' as recommended in
[RFC2926] and [SLPPRT20].
Fleming & McDonald Informational [Page 9]
RFC 7612 LDAP Schema for Printer Services June 2015
3.1. slpServicePrinter
( 1.3.18.0.2.6.254
NAME 'slpServicePrinter'
DESC 'Service Location Protocol (SLP) information.'
AUXILIARY
SUP slpService
)
This auxiliary class defines information specific to the Service
Location Protocol (SLPv2) [RFC2608]. It MAY be used to create new,
or extend existing, directory entries with SLP 'service:printer'
abstract service type information as defined in [SLPPRT20]. This
object class is derived from 'slpService', the parent class for all
SLP services, defined in [RFC2926].
3.2. printerAbstract
( 1.3.18.0.2.6.258
NAME 'printerAbstract'
DESC 'Printer-related information.'
ABSTRACT
SUP top
MAY ( printer-name $
printer-natural-language-configured $
printer-location $
printer-info $
printer-more-info $
printer-make-and-model $
printer-multiple-document-jobs-supported $
printer-charset-configured $
printer-charset-supported $
printer-generated-natural-language-supported $
printer-document-format-supported $
printer-color-supported $
printer-compression-supported $
printer-pages-per-minute $
printer-pages-per-minute-color $
printer-finishings-supported $
printer-number-up-supported $
printer-sides-supported $
printer-media-supported $
printer-media-local-supported $
printer-resolution-supported $
printer-print-quality-supported $
printer-job-priority-supported $
printer-copies-supported $
printer-job-k-octets-supported $
Fleming & McDonald Informational [Page 10]
RFC 7612 LDAP Schema for Printer Services June 2015
printer-current-operator $
printer-service-person $
printer-delivery-orientation-supported $
printer-stacking-order-supported $
printer-output-features-supported $
printer-device-id $
printer-device-service-count $
printer-uuid $
printer-charge-info $
printer-charge-info-uri $
printer-geo-location )
)
This abstract class defines Printer information. It is a base class
for deriving other Printer-related classes, such as, but not limited
to, classes defined in this document. It defines a common set of
Printer attributes that are not specific to any one type of service,
protocol, or operating system.
3.3. printerService
( 1.3.18.0.2.6.255
NAME 'printerService'
DESC 'Printer information.'
STRUCTURAL
SUP printerAbstract
MAY ( printer-uri $
printer-xri-supported )
)
This structural class defines Printer information. It is derived
from class printerAbstract and thus inherits common Printer
attributes. This class can be used with or without auxiliary classes
to define Printer information. Auxiliary classes can be used to
extend the common Printer information with information specific to
the protocol, service, or operating system.
Note: When extending other structural classes with auxiliary classes,
printerService SHOULD NOT be used.
Fleming & McDonald Informational [Page 11]
RFC 7612 LDAP Schema for Printer Services June 2015
3.4. printerServiceAuxClass
( 1.3.18.0.2.6.257
NAME 'printerServiceAuxClass'
DESC 'Printer information.'
AUXILIARY
SUP printerAbstract
MAY ( printer-uri $
printer-xri-supported )
)
This auxiliary class defines Printer information. It is derived from
class printerAbstract and thus inherits common Printer attributes.
3.5. printerIPP
( 1.3.18.0.2.6.256
NAME 'printerIPP'
DESC 'Internet Printing Protocol (IPP) information.'
AUXILIARY
SUP top
MAY ( printer-ipp-versions-supported $
printer-ipp-features-supported $
printer-multiple-document-jobs-supported )
)
This auxiliary class defines Internet Printing Protocol (IPP/1.1)
[RFC2911] information. It is used to extend structural classes with
IPP-specific Printer information.
Note: See "Internet Printing Protocol/1.1: IPP URL Scheme" [RFC3510]
and "Internet Printing Protocol (IPP) over HTTPS Transport Binding
and the 'ipps' URI Scheme" [RFC7472] for conforming URI for IPP
Printers.
3.6. printerLPR
( 1.3.18.0.2.6.253
NAME 'printerLPR'
DESC 'LPR information.'
AUXILIARY
SUP top
MUST ( printer-name )
MAY ( printer-aliases )
)
This auxiliary class defines LPR [RFC1179] information. It is used
to identify directory entries that support LPR.
Fleming & McDonald Informational [Page 12]
RFC 7612 LDAP Schema for Printer Services June 2015
4. Definition of Attribute Types
The following attribute types are referenced by the object classes
defined in Section 3.
The following attribute types reference syntax OIDs defined in
Section 3 of [RFC4517] (see Section 5 ("Definition of Syntaxes")
below).
The following attribute types reference matching rule names (instead
of OIDs) for clarity (see Section 6 below). For optional attributes,
if the Printer information is not known, the attribute value
SHOULD NOT be set. In the following definitions, referenced matching
rules are defined in Section 4 of [RFC4517] and discussed in
Section 6 ("Definition of Matching Rules") later in this document.
Note: For compatibility with existing implementations of [RFC3712]
and underlying string length limits in [RFC2707], [RFC2911],
[RFC3805], [PWG5107.2], [PWG5100.13], and [PWG5100.14],
implementations of the attributes defined in this document SHOULD NOT
exceed those underlying string length limits (to avoid truncation and
false matches).
Note: For interoperability and consistent text display, values of
attributes defined in this document (a) SHOULD be normalized as
recommended in "Unicode Format for Network Interchange" [RFC5198];
(b) SHOULD NOT contain DEL or any C0 or C1 control characters except
for HT, CR, and LF; (c) SHOULD only contain CR and LF characters
together (not as singletons); and (d) SHOULD NOT contain HT, CR, or
LF characters in names, e.g., printer-name and printer-aliases.
Note: Some of the following attributes are described as 'List of xxx'
(using a comma as the member delimiter). Some other attributes are
described as 'One of xxx' (single-valued). In all cases, any
attribute can have multiple values represented as multiple instances,
except where explicitly restricted in syntax to be single-valued.
Note: Values of the string attributes printer-xri-supported and
printer-resolution-supported use different field delimiters ('<' and
'>', respectively). These two field delimiters are different for
compatibility with the corresponding attributes in the IANA-
registered SLP 'service:printer:' v2.0 template [SLPPRT20], which was
defined before the original LDAP Printer Schema [RFC3712] was
written.
Fleming & McDonald Informational [Page 13]
Internet-Draft TLS March 2023
[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
[sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length)
[sender] denotes the sending side. The value of Secret for each
category of data is shown in the table below.
+====================+=======================================+
| Data Type | Secret |
+====================+=======================================+
| 0-RTT Application | client_early_traffic_secret |
| and EndOfEarlyData | |
+--------------------+---------------------------------------+
| Initial Handshake | [sender]_handshake_traffic_secret |
+--------------------+---------------------------------------+
| Post-Handshake and | [sender]_application_traffic_secret_N |
| Application Data | |
+--------------------+---------------------------------------+
Table 3: Secrets for Traffic Keys
Alerts are sent with the then current sending key (or as plaintext if
no such key has been established.) All the traffic keying material
is recomputed whenever the underlying Secret changes (e.g., when
changing from the handshake to Application Data keys or upon a key
update).
7.4. (EC)DHE Shared Secret Calculation
7.4.1. Finite Field Diffie-Hellman
For finite field groups, a conventional Diffie-Hellman [DH76]
computation is performed. The negotiated key (Z) is converted to a
byte string by encoding in big-endian form and left-padded with zeros
up to the size of the prime. This byte string is used as the shared
secret in the key schedule as specified above.
Note that this construction differs from previous versions of TLS
which remove leading zeros.
7.4.2. Elliptic Curve Diffie-Hellman
For secp256r1, secp384r1 and secp521r1, ECDH calculations (including
parameter and key generation as well as the shared secret
calculation) are performed according to [IEEE1363] using the ECKAS-
DH1 scheme with the identity map as the key derivation function
(KDF), so that the shared secret is the x-coordinate of the ECDH
shared secret elliptic curve point represented as an octet string.
Note that this octet string ("Z" in IEEE 1363 terminology) as output
Rescorla Expires 27 September 2023 [Page 91]
Internet-Draft TLS March 2023
by FE2OSP (the Field Element to Octet String Conversion Primitive)
has constant length for any given field; leading zeros found in this
octet string MUST NOT be truncated.
(Note that this use of the identity KDF is a technicality. The
complete picture is that ECDH is employed with a non-trivial KDF
because TLS does not directly use this secret for anything other than
for computing other secrets.)
For X25519 and X448, the ECDH calculations are as follows:
* The public key to put into the KeyShareEntry.key_exchange
structure is the result of applying the ECDH scalar multiplication
function to the secret key of appropriate length (into scalar
input) and the standard public basepoint (into u-coordinate point
input).
* The ECDH shared secret is the result of applying the ECDH scalar
multiplication function to the secret key (into scalar input) and
the peer's public key (into u-coordinate point input). The output
is used raw, with no processing.
For these curves, implementations SHOULD use the approach specified
in [RFC7748] to calculate the Diffie-Hellman shared secret.
Implementations MUST check whether the computed Diffie-Hellman shared
secret is the all-zero value and abort if so, as described in
Section 6 of [RFC7748]. If implementors use an alternative
implementation of these elliptic curves, they SHOULD perform the
additional checks specified in Section 7 of [RFC7748].
7.5. Exporters
[RFC5705] defines keying material exporters for TLS in terms of the
TLS pseudorandom function (PRF). This document replaces the PRF with
HKDF, thus requiring a new construction. The exporter interface
remains the same.
The exporter value is computed as:
TLS-Exporter(label, context_value, key_length) =
HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
"exporter", Hash(context_value), key_length)
Rescorla Expires 27 September 2023 [Page 92]
Internet-Draft TLS March 2023
Where Secret is either the early_exporter_secret or the
exporter_secret. Implementations MUST use the exporter_secret unless
explicitly specified by the application. The early_exporter_secret
is defined for use in settings where an exporter is needed for 0-RTT
data. A separate interface for the early exporter is RECOMMENDED;
this avoids the exporter user accidentally using an early exporter
when a regular one is desired or vice versa.
If no context is provided, the context_value is zero length.
Consequently, providing no context computes the same value as
providing an empty context. This is a change from previous versions
of TLS where an empty context produced a different output than an
absent context. As of this document's publication, no allocated
exporter label is used both with and without a context. Future
specifications MUST NOT define a use of exporters that permit both an
empty context and no context with the same label. New uses of
exporters SHOULD provide a context in all exporter computations,
though the value could be empty.
Requirements for the format of exporter labels are defined in
Section 4 of [RFC5705].
8. 0-RTT and Anti-Replay
As noted in Section 2.3 and Appendix F.5, TLS does not provide
inherent replay protections for 0-RTT data. There are two potential
threats to be concerned with:
* Network attackers who mount a replay attack by simply duplicating
a flight of 0-RTT data.
* Network attackers who take advantage of client retry behavior to
arrange for the server to receive multiple copies of an
application message. This threat already exists to some extent
because clients that value robustness respond to network errors by
attempting to retry requests. However, 0-RTT adds an additional
dimension for any server system which does not maintain globally
consistent server state. Specifically, if a server system has
multiple zones where tickets from zone A will not be accepted in
zone B, then an attacker can duplicate a ClientHello and early
data intended for A to both A and B. At A, the data will be
accepted in 0-RTT, but at B the server will reject 0-RTT data and
instead force a full handshake. If the attacker blocks the
ServerHello from A, then the client will complete the handshake
with B and probably retry the request, leading to duplication on
the server system as a whole.
Rescorla Expires 27 September 2023 [Page 93]
Internet-Draft TLS March 2023
The first class of attack can be prevented by sharing state to
guarantee that the 0-RTT data is accepted at most once. Servers
SHOULD provide that level of replay safety by implementing one of the
methods described in this section or by equivalent means. It is
understood, however, that due to operational concerns not all
deployments will maintain state at that level. Therefore, in normal
operation, clients will not know which, if any, of these mechanisms
servers actually implement and hence MUST only send early data which
they deem safe to be replayed.
In addition to the direct effects of replays, there is a class of
attacks where even operations normally considered idempotent could be
exploited by a large number of replays (timing attacks, resource
limit exhaustion and others, as described in Appendix F.5). Those
can be mitigated by ensuring that every 0-RTT payload can be replayed
only a limited number of times. The server MUST ensure that any
instance of it (be it a machine, a thread, or any other entity within
the relevant serving infrastructure) would accept 0-RTT for the same
0-RTT handshake at most once; this limits the number of replays to
the number of server instances in the deployment. Such a guarantee
can be accomplished by locally recording data from recently received
ClientHellos and rejecting repeats, or by any other method that
provides the same or a stronger guarantee. The "at most once per
server instance" guarantee is a minimum requirement; servers SHOULD
limit 0-RTT replays further when feasible.
The second class of attack cannot be prevented at the TLS layer and
MUST be dealt with by any application. Note that any application
whose clients implement any kind of retry behavior already needs to
implement some sort of anti-replay defense.
8.1. Single-Use Tickets
The simplest form of anti-replay defense is for the server to only
allow each session ticket to be used once. For instance, the server
can maintain a database of all outstanding valid tickets, deleting
each ticket from the database as it is used. If an unknown ticket is
provided, the server would then fall back to a full handshake.
If the tickets are not self-contained but rather are database keys,
and the corresponding PSKs are deleted upon use, then connections
established using PSKs enjoy not only anti-replay protection, but
also forward secrecy once all copies of the PSK from the database
entry have been deleted. This mechanism also improves security for
PSK usage when PSK is used without (EC)DHE.
Rescorla Expires 27 September 2023 [Page 94]
Internet-Draft TLS March 2023
Because this mechanism requires sharing the session database between
server nodes in environments with multiple distributed servers, it
may be hard to achieve high rates of successful PSK 0-RTT connections
when compared to self-encrypted tickets. Unlike session databases,
session tickets can successfully do PSK-based session establishment
even without consistent storage, though when 0-RTT is allowed they
still require consistent storage for anti-replay of 0-RTT data, as
detailed in the following section.
8.2. Client Hello Recording
An alternative form of anti-replay is to record a unique value
derived from the ClientHello (generally either the random value or
the PSK binder) and reject duplicates. Recording all ClientHellos
causes state to grow without bound, but a server can instead record
ClientHellos within a given time window and use the
"obfuscated_ticket_age" to ensure that tickets aren't reused outside
that window.
In order to implement this, when a ClientHello is received, the
server first verifies the PSK binder as described in Section 4.2.11.
It then computes the expected_arrival_time as described in the next
section and rejects 0-RTT if it is outside the recording window,
falling back to the 1-RTT handshake.
If the expected_arrival_time is in the window, then the server checks
to see if it has recorded a matching ClientHello. If one is found,
it either aborts the handshake with an "illegal_parameter" alert or
accepts the PSK but rejects 0-RTT. If no matching ClientHello is
found, then it accepts 0-RTT and then stores the ClientHello for as
long as the expected_arrival_time is inside the window. Servers MAY
also implement data stores with false positives, such as Bloom
filters, in which case they MUST respond to apparent replay by
rejecting 0-RTT but MUST NOT abort the handshake.
Rescorla Expires 27 September 2023 [Page 95]
Internet-Draft TLS March 2023
RFC 7612 LDAP Schema for Printer Services June 2015
The following table is a summary of the attribute names defined by
this document and their corresponding source document names as
defined in [RFC2911], [RFC3805], [PWG5107.2], or [PWG5100.13]. Some
source attribute names have been prefixed with 'printer-' as
recommended in [RFC2926], to address the flat namespace for LDAP
identifiers.
LDAP and SLP Printer Schema Source Document and Attribute Name
------------------------------ -------------------------------------
*** IPP/1.1 and Semantics Model [RFC2911]
printer-uri
printer-xri-supported
[printer-uri-supported]
[uri-authentication-supported]
[uri-security-supported]
printer-name printer-name
printer-natural-language-configured
natural-language-configured
printer-location printer-location
printer-info printer-info
printer-more-info printer-more-info
printer-make-and-model printer-make-and-model
printer-ipp-versions-supported ipp-versions-supported
printer-multiple-document-jobs-supported
multiple-document-jobs-supported
printer-charset-configured charset-configured
printer-charset-supported charset-supported
printer-generated-natural-language-supported
generated-natural-language-supported
printer-document-format-supported
document-format-supported
printer-color-supported color-supported
printer-compression-supported compression-supported
printer-pages-per-minute pages-per-minute
printer-pages-per-minute-color pages-per-minute-color
printer-finishings-supported finishings-supported
printer-number-up-supported number-up-supported
printer-sides-supported sides-supported
printer-media-supported media-supported
printer-media-local-supported [site names from IPP media-supported]
printer-resolution-supported printer-resolution-supported
printer-print-quality-supported print-quality-supported
printer-job-priority-supported job-priority-supported
printer-copies-supported copies-supported
printer-job-k-octets-supported job-k-octets-supported
Fleming & McDonald Informational [Page 14]
RFC 7612 LDAP Schema for Printer Services June 2015
*** Printer MIB v2 [RFC3805]
printer-current-operator prtGeneralCurrentOperator
printer-service-person prtGeneralServicePerson
printer-delivery-orientation-supported
prtOutputPageDeliveryOrientation
printer-stacking-order-supported
prtOutputStackingOrder
printer-output-features-supported
[prtOutputBursting]
[prtOutputDecollating]
[prtOutputPageCollated]
[prtOutputOffsetStacking]
printer-aliases prtGeneralPrinterName
*** Cmd Set 1284 Device ID [PWG5107.2]
printer-device-id printer-device-id
*** IPP Job/Printer Ext Set3 [PWG5100.13]
printer-device-service-count device-service-count
printer-uuid printer-uuid
printer-charge-info printer-charge-info
printer-charge-info-uri printer-charge-info-uri
printer-geo-location printer-geo-location
printer-ipp-features-supported ipp-features-supported
4.1. printer-uri
( 1.3.18.0.2.4.1140
NAME 'printer-uri'
DESC 'A URI supported by this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
If the printer-xri-supported LDAP attribute is implemented, then this
printer-uri value MUST be listed in printer-xri-supported.
See [STD66] for details of URI syntax.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 1023 octets in length.
Note: LDAP application clients SHOULD NOT attempt to use malformed
URI values read from this attribute. LDAP administrative clients
SHOULD NOT write malformed URI values into this attribute.
Fleming & McDonald Informational [Page 15]
RFC 7612 LDAP Schema for Printer Services June 2015
Note: See "Internet Printing Protocol/1.1: IPP URL Scheme" [RFC3510]
and "Internet Printing Protocol (IPP) over HTTPS Transport Binding
and the 'ipps' URI Scheme" [RFC7472] for conforming URI for IPP
Printers.
Note: For SLP-registered Printers, the LDAP printer-uri attribute
SHOULD be set to the value of the SLP-registered URL of the Printer,
for interworking with SLPv2 [RFC2608] service discovery.
Note: See Sections 1.4.1, 1.4.2, and 1.4.3 for rationale for design
choices.
4.2. printer-xri-supported
( 1.3.18.0.2.4.1107
NAME 'printer-xri-supported'
DESC 'An XRI (extended resource identifier) supported by
this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
Each value of this attribute MUST consist of a URI (uniform resource
identifier) followed by (optional) authentication and security
fields.
Each XRI field MUST be delimited by '<', with optional trailing
whitespace. For example:
'uri=ipp://example.com/ipp< auth=digest< sec=tls<'
'uri=ipps://example.com/ipp< auth=digest< sec=tls<'
'uri=lpr://example.com/lpr< auth=none< sec=none<'
'uri=mailto:printer@example.com< auth=none< sec=none<'
Note: See the note in Section 4 about the different field delimiters
used in the printer-xri-supported and printer-resolution-supported
attributes ('<' and '>', respectively), chosen for compatibility with
the IANA-registered SLP 'service:printer:' v2.0 template [SLPPRT20].
Note: Multiple values for this attribute are represented as multiple
instances of this attribute.
See [STD66] for details of URI syntax.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 1023 octets in length.
Fleming & McDonald Informational [Page 16]
RFC 7612 LDAP Schema for Printer Services June 2015
Note: LDAP application clients SHOULD NOT attempt to use malformed
URI values read from this attribute. LDAP administrative clients
SHOULD NOT write malformed URI values into this attribute.
Note: This attribute is based on the IPP/1.1 [RFC2911] attributes
'printer-uri-supported', 'uri-authentication-supported', and
'uri-security-supported' (called the 'Three Musketeers' because they
are parallel, ordered attributes). This attribute unfolds those
IPP/1.1 attributes and thus avoids the ordering (and same number of
values) constraints of the IPP/1.1 separate attributes.
Defined keywords for fields include:
'uri' (IPP 'printer-uri-supported')
'auth' (IPP 'uri-authentication-supported')
'sec' (IPP 'uri-security-supported')
A missing 'auth' field SHOULD be interpreted to mean 'none'. Per
IPP/1.1 [RFC2911], "IPP Job and Printer Extensions - Set 3 (JPS3)"
[PWG5100.13], and the IANA IPP registry [IANAIPP], defined values of
the 'auth' field include:
'none' (no authentication for this URI)
'requesting-user-name' (from operation request)
'basic' (HTTP/1.1 Basic [RFC2617] and [RFC7235])
'digest' (HTTP/1.1 Digest [RFC2617] and [RFC7235])
'certificate' (X.509 Certificate [RFC5280] and [RFC6818])
'negotiate' (HTTP/1.1 Negotiate [RFC4559])
The 'certificate' value refers to the IPP Client certificate
extracted from the TLS session.
A missing 'sec' field SHOULD be interpreted to mean 'none'. Per
IPP/1.1 [RFC2911] and the IANA IPP registry [IANAIPP], defined values
of the 'sec' field include:
'none' (no security for this URI)
'ssl3' (Netscape's Secure Socket Layer protocol (SSL3))
'tls' (IETF TLS, [RFC5246])
Note: The syntax and delimiter for this attribute are aligned with
the equivalent attribute in the 'service:printer:' v2.0 template
[SLPPRT20]. Whitespace is permitted after (but not before) the
delimiter '<'.
Fleming & McDonald Informational [Page 17]
RFC 7612 LDAP Schema for Printer Services June 2015
Note: See "Internet Printing Protocol/1.1: IPP URL Scheme" [RFC3510]
and "Internet Printing Protocol (IPP) over HTTPS Transport Binding
and the 'ipps' URI Scheme" [RFC7472] for conforming URI for IPP
Printers.
Note: See Sections 1.4.1, 1.4.2, and 1.4.3 for rationale for design
choices.
4.3. printer-name
( 1.3.18.0.2.4.1135
NAME 'printer-name'
DESC 'The site-specific administrative name of this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
Values of this attribute SHOULD be specified in the language
specified in printer-natural-language-configured (for example, to
support text-to-speech conversions), although the Printer's name MAY
be specified in any language.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 255 octets in length.
Note: This name can be the last part of the Printer's URI, or it can
be completely unrelated. This name can contain characters that are
not allowed in a conventional URI (see [STD66]).
Note: For interoperability, values of this attribute (a) SHOULD be
normalized as recommended in "Unicode Format for Network Interchange"
[RFC5198]; and (b) SHOULD NOT contain DEL or any C0 or C1 control
characters.
Fleming & McDonald Informational [Page 18]
RFC 7612 LDAP Schema for Printer Services June 2015
4.4. printer-natural-language-configured
( 1.3.18.0.2.4.1119
NAME 'printer-natural-language-configured'
DESC 'The configured natural language for LDAP attributes of
syntax DirectoryString (UTF-8) in this directory entry.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
Also, a possible natural language for IPP protocol string attributes
set by operator, system administrator, or manufacturer. Also, the
(declared) natural language of the printer-name, printer-location,
printer-info, and printer-make-and-model attributes of this Printer.
Values of language tags MUST conform to "Tags for Identifying
Languages" [BCP47]. For example:
'en-us' (English as spoken in the US)
'fr-fr' (French as spoken in France)
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 63 octets in length.
Note: For compatibility with IPP/1.1 [RFC2911], language tags in this
attribute SHOULD be lowercase normalized.
4.5. printer-location
( 1.3.18.0.2.4.1136
NAME 'printer-location'
DESC 'The physical location of this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
For example:
'Room 123A'
'Second floor of building XYZ'
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 127 octets in length.
Fleming & McDonald Informational [Page 19]
RFC 7612 LDAP Schema for Printer Services June 2015The server MUST derive the storage key only from validated sections
of the ClientHello. If the ClientHello contains multiple PSK
identities, then an attacker can create multiple ClientHellos with
different binder values for the less-preferred identity on the
assumption that the server will not verify it (as recommended by
Section 4.2.11). I.e., if the client sends PSKs A and B but the
server prefers A, then the attacker can change the binder for B
without affecting the binder for A. If the binder for B is part of
the storage key, then this ClientHello will not appear as a
duplicate, which will cause the ClientHello to be accepted, and may
cause side effects such as replay cache pollution, although any 0-RTT
data will not be decryptable because it will use different keys. If
the validated binder or the ClientHello.random is used as the storage
key, then this attack is not possible.
Because this mechanism does not require storing all outstanding
tickets, it may be easier to implement in distributed systems with
high rates of resumption and 0-RTT, at the cost of potentially weaker
anti-replay defense because of the difficulty of reliably storing and
retrieving the received ClientHello messages. In many such systems,
it is impractical to have globally consistent storage of all the
received ClientHellos. In this case, the best anti-replay protection
is provided by having a single storage zone be authoritative for a
given ticket and refusing 0-RTT for that ticket in any other zone.
This approach prevents simple replay by the attacker because only one
zone will accept 0-RTT data. A weaker design is to implement
separate storage for each zone but allow 0-RTT in any zone. This
approach limits the number of replays to once per zone. Application
message duplication of course remains possible with either design.
When implementations are freshly started, they SHOULD reject 0-RTT as
long as any portion of their recording window overlaps the startup
time. Otherwise, they run the risk of accepting replays which were
originally sent during that period.
Note: If the client's clock is running much faster than the server's,
then a ClientHello may be received that is outside the window in the
future, in which case it might be accepted for 1-RTT, causing a
client retry, and then acceptable later for 0-RTT. This is another
variant of the second form of attack described in Section 8.
Rescorla Expires 27 September 2023 [Page 96]
Internet-Draft TLS March 2023
8.3. Freshness Checks
Because the ClientHello indicates the time at which the client sent
it, it is possible to efficiently determine whether a ClientHello was
likely sent reasonably recently and only accept 0-RTT for such a
ClientHello, otherwise falling back to a 1-RTT handshake. This is
necessary for the ClientHello storage mechanism described in
Section 8.2 because otherwise the server needs to store an unlimited
number of ClientHellos, and is a useful optimization for self-
contained single-use tickets because it allows efficient rejection of
ClientHellos which cannot be used for 0-RTT.
In order to implement this mechanism, a server needs to store the
time that the server generated the session ticket, offset by an
estimate of the round-trip time between client and server. I.e.,
adjusted_creation_time = creation_time + estimated_RTT
This value can be encoded in the ticket, thus avoiding the need to
keep state for each outstanding ticket. The server can determine the
client's view of the age of the ticket by subtracting the ticket's
"ticket_age_add" value from the "obfuscated_ticket_age" parameter in
the client's "pre_shared_key" extension. The server can determine
the expected_arrival_time of the ClientHello as:
expected_arrival_time = adjusted_creation_time + clients_ticket_age
When a new ClientHello is received, the expected_arrival_time is then
compared against the current server wall clock time and if they
differ by more than a certain amount, 0-RTT is rejected, though the
1-RTT handshake can be allowed to complete.
There are several potential sources of error that might cause
mismatches between the expected_arrival_time and the measured time.
Variations in client and server clock rates are likely to be minimal,
though potentially the absolute times may be off by large values.
Network propagation delays are the most likely causes of a mismatch
in legitimate values for elapsed time. Both the NewSessionTicket and
ClientHello messages might be retransmitted and therefore delayed,
which might be hidden by TCP. For clients on the Internet, this
implies windows on the order of ten seconds to account for errors in
clocks and variations in measurements; other deployment scenarios may
have different needs. Clock skew distributions are not symmetric, so
the optimal tradeoff may involve an asymmetric range of permissible
mismatch values.
Rescorla Expires 27 September 2023 [Page 97]
Internet-Draft TLS March 2023
Note that freshness checking alone is not sufficient to prevent
replays because it does not detect them during the error window,
which -- depending on bandwidth and system capacity -- could include
billions of replays in real-world settings. In addition, this
freshness checking is only done at the time the ClientHello is
received, and not when subsequent early Application Data records are
received. After early data is accepted, records may continue to be
streamed to the server over a longer time period.
9. Compliance Requirements
9.1. Mandatory-to-Implement Cipher Suites
In the absence of an application profile standard specifying
otherwise:
A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256
[GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384
[GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see
Appendix B.4).
A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A
TLS-compliant application MUST support key exchange with secp256r1
(NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
9.2. Mandatory-to-Implement Extensions
In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the following
TLS extensions:
* Supported Versions ("supported_versions"; Section 4.2.1)
* Cookie ("cookie"; Section 4.2.2)
* Signature Algorithms ("signature_algorithms"; Section 4.2.3)
* Signature Algorithms Certificate ("signature_algorithms_cert";
Section 4.2.3)
* Negotiated Groups ("supported_groups"; Section 4.2.7)
* Key Share ("key_share"; Section 4.2.8)
* Server Name Indication ("server_name"; Section 3 of [RFC6066])
Rescorla Expires 27 September 2023 [Page 98]
Internet-Draft TLS March 2023
All implementations MUST send and use these extensions when offering
applicable features:
* "supported_versions" is REQUIRED for all ClientHello, ServerHello,
and HelloRetryRequest messages.
* "signature_algorithms" is REQUIRED for certificate authentication.
* "supported_groups" is REQUIRED for ClientHello messages using DHE
or ECDHE key exchange.
* "key_share" is REQUIRED for DHE or ECDHE key exchange.
* "pre_shared_key" is REQUIRED for PSK key agreement.
* "psk_key_exchange_modes" is REQUIRED for PSK key agreement.
A client is considered to be attempting to negotiate using this
specification if the ClientHello contains a "supported_versions"
extension with 0x0304 contained in its body. Such a ClientHello
message MUST meet the following requirements:
* If not containing a "pre_shared_key" extension, it MUST contain
both a "signature_algorithms" extension and a "supported_groups"
extension.
* If containing a "supported_groups" extension, it MUST also contain
a "key_share" extension, and vice versa. An empty
KeyShare.client_shares list is permitted.
Servers receiving a ClientHello which does not conform to these
requirements MUST abort the handshake with a "missing_extension"
alert.
Additionally, all implementations MUST support the use of the
"server_name" extension with applications capable of using it.
Servers MAY require clients to send a valid "server_name" extension.
Servers requiring this extension SHOULD respond to a ClientHello
lacking a "server_name" extension by terminating the connection with
a "missing_extension" alert.
9.3. Protocol Invariants
This section describes invariants that TLS endpoints and middleboxes
MUST follow. It also applies to earlier versions of TLS.
Rescorla Expires 27 September 2023 [Page 99]
Internet-Draft TLS March 2023
TLS is designed to be securely and compatibly extensible. Newer
clients or servers, when communicating with newer peers, should
negotiate the most preferred common parameters. The TLS handshake
provides downgrade protection: Middleboxes passing traffic between a
newer client and newer server without terminating TLS should be
unable to influence the handshake (see Appendix F.1). At the same
time, deployments update at different rates, so a newer client or
server MAY continue to support older parameters, which would allow it
to interoperate with older endpoints.
For this to work, implementations MUST correctly handle extensible
fields:
* A client sending a ClientHello MUST support all parameters
advertised in it. Otherwise, the server may fail to interoperate
by selecting one of those parameters.
* A server receiving a ClientHello MUST correctly ignore all
unrecognized cipher suites, extensions, and other parameters.
Otherwise, it may fail to interoperate with newer clients. In TLS
1.3, a client receiving a CertificateRequest or NewSessionTicket
MUST also ignore all unrecognized extensions.
* A middlebox which terminates a TLS connection MUST behave as a
compliant TLS server (to the original client), including having a
certificate which the client is willing to accept, and also as a
compliant TLS client (to the original server), including verifying
the original server's certificate. In particular, it MUST
generate its own ClientHello containing only parameters it
understands, and it MUST generate a fresh ServerHello random
value, rather than forwarding the endpoint's value.
Note that TLS's protocol requirements and security analysis only
apply to the two connections separately. Safely deploying a TLS
terminator requires additional security considerations which are
beyond the scope of this document.
* A middlebox which forwards ClientHello parameters it does not
understand MUST NOT process any messages beyond that ClientHello.
It MUST forward all subsequent traffic unmodified. Otherwise, it
may fail to interoperate with newer clients and servers.
Rescorla Expires 27 September 2023 [Page 100]
Internet-Draft TLS March 2023
Forwarded ClientHellos may contain advertisements for features not
supported by the middlebox, so the response may include future TLS
additions the middlebox does not recognize. These additions MAY
change any message beyond the ClientHello arbitrarily. In
particular, the values sent in the ServerHello might change, the
ServerHello format might change, and the TLSCiphertext format
might change.
The design of TLS 1.3 was constrained by widely deployed non-
compliant TLS middleboxes (see Appendix E.4); however, it does not
relax the invariants. Those middleboxes continue to be non-
compliant.
10. Security Considerations
Security issues are discussed throughout this memo, especially in
Appendix C, Appendix E, and Appendix F.
11. IANA Considerations
This document uses several registries that were originally created in
[RFC4346] and updated in [RFC8446] and [RFC8447]. The changes
between [RFC8446] and [RFC8447] this document are described in
Section 11.1. IANA has updated these to reference this document.
The registries and their allocation policies are below:
* TLS Cipher Suites registry: values with the first byte in the
range 0-254 (decimal) are assigned via Specification Required
[RFC8126]. Values with the first byte 255 (decimal) are reserved
for Private Use [RFC8126].
IANA has added the cipher suites listed in Appendix B.4 to the
registry. The "Value" and "Description" columns are taken from
the table. The "DTLS-OK" and "Recommended" columns are both
marked as "Y" for each new cipher suite.
* TLS ContentType registry: Future values are allocated via
Standards Action [RFC8126].
* TLS Alerts registry: Future values are allocated via Standards
Action [RFC8126]. IANA [is requested to/has] populated this
registry with the values from Appendix B.2. The "DTLS-OK" column
is marked as "Y" for all such values. Values marked as
"_RESERVED" have comments describing their previous usage.
Rescorla Expires 27 September 2023 [Page 101]
Internet-Draft TLS March 2023
* TLS HandshakeType registry: Future values are allocated via
Standards Action [RFC8126]. IANA has updated this registry to
rename item 4 from "NewSessionTicket" to "new_session_ticket" and
populated this registry with the values from Appendix B.3. The
"DTLS-OK" column is marked as "Y" for all such values. Values
marked "_RESERVED" have comments describing their previous or
temporary usage.
This document also uses the TLS ExtensionType Values registry
originally created in [RFC4366]. IANA has updated it to reference
this document. Changes to the registry follow:
* IANA has updated the registration policy as follows:
Values with the first byte in the range 0-254 (decimal) are
assigned via Specification Required [RFC8126]. Values with the
first byte 255 (decimal) are reserved for Private Use [RFC8126].
* IANA has updated this registry to include the "key_share",
"pre_shared_key", "psk_key_exchange_modes", "early_data",
"cookie", "supported_versions", "certificate_authorities",
"oid_filters", "post_handshake_auth", and
"signature_algorithms_cert" extensions with the values defined in
this document and the "Recommended" value of "Y".
* IANA has updated this registry to include a "TLS 1.3" column which
lists the messages in which the extension may appear. This column
has been initially populated from the table in Section 4.2, with
any extension not listed there marked as "-" to indicate that it
is not used by TLS 1.3.
This document updates an entry in the TLS Certificate Types registry
originally created in [RFC6091] and updated in [RFC8447]. IANA has
updated the entry for value 1 to have the name "OpenPGP_RESERVED",
"Recommended" value "N", and comment "Used in TLS versions prior to
1.3." IANA has updated the entry for value 0 to have the name
"X509", "Recommended" value "Y", and comment "Was X.509 before TLS
1.3".
This document updates an entry in the TLS Certificate Status Types
registry originally created in [RFC6961]. IANA has updated the entry
for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used
in TLS versions prior to 1.3".
Rescorla Expires 27 September 2023 [Page 102]
Internet-Draft TLS March 2023
This document updates two entries in the TLS Supported Groups
registry (created under a different name by [RFC4492]; now maintained
by [RFC8422]) and updated by [RFC7919] and [RFC8447]. The entries
for values 29 and 30 (x25519 and x448) have been updated to also
refer to this document.
In addition, this document defines two new registries that are
maintained by IANA:
* TLS SignatureScheme registry: Values with the first byte in the
range 0-253 (decimal) are assigned via Specification Required
[RFC8126]. Values with the first byte 254 or 255 (decimal) are
reserved for Private Use [RFC8126]. Values with the first byte in
the range 0-6 or with the second byte in the range 0-3 that are
not currently allocated are reserved for backward compatibility.
This registry has a "Recommended" column. The registry has been
initially populated with the values described in Section 4.2.3.
The following values are marked as "Recommended":
ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512,
rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and
ed25519. The "Recommended" column is assigned a value of "N"
unless explicitly requested, and adding a value with a
"Recommended" value of "Y" requires Standards Action [RFC8126].
IESG Approval is REQUIRED for a Y->N transition.
* TLS PskKeyExchangeMode registry: Values in the range 0-253
(decimal) are assigned via Specification Required [RFC8126]. The
values 254 and 255 (decimal) are reserved for Private Use
[RFC8126]. This registry has a "Recommended" column. The
registry has been initially populated with psk_ke (0) and
psk_dhe_ke (1). Both are marked as "Recommended". The
"Recommended" column is assigned a value of "N" unless explicitly
requested, and adding a value with a "Recommended" value of "Y"
requires Standards Action [RFC8126]. IESG Approval is REQUIRED
for a Y->N transition.
11.1. Changes for this RFC
IANA [shall update/has updated] the TLS registries to reference this
document.
IANA [shall rename/has renamed] the "extended_master_secret" value in
the TLS ExtensionType Values registry to "extended_main_secret".
IANA [shall create/has created] a value for the "general_error" alert
in the TLS Alerts Registry with the value given in Section 6.
Rescorla Expires 27 September 2023 [Page 103]
Internet-Draft TLS March 2023
12. References
12.1. Normative References
[DH76] Diffie, W., Hellman, M., and Institute of Electrical and
Electronics Engineers (IEEE), "New directions in
cryptography", IEEE Transactions on Information Theory,
vol. 22, no. 6, pp. 644-654, DOI 10.1109/tit.1976.1055638,
November 1976,
<http://dx.doi.org/10.1109/tit.1976.1055638>.
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC",
NIST Special Publication 800-38D, November 2007.
[IEEE1363] IEEE, "IEEE Standard Specifications for Public-Key
Cryptography", DOI 10.1109/ieeestd.2000.92292, 23
September 2008,
<http://dx.doi.org/10.1109/ieeestd.2000.92292>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Updates for RSAES-OAEP and RSASSA-PSS Algorithm
Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010,
<https://www.rfc-editor.org/info/rfc5756>.
Rescorla Expires 27 September 2023 [Page 104]
Internet-Draft TLS March 2023
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655,
DOI 10.17487/RFC6655, July 2012,
<https://www.rfc-editor.org/info/rfc6655>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<https://www.rfc-editor.org/info/rfc6961>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
<https://www.rfc-editor.org/info/rfc7507>.
Rescorla Expires 27 September 2023 [Page 105]
Internet-Draft TLS March 2023
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman
Ephemeral Parameters for Transport Layer Security (TLS)",
RFC 7919, DOI 10.17487/RFC7919, August 2016,
<https://www.rfc-editor.org/info/rfc7919>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
[SHS] Dang, Q. H. and National Institute of Standards and
Technology, "Secure Hash Standard",
DOI 10.6028/nist.fips.180-4, July 2015,
<http://dx.doi.org/10.6028/nist.fips.180-4>.
Rescorla Expires 27 September 2023 [Page 106]
Internet-Draft TLS March 2023
[X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8824-1:2021 , February 2021.
12.2. Informative References
[AEAD-LIMITS]
Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", August 2017,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[BBFGKZ16] Bhargavan, K., Brzuska, C., Fournet, C., Green, M.,
Kohlweiss, M., Zanella-Beguelin, S., and IEEE, "Downgrade
Resilience in Key-Exchange Protocols", 2016 IEEE Symposium
on Security and Privacy (SP), DOI 10.1109/sp.2016.37, May
2016, <http://dx.doi.org/10.1109/sp.2016.37>.
[BBK17] Bhargavan, K., Blanchet, B., Kobeissi, N., and IEEE,
"Verified Models and Reference Implementations for the TLS
1.3 Standard Candidate", 2017 IEEE Symposium on Security
and Privacy (SP), DOI 10.1109/sp.2017.26, May 2017,
<http://dx.doi.org/10.1109/sp.2017.26>.
[BDFKPPRSZZ16]
Bhargavan, K., Delignat-Lavaud, A., Fournet, C.,
Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy,
N., Zanella-Beguelin, S., and J. Zinzindohoue,
"Implementing and Proving the TLS 1.3 Record Layer",
Proceedings of IEEE Symposium on Security and Privacy (San
Jose) 2017 , December 2016,
<https://eprint.iacr.org/2016/1178>.
[Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF
100", 2017,
<https://datatracker.ietf.org/meeting/100/materials/
slides-100-tls-sessa-tls13/>.
[Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome",
2017, <https://www.ietf.org/mail-archive/web/tls/current/
msg25168.html>.
[Blei98] Bleichenbacher, D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1",
Proceedings of CRYPTO '98 , 1998.
Rescorla Expires 27 September 2023 [Page 107]
Internet-Draft TLS March 2023
[BMMRT15] Badertscher, C., Matt, C., Maurer, U., Rogaway, P., and B.
Tackmann, "Augmented Secure Channels and the Goal of the
TLS 1.3 Record Layer", ProvSec 2015 , September 2015,
<https://eprint.iacr.org/2015/394>.
[BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of
Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings
of CRYPTO 2016 , July 2016,
<https://eprint.iacr.org/2016/564>.
[CCG16] Cohn-Gordon, K., Cremers, C., Garratt, L., and IEEE, "On
Post-compromise Security", 2016 IEEE 29th Computer
Security Foundations Symposium (CSF),
DOI 10.1109/csf.2016.19, June 2016,
<http://dx.doi.org/10.1109/csf.2016.19>.
[CHECKOWAY]
Checkoway, S., Maskiewicz, J., Garman, C., Fried, J.,
Cohney, S., Green, M., Heninger, N., Weinmann, R.,
Rescorla, E., Shacham, H., and ACM, "A Systematic Analysis
of the Juniper Dual EC Incident", Proceedings of the 2016
ACM SIGSAC Conference on Computer and Communications
Security, DOI 10.1145/2976749.2978395, 24 October 2016,
<http://dx.doi.org/10.1145/2976749.2978395>.
[CHHSV17] Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T.,
and S. Scott, "Awkward Handshake: Possible mismatch of
client/server view on client authentication in post-
handshake mode in Revision 18", message to the TLS mailing
list , February 2017, <https://www.ietf.org/mail-
archive/web/tls/current/msg22382.html>.
[CHSV16] Cremers, C., Horvat, M., Scott, S., Merwe, T. V. D., and
IEEE, "Automated Analysis and Verification of TLS 1.3:
0-RTT, Resumption and Delayed Authentication", 2016 IEEE
Symposium on Security and Privacy (SP),
DOI 10.1109/sp.2016.35, May 2016,
<http://dx.doi.org/10.1109/sp.2016.35>.
[CK01] Canetti, R., Krawczyk, H., and Springer Berlin Heidelberg,
"Analysis of Key-Exchange Protocols and Their Use for
Building Secure Channels", Lecture Notes in Computer
Science, pp. 453-474, DOI 10.1007/3-540-44987-6_28, 2001,
<http://dx.doi.org/10.1007/3-540-44987-6_28>.
[CLINIC] Miller, B., Huang, L., Joseph, A. D., Tygar, J. D., and
Springer International Publishing, "I Know Why You Went to
the Clinic: Risks and Realization of HTTPS Traffic
Rescorla Expires 27 September 2023 [Page 108]
Internet-Draft TLS March 2023
Analysis", Privacy Enhancing Technologies, pp. 143-163,
DOI 10.1007/978-3-319-08506-7_8, 2014,
<http://dx.doi.org/10.1007/978-3-319-08506-7_8>.
[DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
"A Cryptographic Analysis of the TLS 1.3 draft-10 Full and
Pre-shared Key Handshake Protocol", Proceedings of ACM CCS
2015 , October 2016, <https://eprint.iacr.org/2015/914>.
[DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
"A Cryptographic Analysis of the TLS 1.3 draft-10 Full and
Pre-shared Key Handshake Protocol", TRON 2016 , February
2016, <https://eprint.iacr.org/2016/081>.
[DOW92] Diffie, W., Oorschot, P. C. V., Wiener, M. J., and
Springer Science and Business Media LLC, "Authentication
and authenticated key exchanges", Designs, Codes and
Cryptography, vol. 2, no. 2, pp. 107-125,
DOI 10.1007/bf00124891, June 1992,
<http://dx.doi.org/10.1007/bf00124891>.
[DSA-1571-1]
The Debian Project, "openssl -- predictable random number
generator", May 2008,
<https://www.debian.org/security/2008/dsa-1571>.
[DSS] Moody, D. and National Institute of Standards and
Technology, "Digital Signature Standard (DSS)",
DOI 10.6028/nist.fips.186-5, 2023,
<http://dx.doi.org/10.6028/nist.fips.186-5>.
[ECDP] Moody, D. and National Institute of Standards and
Technology, "Recommendations for Discrete Logarithm-based
Cryptography:", DOI 10.6028/nist.sp.800-186, 2022,
<http://dx.doi.org/10.6028/nist.sp.800-186>.
[FETCH] WHATWG, "Fetch Standard", March 2023,
<https://fetch.spec.whatwg.org/>.
[FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero
Round-Trip Time: The Case of the TLS 1.3 Handshake
Candidates", Proceedings of Euro S&P 2017 , 2017,
<https://eprint.iacr.org/2017/082>.
Rescorla Expires 27 September 2023 [Page 109]
Internet-Draft TLS March 2023
[FGSW16] Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi,
"Key Confirmation in Key Exchange: A Formal Treatment and
Implications for TLS 1.3", Proceedings of IEEE Symposium
on Security and Privacy (Oakland) 2016 , 2016,
<http://ieeexplore.ieee.org/document/7546517/>.
[FW15] Weimer, F., "Factoring RSA Keys With TLS Perfect Forward
Secrecy", September 2015.
[HCJC16] Husák, M., Čermák, M., Jirsík, T., Čeleda, P., and
Springer Science and Business Media LLC, "HTTPS traffic
analysis and client identification using passive SSL/TLS
fingerprinting", EURASIP Journal on Information Security,
vol. 2016, no. 1, DOI 10.1186/s13635-016-0030-7, 26
February 2016,
<http://dx.doi.org/10.1186/s13635-016-0030-7>.
[HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes,
"Prying Open Pandora's Box: KCI Attacks against TLS",
Proceedings of USENIX Workshop on Offensive Technologies ,
2015.
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-15, 3 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-15>.
[I-D.ietf-uta-rfc6125bis]
Saint-Andre, P. and R. Salz, "Service Identity in TLS",
Work in Progress, Internet-Draft, draft-ietf-uta-
rfc6125bis-12, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-uta-
rfc6125bis-12>.
[JSS15] Jager, T., Schwenk, J., Somorovsky, J., and ACM, "On the
Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC
Conference on Computer and Communications Security,
DOI 10.1145/2810103.2813657, 12 October 2015,
<http://dx.doi.org/10.1145/2810103.2813657>.
Rescorla Expires 27 September 2023 [Page 110]
Internet-Draft TLS March 2023
[KEYAGREEMENT]
Barker, E., Chen, L., Roginsky, A., Smid, M., and National
Institute of Standards and Technology, "Recommendation for
Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography", DOI 10.6028/nist.sp.800-56ar2,
May 2013, <http://dx.doi.org/10.6028/nist.sp.800-56ar2>.
[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 ,
2010, <https://eprint.iacr.org/2010/264>.
[Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication
Compiler for Key Exchange (with Applications to Client
Authentication in TLS 1.3", Proceedings of ACM CCS 2016 ,
October 2016, <https://eprint.iacr.org/2016/711>.
[KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3",
Proceedings of Euro S&P 2016 , 2016,
<https://eprint.iacr.org/2015/978>.
[LXZFH16] Li, X., Xu, J., Zhang, Z., Feng, D., Hu, H., and IEEE,
"Multiple Handshakes Security of TLS 1.3 Candidates", 2016
IEEE Symposium on Security and Privacy (SP),
DOI 10.1109/sp.2016.36, May 2016,
<http://dx.doi.org/10.1109/sp.2016.36>.
[Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", March
2017, <https://github.com/tlswg/tls13-spec/issues/1001>.
[PS18] Patton, C. and T. Shrimpton, "Partially specified
channels: The TLS 1.3 record layer without elision", 2018,
<https://eprint.iacr.org/2018/634>.
[PSK-FINISHED]
Cremers, C., Horvat, M., van der Merwe, T., and S. Scott,
"Revision 10: possible attack if client authentication is
allowed during PSK", message to the TLS mailing list, ,
2015, <https://www.ietf.org/mail-archive/web/tls/current/
msg18215.html>.
[REKEY] Abdalla, M., Bellare, M., and Springer Berlin Heidelberg,
"Increasing the Lifetime of a Key: A Comparative Analysis
of the Security of Re-keying Techniques", Advances in
Cryptology — ASIACRYPT 2000, pp. 546-559,
DOI 10.1007/3-540-44448-3_42, 2000,
<http://dx.doi.org/10.1007/3-540-44448-3_42>.
Rescorla Expires 27 September 2023 [Page 111]
Internet-Draft TLS March 2023
[Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3
Middlebox experiment", message to the TLS mailing list ,
2017, <https://www.ietf.org/mail-archive/web/tls/current/
msg25091.html>.
[Res17b] Rescorla, E., "More compatibility measurement results",
message to the TLS mailing list , December 2017,
<https://www.ietf.org/mail-archive/web/tls/current/
msg25179.html>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999,
<https://www.rfc-editor.org/info/rfc2246>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006,
<https://www.rfc-editor.org/info/rfc4346>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<https://www.rfc-editor.org/info/rfc4366>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006,
<https://www.rfc-editor.org/info/rfc4492>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>.
Rescorla Expires 27 September 2023 [Page 112]
Internet-Draft TLS March 2023
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/info/rfc5764>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/info/rfc5929>.
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
for Transport Layer Security (TLS) Authentication",
RFC 6091, DOI 10.17487/RFC6091, February 2011,
<https://www.rfc-editor.org/info/rfc6091>.
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
DOI 10.17487/RFC6101, August 2011,
<https://www.rfc-editor.org/info/rfc6101>.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March
2011, <https://www.rfc-editor.org/info/rfc6176>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension", RFC 6520,
DOI 10.17487/RFC6520, February 2012,
<https://www.rfc-editor.org/info/rfc6520>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
Rescorla Expires 27 September 2023 [Page 113]
Internet-Draft TLS March 2023
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
DOI 10.17487/RFC7465, February 2015,
<https://www.rfc-editor.org/info/rfc7465>.
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
DOI 10.17487/RFC7568, June 2015,
<https://www.rfc-editor.org/info/rfc7568>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello
Padding Extension", RFC 7685, DOI 10.17487/RFC7685,
October 2015, <https://www.rfc-editor.org/info/rfc7685>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Rescorla Expires 27 September 2023 [Page 114]
Internet-Draft TLS March 2023
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>.
[RFC8448] Thomson, M., "Example Handshake Traces for TLS 1.3",
RFC 8448, DOI 10.17487/RFC8448, January 2019,
<https://www.rfc-editor.org/info/rfc8448>.
[RFC8449] Thomson, M., "Record Size Limit Extension for TLS",
RFC 8449, DOI 10.17487/RFC8449, August 2018,
<https://www.rfc-editor.org/info/rfc8449>.
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/info/rfc8773>.
[RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", RFC 8879, DOI 10.17487/RFC8879, December
2020, <https://www.rfc-editor.org/info/rfc8879>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/info/rfc8937>.
[RSA] Rivest, R. L., Shamir, A., Adleman, L., and Association
for Computing Machinery (ACM), "A method for obtaining
digital signatures and public-key cryptosystems",
Communications of the ACM, vol. 21, no. 2, pp. 120-126,
DOI 10.1145/359340.359342, February 1978,
<http://dx.doi.org/10.1145/359340.359342>.
[SIGMA] Krawczyk, H. and Springer Berlin Heidelberg, "SIGMA: The
‘SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman
and Its Use in the IKE Protocols", Advances in Cryptology
- CRYPTO 2003, pp. 400-425,
DOI 10.1007/978-3-540-45146-4_24, 2003,
<http://dx.doi.org/10.1007/978-3-540-45146-4_24>.
[SLOTH] Bhargavan, K., Leurent, G., and Internet Society,
"Transcript Collision Attacks: Breaking Authentication in
TLS, IKE, and SSH", Proceedings 2016 Network and
Distributed System Security Symposium,
DOI 10.14722/ndss.2016.23418, 2016,
<http://dx.doi.org/10.14722/ndss.2016.23418>.
[SSL2] Hickman, K., "The SSL Protocol&
Note: For interoperability and consistent text display, values of
this attribute (a) SHOULD be normalized as recommended in "Unicode
Format for Network Interchange" [RFC5198]; (b) SHOULD NOT contain DEL
or any C0 or C1 control characters except for HT, CR, and LF; and
(c) SHOULD only contain CR and LF characters together (not as
singletons).
4.6. printer-info
( 1.3.18.0.2.4.1139
NAME 'printer-info'
DESC 'Descriptive information about this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
For example:
'This Printer can be used for printing color transparencies for
HR presentations'
'Out of courtesy for others, please print only small (1-5 page)
jobs at this Printer'
'This Printer is going away on July 1, 1997; please find a new
Printer'
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 127 octets in length.
Note: For interoperability and consistent text display, values of
this attribute (a) SHOULD be normalized as recommended in "Unicode
Format for Network Interchange" [RFC5198]; (b) SHOULD NOT contain DEL
or any C0 or C1 control characters except for HT, CR, and LF; and
(c) SHOULD only contain CR and LF characters together (not as
singletons).
Fleming & McDonald Informational [Page 20]
RFC 7612 LDAP Schema for Printer Services June 2015
4.7. printer-more-info
( 1.3.18.0.2.4.1134
NAME 'printer-more-info'
DESC 'A URI for more information about this specific Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
For example, this could be an HTTP URI referencing an HTML page
accessible to a Web Browser. The information obtained from this URI
is intended for end user consumption.
See [STD66] for details of URI syntax.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 1023 octets in length.
Note: LDAP application clients SHOULD NOT attempt to use malformed
URI values read from this attribute. LDAP administrative clients
SHOULD NOT write malformed URI values into this attribute.
Note: See Sections 1.4.1, 1.4.2, and 1.4.3 for rationale for design
choices.
4.8. printer-make-and-model
( 1.3.18.0.2.4.1138
NAME 'printer-make-and-model'
DESC 'Make and model of this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 127 octets in length.
Note: The Printer manufacturer MAY initially populate this attribute.
Fleming & McDonald Informational [Page 21]
RFC 7612 LDAP Schema for Printer Services June 2015
Note: For interoperability and consistent text display, values of
this attribute (a) SHOULD be normalized as recommended in "Unicode
Format for Network Interchange" [RFC5198]; (b) SHOULD NOT contain DEL
or any C0 or C1 control characters except for HT, CR, and LF; and
(c) SHOULD only contain CR and LF characters together (not as
singletons).
4.9. printer-ipp-versions-supported
( 1.3.18.0.2.4.1133
NAME 'printer-ipp-versions-supported'
DESC 'Comma-delimited list of IPP versions supported by
this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
For example:
'1.1,2.0'
Note: Length overflow in values of this attribute MUST be handled by
multiple instances of this attribute, i.e., individual
comma-delimited list members MUST NOT be truncated.
The IPP protocol version(s) MUST include major and minor versions,
i.e., the exact version numbers for which this Printer implementation
meets the IPP version-specific conformance requirements as registered
in the IANA IPP registry [IANAIPP].
IANA-registered versions of IPP currently are:
'1.0' (IPP/1.0 [RFC2566], OBSOLETE)
'1.1' (IPP/1.1 [RFC2911])
'2.0' (IPP/2.0 [PWG5100.12])
'2.1' (IPP/2.1 [PWG5100.12])
'2.2' (IPP/2.2 [PWG5100.12])
Fleming & McDonald Informational [Page 22]
RFC 7612 LDAP Schema for Printer Services June 2015
4.10. printer-multiple-document-jobs-supported
( 1.3.18.0.2.4.1132
NAME 'printer-multiple-document-jobs-supported'
DESC 'Indicates whether or not this Printer supports more than one
document per job.'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
)
4.11. printer-charset-configured
( 1.3.18.0.2.4.1109
NAME 'printer-charset-configured'
DESC 'The configured charset for IPP protocol values of error
and status messages generated by this Printer.'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
Also, a possible charset for IPP protocol string attributes set by
operator, system administrator, or manufacturer. For example:
'utf-8' (ISO 10646/Unicode in UTF-8 transform [STD63])
'iso-8859-1' (ISO Latin1)
Values of charset tags SHOULD be defined in the IANA registry of
Character Sets [IANACHAR] (see also [BCP19]), and the '(preferred
MIME name)' SHOULD be used as the charset tag in this attribute.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 63 octets in length.
Note: For compatibility with IPP/1.1 [RFC2911], charset tags in this
attribute SHOULD be lowercase normalized.
Fleming & McDonald Informational [Page 23]
RFC 7612 LDAP Schema for Printer Services June 2015
4.12. printer-charset-supported
( 1.3.18.0.2.4.1131
NAME 'printer-charset-supported'
DESC 'One of the charsets supported for IPP protocol values of
IPP string attributes that correspond to attributes of
syntax DirectoryString (UTF-8) for this directory entry.'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
For example:
'utf-8' (ISO 10646/Unicode in UTF-8 transform [STD63])
'iso-8859-1' (ISO Latin1)
Note: Multiple values for this attribute are represented as multiple
instances of this attribute.
Values of charset tags SHOULD be defined in the IANA registry of
Character Sets [IANACHAR] (see also [BCP19]), and the '(preferred
MIME name)' SHOULD be used as the charset tag in this attribute.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 63 octets in length.
Note: For compatibility with IPP/1.1 [RFC2911], charset tags in this
attribute SHOULD be lowercase normalized.
4.13. printer-generated-natural-language-supported
( 1.3.18.0.2.4.1137
NAME 'printer-generated-natural-language-supported'
DESC 'One of the natural languages supported for LDAP attributes of
syntax DirectoryString (UTF-8) in this directory entry.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
Values of language tags SHOULD conform to "Tags for Identifying
Languages" [BCP47]. For example:
'en-us' (English as spoken in the US)
'fr-ca' (French as spoken in Canada)
Note: Multiple values for this attribute are represented as multiple
instances of this attribute.
Fleming & McDonald Informational [Page 24]
RFC 7612 LDAP Schema for Printer Services June 2015
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 63 octets in length.
Note: For compatibility with IPP/1.1 [RFC2911], language tags in this
attribute SHOULD be lowercase normalized.
4.14. printer-document-format-supported
( 1.3.18.0.2.4.1130
NAME 'printer-document-format-supported'
DESC 'One of the source document formats that can be interpreted
and printed by this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
Values of document formats SHOULD be MIME media types defined in the
IANA registry of MIME Media Types [IANAMIME] (see also [BCP13]).
For example:
'application/postscript' (Adobe PostScript)
'text/plain' (plain text)
Note: Multiple values for this attribute are represented as multiple
instances of this attribute.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 255 octets in length.
4.15. printer-color-supported
( 1.3.18.0.2.4.1129
NAME ", 9 February 1995.
Rescorla Expires 27 September 2023 [Page 115]
Internet-Draft TLS March 2023
[TIMING] Boneh, D. and D. Brumley, "Remote Timing Attacks Are
Practical", USENIX Security Symposium, 2003.
[X501] ITU-T, "Information Technology - Open Systems
Interconnection - The Directory: Models", ISO/IEC
9594-2:2020 , October 2019.
Appendix A. State Machine
This appendix provides a summary of the legal state transitions for
the client and server handshakes. State names (in all capitals,
e.g., START) have no formal meaning but are provided for ease of
comprehension. Actions which are taken only in certain circumstances
are indicated in []. The notation "K_{send,recv} = foo" means "set
the send/recv key to the given key".
A.1. Client
START <----+
Send ClientHello | | Recv HelloRetryRequest
[K_send = early data] | |
v |
/ WAIT_SH ----+
| | Recv ServerHello
| | K_recv = handshake
Can | V
send | WAIT_EE
early | | Recv EncryptedExtensions
data | +--------+--------+
| Using | | Using certificate
| PSK | v
| | WAIT_CERT_CR
| | Recv | | Recv CertificateRequest
| | Certificate | v
| | | WAIT_CERT
| | | | Recv Certificate
| | v v
| | WAIT_CV
| | | Recv CertificateVerify
| +> WAIT_FINISHED <+
| | Recv Finished
\ | [Send EndOfEarlyData]
| K_send = handshake
| [Send Certificate [+ CertificateVerify]]
Can send | Send Finished
app data --> | K_send = K_recv = application
after here v
CONNECTED
Rescorla Expires 27 September 2023 [Page 116]
Internet-Draft TLS March 2023
Note that with the transitions as shown above, clients may send
alerts that derive from post-ServerHello messages in the clear or
with the early data keys. If clients need to send such alerts, they
SHOULD first rekey to the handshake keys if possible.
A.2. Server
START <-----+
Recv ClientHello | | Send HelloRetryRequest
v |
RECVD_CH ----+
| Select parameters
v
NEGOTIATED
| Send ServerHello
| K_send = handshake
| Send EncryptedExtensions
| [Send CertificateRequest]
Can send | [Send Certificate + CertificateVerify]
app data | Send Finished
after --> | K_send = application
here +--------+--------+
No 0-RTT | | 0-RTT
| |
K_recv = handshake | | K_recv = early data
[Skip decrypt errors] | +------> WAIT_EOED -+
| | Recv | | Recv EndOfEarlyData
| | early data | | K_recv = handshake
| +------------+ |
| |
+> WAIT_FLIGHT2 <--------+
|
+--------+--------+
No auth | | Cert-based client auth
| |
| v
| WAIT_CERT
| Recv | | Recv Certificate
| empty | v
| Certificate | WAIT_CV
| | | Recv
| v | CertificateVerify
+-> WAIT_FINISHED <---+
| Recv Finished
| K_recv = application
v
CONNECTED
Rescorla Expires 27 September 2023 [Page 117]
Internet-Draft TLS March 2023
Appendix B. Protocol Data Structures and Constant Values
This appendix provides the normative protocol types and the
definitions for constants. Values listed as "_RESERVED" were used in
previous versions of TLS and are listed here for completeness. TLS
1.3 implementations MUST NOT send them but might receive them from
older TLS implementations.
B.1. Record Layer
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
(255)
} ContentType;
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
opaque content[TLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} TLSInnerPlaintext;
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
B.2. Alert Messages
Rescorla Expires 27 September 2023 [Page 118]
Internet-Draft TLS March 2023
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure_RESERVED(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
no_renegotiation_RESERVED(100),
missing_extension(109),
unsupported_extension(110),
certificate_unobtainable_RESERVED(111),
unrecognized_name(112),
bad_certificate_status_response(113),
bad_certificate_hash_value_RESERVED(114),
unknown_psk_identity(115),
certificate_required(116),
general_error(117),
no_application_protocol(120),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
B.3. Handshake Protocol
Rescorla Expires 27 September 2023 [Page 119]
Internet-Draft TLS March 2023
enum {
hello_request_RESERVED(0),
client_hello(1),
server_hello(2),
hello_verify_request_RESERVED(3),
new_session_ticket(4),
end_of_early_data(5),
hello_retry_request_RESERVED(6),
encrypted_extensions(8),
certificate(11),
server_key_exchange_RESERVED(12),
certificate_request(13),
server_hello_done_RESERVED(14),
certificate_verify(15),
client_key_exchange_RESERVED(16),
finished(20),
certificate_url_RESERVED(21),
certificate_status_RESERVED(22),
supplemental_data_RESERVED(23),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* remaining bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
};
} Handshake;
B.3.1. Key Exchange Messages
Rescorla Expires 27 September 2023 [Page 120]
Internet-Draft TLS March 2023
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>;
} ServerHello;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
Rescorla Expires 27 September 2023 [Page 121]
Internet-Draft TLS March 2023
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
struct {
uint8 legacy_form = 4;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
struct {
PskKeyExchangeMode ke_modes<1..255>;
} PskKeyExchangeModes;
struct {} Empty;
struct {
select (Handshake.msg_type) {
case new_session_ticket: uint32 max_early_data_size;
case client_hello: Empty;
case encrypted_extensions: Empty;
};
} EarlyDataIndication;
struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age;
Rescorla Expires 27 September 2023 [Page 122]
Internet-Draft TLS March 2023
} PskIdentity;
opaque PskBinderEntry<32..255>;
struct {
PskIdentity identities<7..2^16-1>;
PskBinderEntry binders<33..2^16-1>;
} OfferedPsks;
struct {
select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
};
} PreSharedKeyExtension;
B.3.1.1. Version Extension
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
B.3.1.2. Cookie Extension
struct {
opaque cookie<1..2^16-1>;
} Cookie;
B.3.1.3. Signature Algorithm Extension
Rescorla Expires 27 September 2023 [Page 123]
Internet-Draft TLS March 2023
enum {
/* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601),
/* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),
/* RSASSA-PSS algorithms with public key OID rsaEncryption */
rsa_pss_rsae_sha256(0x0804),
rsa_pss_rsae_sha384(0x0805),
rsa_pss_rsae_sha512(0x0806),
/* EdDSA algorithms */
ed25519(0x0807),
ed448(0x0808),
/* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x080a),
rsa_pss_pss_sha512(0x080b),
/* Legacy algorithms */
rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203),
/* Reserved Code Points */
obsolete_RESERVED(0x0000..0x0200),
dsa_sha1_RESERVED(0x0202),
obsolete_RESERVED(0x0204..0x0400),
dsa_sha256_RESERVED(0x0402),
obsolete_RESERVED(0x0404..0x0500),
dsa_sha384_RESERVED(0x0502),
obsolete_RESERVED(0x0504..0x0600),
dsa_sha512_RESERVED(0x0602),
obsolete_RESERVED(0x0604..0x06FF),
private_use(0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;
Rescorla Expires 27 September 2023 [Page 124]
Internet-Draft TLS March 2023
B.3.1.4. Supported Groups Extension
enum {
unallocated_RESERVED(0x0000),
/* Elliptic Curve Groups (ECDHE) */
obsolete_RESERVED(0x0001..0x0016),
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
obsolete_RESERVED(0x001A..0x001C),
x25519(0x001D), x448(0x001E),
/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
obsolete_RESERVED(0xFF01..0xFF02),
(0xFFFF)
} NamedGroup;
struct {
NamedGroup named_group_list<2..2^16-1>;
} NamedGroupList;
Values within "obsolete_RESERVED" ranges are used in previous
versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
implementations. The obsolete curves have various known/theoretical
weaknesses or have had very little usage, in some cases only due to
unintentional server configuration issues. They are no longer
considered appropriate for general use and should be assumed to be
potentially unsafe. The set of curves specified here is sufficient
for interoperability with all currently deployed and properly
configured TLS implementations.
B.3.2. Server Parameters Messages
Rescorla Expires 27 September 2023 [Page 125]
Internet-Draft TLS March 2023
opaque DistinguishedName<1..2^16-1>;
struct {
DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension;
struct {
opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>;
} OIDFilter;
struct {
OIDFilter filters<0..2^16-1>;
} OIDFilterExtension;
struct {} PostHandshakeAuth;
struct {
Extension extensions<0..2^16-1>;
} EncryptedExtensions;
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<0..2^16-1>;
} CertificateRequest;
B.3.3. Authentication Messages
Rescorla Expires 27 September 2023 [Page 126]
Internet-Draft TLS March 2023
enum {
X509(0),
OpenPGP_RESERVED(1),
RawPublicKey(2),
(255)
} CertificateType;
struct {
select (certificate_type) {
case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
opaque certificate_request_context#x27;printer-color-supported'
DESC 'Indicates whether or not this Printer is capable of any type of
color printing at all, including highlight color.'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
)
Fleming & McDonald Informational [Page 25]
RFC 7612 LDAP Schema for Printer Services June 2015
4.16. printer-compression-supported
( 1.3.18.0.2.4.1128
NAME 'printer-compression-supported'
DESC 'Comma-delimited list of compression algorithms supported by
this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
For example:
'none'
'deflate,gzip'
Note: Length overflow in values of this attribute MUST be handled by
multiple instances of this attribute, i.e., individual
comma-delimited list members MUST NOT be truncated.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 255 octets in length.
Values defined in IPP/1.1 [RFC2911] and recorded in the IANA IPP
registry [IANAIPP] include:
'none' (no compression is used)
'deflate' (public domain ZIP described in [RFC1951])
'gzip' (GNU ZIP described in [RFC1952])
'compress' (UNIX compression described in [RFC1977])
4.17. printer-pages-per-minute
( 1.3.18.0.2.4.1127
NAME 'printer-pages-per-minute'
DESC 'The nominal number of pages per minute that can be output by
this Printer.'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
This attribute is informative, not a service guarantee. Typically,
it is the value used in marketing literature to describe this Printer
-- for example, the value for a simplex or black-and-white print
mode.
Fleming & McDonald Informational [Page 26]
RFC 7612 LDAP Schema for Printer Services June 2015
4.18. printer-pages-per-minute-color
( 1.3.18.0.2.4.1126
NAME 'printer-pages-per-minute-color'
DESC 'The nominal number of color pages per minute that can be
output by this Printer.'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
This attribute is informative, not a service guarantee. Typically,
it is the value used in marketing literature to describe this
Printer.
4.19. printer-finishings-supported
( 1.3.18.0.2.4.1125
NAME 'printer-finishings-supported'
DESC 'Comma-delimited list of finishing operations supported by
this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
For example:
'staple'
'staple,punch,bind'
Note: Length overflow in values of this attribute MUST be handled by
multiple instances of this attribute, i.e., individual
comma-delimited list members MUST NOT be truncated.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 255 octets in length.
Values defined in IPP/1.1 [RFC2911] and recorded in the IANA IPP
registry [IANAIPP] include:
'none', 'staple', 'punch', 'cover', 'bind', 'saddle-stitch',
'edge-stitch', 'staple-top-left', 'staple-bottom-left',
'staple-top-right', 'staple-bottom-right', 'edge-stitch-left',
'edge-stitch-top', 'edge-stitch-right', 'edge-stitch-bottom',
'staple-dual-left', 'staple-dual-top', 'staple-dual-right',
'staple-dual-bottom'.
Fleming & McDonald Informational [Page 27]
RFC 7612 LDAP Schema for Printer Services June 2015
Note: Implementations MAY support other values.
4.20. printer-number-up-supported
( 1.3.18.0.2.4.1124
NAME 'printer-number-up-supported'
DESC 'Maximum number of print-stream pages that can be imposed upon
a single side of an instance of a selected medium by this
Printer.'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
For example:
'1'
'4'
Note: Values of this attribute differ from the corresponding IPP
attribute, in that only the maximum number-up is mapped from the
corresponding IPP attribute 'number-up-supported' defined in
[RFC2911].
4.21. printer-sides-supported
( 1.3.18.0.2.4.1123
NAME 'printer-sides-supported'
DESC 'Comma-delimited list of impression sides (one or two) and the
two-sided impression rotations supported by this Printer.'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
For example:
'one-sided'
'one-sided,two-sided-short-edge'
Note: Length overflow in values of this attribute MUST be handled by
multiple instances of this attribute, i.e., individual
comma-delimited list members MUST NOT be truncated.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 255 octets in length.
Fleming & McDonald Informational [Page 28]
RFC 7612 LDAP Schema for Printer Services June 2015
Values defined in IPP/1.1 [RFC2911] and recorded in the IANA IPP
registry [IANAIPP] are:
'one-sided'
'two-sided-long-edge'
'two-sided-short-edge'
4.22. printer-media-supported
( 1.3.18.0.2.4.1122
NAME 'printer-media-supported'
DESC 'One of the names/sizes/types/colors of the media supported by
this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
Values SHOULD conform to "PWG Media Standardized Names 2.0 (MSN2)"
[PWG5101.1].
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 255 octets in length.
Values of standardized media size names defined in [PWG5101.1] and
recorded in the IANA IPP registry [IANAIPP] include:
'na_letter_8.5x11in'
'iso_a4_210x297mm'
Values of standardized media types defined in [PWG5101.1] and
recorded in the IANA IPP registry [IANAIPP] include:
'envelope'
'stationery'
Values of standardized media colors defined in [PWG5101.1] and
recorded in the IANA IPP registry [IANAIPP] include:
'white'
'blue'
Note: Multiple values for this attribute are represented as multiple
instances of this attribute.
Fleming & McDonald Informational [Page 29]
RFC 7612 LDAP Schema for Printer Services June 2015
4.23. printer-media-local-supported
( 1.3.18.0.2.4.1117
NAME 'printer-media-local-supported'
DESC 'One of the site-specific media supported by this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
Values SHOULD conform to "PWG Media Standardized Names 2.0 (MSN2)"
[PWG5101.1].
For example:
'custom_purchasing-form_8.5x11in' (site-specific name)
Note: Multiple values for this attribute are represented as multiple
instances of this attribute.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 255 octets in length.
4.24. printer-resolution-supported
( 1.3.18.0.2.4.1121
NAME 'printer-resolution-supported'
DESC 'One of the resolutions supported for printing documents by
this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
Each resolution value MUST be a string containing three fields:
1) Cross-feed direction resolution (positive integer);
2) Feed direction resolution (positive integer);
3) Unit -- 'dpi' (dots per inch) or 'dpcm' (dots per centimeter).
Each resolution field MUST be delimited by '>', with optional
trailing whitespace. For example:
'300> 300> dpi>'
'600> 600> dpi>'
Fleming & McDonald Informational [Page 30]
RFC 7612 LDAP Schema for Printer Services June 2015
Note: See the note in Section 4 about the different field delimiters
used in the printer-xri-supported and printer-resolution-supported
attributes ('<' and '>', respectively), chosen for compatibility with
the IANA-registered SLP 'service:printer:' v2.0 template [SLPPRT20].
Note: Multiple values for this attribute are represented as multiple
instances of this attribute.
Note: This attribute is based on 'printer-resolution-supported'
defined in IPP/1.1 [RFC2911] with a complex encoding derived from
'prtMarkerAddressabilityFeedDir', 'prtMarkerAddressabilityXFeedDir',
and 'prtMarkerAddressabilityUnit' defined in "Printer MIB v2"
[RFC3805] (which have integer encodings).
Note: The syntax and delimiter for this attribute are aligned with
the equivalent attribute in the 'service:printer:' v2.0 template
[SLPPRT20]. Whitespace is permitted after (but not before) the
delimiter '>'.
4.25. printer-print-quality-supported
( 1.3.18.0.2.4.1120
NAME 'printer-print-quality-supported'
DESC 'Comma-delimited list of print qualities supported
for printing documents on this Printer.'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
For example:
'unknown'
'draft,normal,high'
Note: Length overflow in values of this attribute MUST be handled by
multiple instances of this attribute, i.e., individual
comma-delimited list members MUST NOT be truncated.
Values defined in IPP/1.1 [RFC2911] and recorded in the IANA IPP
registry [IANAIPP] include:
'draft'
'normal'
'high'
Note: The value 'unknown' MUST only be reported if the corresponding
IPP attribute is not present, i.e., the value 'unknown' is an
artifact of this LDAP mapping.
Fleming & McDonald Informational [Page 31]
RFC 7612 LDAP Schema for Printer Services June 2015
4.26. printer-job-priority-supported
( 1.3.18.0.2.4.1110
NAME 'printer-job-priority-supported'
DESC 'Indicates the number of job priority levels supported by
this Printer.'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
An IPP/1.1 [RFC2911] conformant Printer, which supports job priority,
always supports a full range of priorities from '1' to '100' (to
ensure consistent behavior); therefore, this attribute describes the
'granularity' of priority supported. Values of this attribute are
from '1' to '100'.
4.27. printer-copies-supported
( 1.3.18.0.2.4.1118
NAME 'printer-copies-supported'
DESC 'The maximum number of copies of a document that can be printed
as a single job on this Printer.'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
A positive value indicates the maximum supported copies. A value of
'0' indicates no maximum limit. A value of '-1' indicates 'unknown'.
Note: The syntax and values for this attribute are aligned with the
equivalent attribute in the 'service:printer:' v2.0 template
[SLPPRT20].
Fleming & McDonald Informational [Page 32]
RFC 7612 LDAP Schema for Printer Services June 2015
4.28. printer-job-k-octets-supported
( 1.3.18.0.2.4.1111
NAME 'printer-job-k-octets-supported'
DESC 'The maximum size of an incoming print job that this Printer
will accept, in kilobytes (1,024 octets).'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
A positive value indicates the maximum supported job size. A value
of '0' indicates no maximum limit. A value of '-1' indicates
'unknown'.
Note: The syntax and values for this attribute are aligned with the
equivalent attribute in the 'service:printer:' v2.0 template
[SLPPRT20].
4.29. printer-current-operator
( 1.3.18.0.2.4.1112
NAME 'printer-current-operator'
DESC 'The identity of the current human operator responsible for
operating this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
The value of this attribute SHOULD include information that would
enable other humans to reach the operator, such as a telephone
number.
Note: For interoperability and consistent text display, values of
this attribute (a) SHOULD be normalized as recommended in "Unicode
Format for Network Interchange" [RFC5198]; (b) SHOULD NOT contain DEL
or any C0 or C1 control characters except for HT, CR, and LF; and
(c) SHOULD only contain CR and LF characters together (not as
singletons).
Fleming & McDonald Informational [Page 33]
RFC 7612 LDAP Schema for Printer Services June 2015
4.30. printer-service-person
( 1.3.18.0.2.4.1113
NAME 'printer-service-person'
DESC 'The identity of the current human service person responsible
for servicing this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
The value of this attribute SHOULD include information that would
enable other humans to reach the service person, such as a telephone
number.
Note: For interoperability and consistent text display, values of
this attribute (a) SHOULD be normalized as recommended in "Unicode
Format for Network Interchange" [RFC5198]; (b) SHOULD NOT contain DEL
or any C0 or C1 control characters except for HT, CR, and LF; and
(c) SHOULD only contain CR and LF characters together (not as
singletons).
4.31. printer-delivery-orientation-supported
( 1.3.18.0.2.4.1114
NAME 'printer-delivery-orientation-supported'
DESC 'Comma-delimited list of delivery orientations of pages as they
are printed and ejected supported by this Printer.'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
For example:
'unknown'
'face-up,face-down'
Values defined in "Printer MIB v2" [RFC3805] for
prtOutputPageDeliveryOrientation are:
'face-up'
'face-down'
Note: The value 'unknown' MUST only be reported if the corresponding
Printer MIB attribute is not present, i.e., the value 'unknown' is an
artifact of this LDAP mapping.
Fleming & McDonald Informational [Page 34]
<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
struct {
opaque verify_data[Hash.length];
} Finished;
B.3.4. Ticket Establishment
struct {
uint32 ticket_lifetime;
uint32 ticket_age_add;
opaque ticket_nonce<0..255>;
opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-1>;
} NewSessionTicket;
B.3.5. Updating Keys
Rescorla Expires 27 September 2023 [Page 127]
Internet-Draft TLS March 2023
struct {} EndOfEarlyData;
enum {
update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
B.4. Cipher Suites
A cipher suite defines the pair of the AEAD algorithm and hash
algorithm to be used with HKDF. Cipher suite names follow the naming
convention:
CipherSuite TLS_AEAD_HASH = VALUE;
+===========+================================================+
| Component | Contents |
+===========+================================================+
| TLS | The string "TLS" |
+-----------+------------------------------------------------+
| AEAD | The AEAD algorithm used for record protection |
+-----------+------------------------------------------------+
| HASH | The hash algorithm used with HKDF |
+-----------+------------------------------------------------+
| VALUE | The two byte ID assigned for this cipher suite |
+-----------+------------------------------------------------+
Table 4: Cipher Suite Name Structure
This specification defines the following cipher suites for use with
TLS 1.3.
Rescorla Expires 27 September 2023 [Page 128]
Internet-Draft TLS March 2023
+==============================+=============+
| Description | Value |
+==============================+=============+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
+------------------------------+-------------+
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
+------------------------------+-------------+
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
+------------------------------+-------------+
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
+------------------------------+-------------+
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+
Table 5: Cipher Suite List
The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM,
and AEAD_AES_128_CCM are defined in [RFC5116].
AEAD_CHACHA20_POLY1305 is defined in [RFC8439]. AEAD_AES_128_CCM_8
is defined in [RFC6655]. The corresponding hash algorithms are
defined in [SHS].
Although TLS 1.3 uses the same cipher suite space as previous
versions of TLS, TLS 1.3 cipher suites are defined differently, only
specifying the symmetric ciphers, and cannot be used for TLS 1.2.
Similarly, cipher suites for TLS 1.2 and lower cannot be used with
TLS 1.3.
New cipher suite values are assigned by IANA as described in
Section 11.
Appendix C. Implementation Notes
The TLS protocol cannot prevent many common security mistakes. This
appendix provides several recommendations to assist implementors.
[RFC8448] provides test vectors for TLS 1.3 handshakes.
C.1. Random Number Generation and Seeding
TLS requires a cryptographically secure pseudorandom number generator
(CSPRNG). In most cases, the operating system provides an
appropriate facility such as /dev/urandom, which should be used
absent other (e.g., performance) concerns. It is RECOMMENDED to use
an existing CSPRNG implementation in preference to crafting a new
one. Many adequate cryptographic libraries are already available
under favorable license terms. Should those prove unsatisfactory,
[RFC4086] provides guidance on the generation of random values.
Rescorla Expires 27 September 2023 [Page 129]
Internet-Draft TLS March 2023
TLS uses random values (1) in public protocol fields such as the
public Random values in the ClientHello and ServerHello and (2) to
generate keying material. With a properly functioning CSPRNG, this
does not present a security problem, as it is not feasible to
determine the CSPRNG state from its output. However, with a broken
CSPRNG, it may be possible for an attacker to use the public output
to determine the CSPRNG internal state and thereby predict the keying
material, as documented in [CHECKOWAY] and [DSA-1571-1].
Implementations can provide extra security against this form of
attack by using separate CSPRNGs to generate public and private
values.
[RFC8937] describes a way way for security protocol implementations
to augment their (pseudo)random number generators using a long-term
private key and a deterministic signature function. This improves
randomness from broken or otherwise subverted random number
generators.
C.2. Certificates and Authentication
Implementations are responsible for verifying the integrity of
certificates and should generally support certificate revocation
messages. Absent a specific indication from an application profile,
certificates should always be verified to ensure proper signing by a
trusted certificate authority (CA). The selection and addition of
trust anchors should be done very carefully. Users should be able to
view information about the certificate and trust anchor.
Applications SHOULD also enforce minimum and maximum key sizes. For
example, certification paths containing keys or signatures weaker
than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure
applications.
Note that it is common practice in some protocols to use the same
certificate in both client and server modes. This setting has not
been extensively analyzed and it is the responsibility of the higher
level protocol to ensure there is no ambiguity in this case about the
higher-level semantics.
C.3. Implementation Pitfalls
Implementation experience has shown that certain parts of earlier TLS
specifications are not easy to understand and have been a source of
interoperability and security problems. Many of these areas have
been clarified in this document but this appendix contains a short
list of the most important things that require special attention from
implementors.
Rescorla Expires 27 September 2023 [Page 130]
Internet-Draft TLS March 2023
TLS protocol issues:
* Do you correctly handle handshake messages that are fragmented to
multiple TLS records (see Section 5.1)? Do you correctly handle
corner cases like a ClientHello that is split into several small
fragments? Do you fragment handshake messages that exceed the
maximum fragment size? In particular, the Certificate and
CertificateRequest handshake messages can be large enough to
require fragmentation. Certificate compression as defined in
[RFC8879] can be used to reduce the risk of fragmentation.
* Do you ignore the TLS record layer version number in all
unencrypted TLS records (see Appendix E)?
* Have you ensured that all support for SSL, RC4, EXPORT ciphers,
and MD5 (via the "signature_algorithms" extension) is completely
removed from all possible configurations that support TLS 1.3 or
later, and that attempts to use these obsolete capabilities fail
correctly? (see Appendix E)?
* Do you handle TLS extensions in ClientHellos correctly, including
unknown extensions?
* When the server has requested a client certificate but no suitable
certificate is available, do you correctly send an empty
Certificate message, instead of omitting the whole message (see
Section 4.4.2)?
* When processing the plaintext fragment produced by AEAD-Decrypt
and scanning from the end for the ContentType, do you avoid
scanning past the start of the cleartext in the event that the
peer has sent a malformed plaintext of all zeros?
* Do you properly ignore unrecognized cipher suites (Section 4.1.2),
hello extensions (Section 4.2), named groups (Section 4.2.7), key
shares (Section 4.2.8), supported versions (Section 4.2.1), and
signature algorithms (Section 4.2.3) in the ClientHello?
* As a server, do you send a HelloRetryRequest to clients which
support a compatible (EC)DHE group but do not predict it in the
"key_share" extension? As a client, do you correctly handle a
HelloRetryRequest from the server?
Cryptographic details:
* What countermeasures do you use to prevent timing attacks
[TIMING]?
Rescorla Expires 27 September 2023 [Page 131]
Internet-Draft TLS March 2023
* When using Diffie-Hellman key exchange, do you correctly preserve
leading zero bytes in the negotiated key (see Section 7.4.1)?
* Does your TLS client check that the Diffie-Hellman parameters sent
by the server are acceptable (see Section 4.2.8.1)?
* Do you use a strong and, most importantly, properly seeded random
number generator (see Appendix C.1) when generating Diffie-Hellman
private values, the ECDSA "k" parameter, and other security-
critical values? It is RECOMMENDED that implementations implement
"deterministic ECDSA" as specified in [RFC6979]. Note that purely
deterministic ECC signatures such as deterministic ECDSA and EdDSA
may be vulnerable to certain side-channel and fault injection
attacks in easily accessible IoT devices.
* Do you zero-pad Diffie-Hellman public key values and shared
secrets to the group size (see Section 4.2.8.1 and Section 7.4.1)?
* Do you verify signatures after making them, to protect against
RSA-CRT key leaks [FW15]?
C.4. Client and Server Tracking Prevention
Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of
a ticket allows passive observers to correlate different connections.
Servers that issue tickets SHOULD offer at least as many tickets as
the number of connections that a client might use; for example, a web
browser using HTTP/1.1 [RFC7230] might open six connections to a
server. Servers SHOULD issue new tickets with every connection.
This ensures that clients are always able to use a new ticket when
creating a new connection.
Offering a ticket to a server additionally allows the server to
correlate different connections. This is possible independent of
ticket reuse. Client applications SHOULD NOT offer tickets across
connections that are meant to be uncorrelated. For example, [FETCH]
defines network partition keys to separate cache lookups in web
browsers.
Clients and Servers SHOULD NOT reuse a key share for multiple
connections. Reuse of a key share allows passive observers to
correlate different connections. Reuse of a client key share to the
same server additionally allows the server to correlate different
connections.
Rescorla Expires 27 September 2023 [Page 132]
Internet-Draft TLS March 2023
If an external PSK identity is used for multiple connections, then it
will generally be possible for an external observer to track clients
and/or servers across connections. Use of the Encrypted Client Hello
[I-D.ietf-tls-esni] extension can mitigate this risk, as can
mechanisms external to TLS that rotate the PSK identity.
C.5. Unauthenticated Operation
Previous versions of TLS offered explicitly unauthenticated cipher
suites based on anonymous Diffie-Hellman. These modes have been
deprecated in TLS 1.3. However, it is still possible to negotiate
parameters that do not provide verifiable server authentication by
several methods, including:
* Raw public keys [RFC7250].
* Using a public key contained in a certificate but without
validation of the certificate chain or any of its contents.
Either technique used alone is vulnerable to man-in-the-middle
attacks and therefore unsafe for general use. However, it is also
possible to bind such connections to an external authentication
mechanism via out-of-band validation of the server's public key,
trust on first use, or a mechanism such as channel bindings (though
the channel bindings described in [RFC5929] are not defined for TLS
1.3). If no such mechanism is used, then the connection has no
protection against active man-in-the-middle attack; applications MUST
NOT use TLS in such a way absent explicit configuration or a specific
application profile.
Appendix D. Updates to TLS 1.2
To align with the names used this document, the following terms from
[RFC5246] are renamed:
* The master secret, computed in Section 8.1 of [RFC5246], is
renamed to the main secret. It is referred to as main_secret in
formulas and structures, instead of master_secret. However, the
label parameter to the PRF function is left unchanged for
compatibility.
* The premaster secret is renamed to the preliminary secret. It is
referred to as preliminary_secret in formulas and structures,
instead of pre_master_secret.
* The PreMasterSecret and EncryptedPreMasterSecret structures,
defined in Section 7.4.7.1 of [RFC5246], are renamed to
PreliminarySecret and EncryptedPreliminarySecret, respectively.
Rescorla Expires 27 September 2023 [Page 133]
Internet-Draft TLS March 2023
Correspondingly, the extension defined in [RFC7627] is renamed to the
"Extended Main Secret" extension. The extension code point is
renamed to "extended_main_secret". The label parameter to the PRF
function in Section 4 of [RFC7627] is left unchanged for
compatibility.
Appendix E. Backward Compatibility
The TLS protocol provides a built-in mechanism for version
negotiation between endpoints potentially supporting different
versions of TLS.
TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can
also handle clients trying to use future versions of TLS as long as
the ClientHello format remains compatible and there is at least one
protocol version supported by both the client and the server.
Prior versions of TLS used the record layer version number
(TLSPlaintext.legacy_record_version and
TLSCiphertext.legacy_record_version) for various purposes. As of TLS
1.3, this field is deprecated. The value of
TLSPlaintext.legacy_record_version MUST be ignored by all
implementations. The value of TLSCiphertext.legacy_record_version is
included in the additional data for deprotection but MAY otherwise be
ignored or MAY be validated to match the fixed constant value.
Version negotiation is performed using only the handshake versions
(ClientHello.legacy_version and ServerHello.legacy_version, as well
as the ClientHello, HelloRetryRequest, and ServerHello
"supported_versions" extensions). In order to maximize
interoperability with older endpoints, implementations that negotiate
the use of TLS 1.0-1.2 SHOULD set the record layer version number to
the negotiated version for the ServerHello and all records
thereafter.
For maximum compatibility with previously non-standard behavior and
misconfigured deployments, all implementations SHOULD support
validation of certification paths based on the expectations in this
document, even when handling prior TLS versions' handshakes (see
Section 4.4.2.2).
TLS 1.2 and prior supported an "Extended Main Secret" [RFC7627]
extension which digested large parts of the handshake transcript into
the secret and derived keys. Note this extension was renamed in
Appendix D. Because TLS 1.3 always hashes in the transcript up to
the server Finished, implementations which support both TLS 1.3 and
earlier versions SHOULD indicate the use of the Extended Main Secret
extension in their APIs whenever TLS 1.3 is used.
Rescorla Expires 27 September 2023 [Page 134]
Internet-Draft TLS March 2023
E.1. Negotiating with an Older Server
A TLS 1.3 client who wishes to negotiate with servers that do not
support TLS 1.3 will send a normal TLS 1.3 ClientHello containing
0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct
version(s) in the "supported_versions" extension. If the server does
not support TLS 1.3, it will respond with a ServerHello containing an
older version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.
A client using a ticket for resumption SHOULD initiate the connection
using the version that was previously negotiated.
Note that 0-RTT data is not compatible with older servers and SHOULD
NOT be sent absent knowledge that the server supports TLS 1.3. See
Appendix E.3.
If the version chosen by the server is not supported by the client
(or is not acceptable), the client MUST abort the handshake with a
"protocol_version" alert.
Some legacy server implementations are known to not implement the TLS
specification properly and might abort connections upon encountering
TLS extensions or versions which they are not aware of.
Interoperability with buggy servers is a complex topic beyond the
scope of this document. Multiple connection attempts may be required
in order to negotiate a backward-compatible connection; however, this
practice is vulnerable to downgrade attacks and is NOT RECOMMENDED.
E.2. Negotiating with an Older Client
A TLS server can also receive a ClientHello indicating a version
number smaller than its highest supported version. If the
"supported_versions" extension is present, the server MUST negotiate
using that extension as described in Section 4.2.1. If the
"supported_versions" extension is not present, the server MUST
negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For
example, if the server supports TLS 1.0, 1.1, and 1.2, and
legacy_version is TLS 1.0, the server will proceed with a TLS 1.0
ServerHello. If the "supported_versions" extension is absent and the
server only supports versions greater than
ClientHello.legacy_version, the server MUST abort the handshake with
a "protocol_version" alert.
Note that earlier versions of TLS did not clearly specify the record
layer version number value in all cases
(TLSPlaintext.legacy_record_version). Servers will receive various
TLS 1.x versions in this field, but its value MUST always be ignored.
Rescorla Expires 27 September 2023 [Page 135]
Internet-Draft TLS March 2023
RFC 7612 LDAP Schema for Printer Services June 2015
Note: The syntax and values for this attribute are aligned with the
equivalent attribute in the 'service:printer:' v2.0 template
[SLPPRT20].
4.32. printer-stacking-order-supported
( 1.3.18.0.2.4.1115
NAME 'printer-stacking-order-supported'
DESC 'Comma-delimited list of stacking orders of pages as they are
printed and ejected supported by this Printer.'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
For example:
'unknown'
'first-to-last'
'first-to-last,last-to-first'
Values defined in "Printer MIB v2" [RFC3805] for
prtOutputStackingOrder are:
'first-to-last'
'last-to-first'
Note: The value 'unknown' MUST only be reported if the corresponding
Printer MIB attribute is not present, i.e., the value 'unknown' is an
artifact of this LDAP mapping.
Note: The syntax and values for this attribute are aligned with the
equivalent attribute in the 'service:printer:' v2.0 template
[SLPPRT20].
Fleming & McDonald Informational [Page 35]
RFC 7612 LDAP Schema for Printer Services June 2015
4.33. printer-output-features-supported
( 1.3.18.0.2.4.1116
NAME 'printer-output-features-supported'
DESC 'Comma-delimited list of output features supported by
this Printer.'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
For example:
'unknown'
'bursting,decollating'
'offset-stacking'
Note: Length overflow in values of this attribute MUST be handled by
multiple instances of this attribute, i.e., individual
comma-delimited list members MUST NOT be truncated.
Values defined in "Printer MIB v2" [RFC3805] for prtOutputBursting,
prtOutputDecollating, prtOutputPageCollated, and
prtOutputOffsetStacking are:
'bursting'
'decollating'
'page-collating'
'offset-stacking'
Note: The value 'unknown' MUST only be reported if the corresponding
Printer MIB attributes are not present, i.e., the value 'unknown' is
an artifact of this LDAP mapping.
Note: The syntax and values for this attribute are aligned with the
equivalent attribute in the 'service:printer:' v2.0 template
[SLPPRT20].
Note: Implementations MAY support other values.
Fleming & McDonald Informational [Page 36]
RFC 7612 LDAP Schema for Printer Services June 2015
4.34. printer-aliases
( 1.3.18.0.2.4.1108
NAME 'printer-aliases'
DESC 'One of the site-specific administrative names of this Printer
in addition to the value specified for printer-name.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
Values of this attribute SHOULD be specified in the language
specified in printer-natural-language-configured (for example, to
support text-to-speech conversions), although the Printer's alias MAY
be specified in any language.
Note: Multiple values for this attribute are represented as multiple
instances of this attribute.
Note: For compatibility with IPP/1.1 [RFC2911], values of this
attribute SHOULD NOT exceed 255 octets in length.
Note: For interoperability, values of this attribute (a) SHOULD be
normalized as recommended in "Unicode Format for Network Interchange"
[RFC5198]; and (b) SHOULD NOT contain DEL or any C0 or C1 control
characters.
4.35. printer-device-id
( 1.3.18.0.2.24.46.1.101
NAME 'printer-device-id'
DESC 'The IEEE 1284 Device ID for this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
Values of this attribute SHOULD conform to "PWG Command Set Format
for IEEE 1284 Device ID v1.0" [PWG5107.2].
Note: For compatibility with [PWG5100.14] and [PWG5107.2], values of
this attribute SHOULD NOT exceed 1023 octets in length.
Fleming & McDonald Informational [Page 37]
RFC 7612 LDAP Schema for Printer Services June 2015
4.36. printer-device-service-count
( 1.3.18.0.2.24.46.1.102
NAME 'printer-device-service-count'
DESC 'The number of Printer (print service) instances configured on
this Imaging Device (host system).'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
A positive value indicates the number of Printer (print service)
instances. A value of '-1' indicates 'unknown'. A value of '0' is
not meaningful (because this attribute must be reported by some
Printer instance).
Note: The syntax and values for this attribute are aligned with the
equivalent 'device-service-count' attribute defined in [PWG5100.13].
4.37. printer-uuid
( 1.3.18.0.2.24.46.1.104
NAME 'printer-uuid'
DESC 'A URN specifying the UUID of this Printer (print service)
instance on this Imaging Device (host system).'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
For example:
'urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6'
Values of this attribute MUST conform to the Universally Unique
Identifier (UUID) URN namespace [RFC4122].
Note: For compatibility with [PWG5100.13] and [RFC4122], values of
this attribute SHOULD NOT exceed 45 octets in length.
Note: LDAP application clients SHOULD NOT attempt to use malformed
URN values read from this attribute. LDAP administrative clients
SHOULD NOT write malformed URN values into this attribute.
Note: The syntax and values for this attribute are aligned with the
equivalent 'printer-uuid' attribute defined in [PWG5100.13].
Fleming & McDonald Informational [Page 38]
RFC 7612 LDAP Schema for Printer Services June 2015
4.38. printer-charge-info
( 1.3.18.0.2.24.46.1.105
NAME 'printer-charge-info'
DESC 'Descriptive information about paid printing services for this
Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
For example:
'This Printer can be used for paid printing at 2 cents/page.'
Note: For compatibility with [PWG5100.13], values of this attribute
SHOULD NOT exceed 1023 octets in length.
Note: For interoperability and consistent text display, values of
this attribute (a) SHOULD be normalized as recommended in "Unicode
Format for Network Interchange" [RFC5198]; (b) SHOULD NOT contain any
C0 or C1 control characters except for HT, CR, and LF; and (c) SHOULD
only contain CR and LF characters together (not as singletons).
Note: The syntax and values for this attribute are aligned with the
equivalent 'printer-charge-info&E.3. 0-RTT Backward Compatibility
0-RTT data is not compatible with older servers. An older server
will respond to the ClientHello with an older ServerHello, but it
will not correctly skip the 0-RTT data and will fail to complete the
handshake. This can cause issues when a client attempts to use
0-RTT, particularly against multi-server deployments. For example, a
deployment could deploy TLS 1.3 gradually with some servers
implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3
deployment could be downgraded to TLS 1.2.
A client that attempts to send 0-RTT data MUST fail a connection if
it receives a ServerHello with TLS 1.2 or older. It can then retry
the connection with 0-RTT disabled. To avoid a downgrade attack, the
client SHOULD NOT disable TLS 1.3, only 0-RTT.
To avoid this error condition, multi-server deployments SHOULD ensure
a uniform and stable deployment of TLS 1.3 without 0-RTT prior to
enabling 0-RTT.
E.4. Middlebox Compatibility Mode
Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found
that a significant number of middleboxes misbehave when a TLS client/
server pair negotiates TLS 1.3. Implementations can increase the
chance of making connections through those middleboxes by making the
TLS 1.3 handshake look more like a TLS 1.2 handshake:
* The client always provides a non-empty session ID in the
ClientHello, as described in the legacy_session_id section of
Section 4.1.2.
* If not offering early data, the client sends a dummy
change_cipher_spec record (see the third paragraph of Section 5)
immediately before its second flight. This may either be before
its second ClientHello or before its encrypted handshake flight.
If offering early data, the record is placed immediately after the
first ClientHello.
* The server sends a dummy change_cipher_spec record immediately
after its first handshake message. This may either be after a
ServerHello or a HelloRetryRequest.
When put together, these changes make the TLS 1.3 handshake resemble
TLS 1.2 session resumption, which improves the chance of successfully
connecting through middleboxes. This "compatibility mode" is
partially negotiated: the client can opt to provide a session ID or
not, and the server has to echo it. Either side can send
Rescorla Expires 27 September 2023 [Page 136]
Internet-Draft TLS March 2023
change_cipher_spec at any time during the handshake, as they must be
ignored by the peer, but if the client sends a non-empty session ID,
the server MUST send the change_cipher_spec as described in this
appendix.
E.5. Security Restrictions Related to Backward Compatibility
Implementations negotiating the use of older versions of TLS SHOULD
prefer forward secret and AEAD cipher suites, when available.
The security of RC4 cipher suites is considered insufficient for the
reasons cited in [RFC7465]. Implementations MUST NOT offer or
negotiate RC4 cipher suites for any version of TLS for any reason.
Old versions of TLS permitted the use of very low strength ciphers.
Ciphers with a strength less than 112 bits MUST NOT be offered or
negotiated for any version of TLS for any reason.
The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246],
and TLS 1.1 [RFC4346] are considered insufficient for the reasons
enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT
be negotiated for any reason.
Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an
SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT
RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
order to negotiate older versions of TLS.
Implementations MUST NOT send a ClientHello.legacy_version or
ServerHello.legacy_version set to 0x0300 or less. Any endpoint
receiving a Hello message with ClientHello.legacy_version or
ServerHello.legacy_version set to 0x0300 MUST abort the handshake
with a "protocol_version" alert.
Implementations MUST NOT send any records with a version less than
0x0300. Implementations SHOULD NOT accept any records with a version
less than 0x0300 (but may inadvertently do so if the record version
number is ignored completely).
Implementations MUST NOT use the Truncated HMAC extension, defined in
Section 7 of [RFC6066], as it is not applicable to AEAD algorithms
and has been shown to be insecure in some scenarios.
Rescorla Expires 27 September 2023 [Page 137]
Internet-Draft TLS March 2023
Appendix F. Overview of Security Properties
A complete security analysis of TLS is outside the scope of this
document. In this appendix, we provide an informal description of
the desired properties as well as references to more detailed work in
the research literature which provides more formal definitions.
We cover properties of the handshake separately from those of the
record layer.
F.1. Handshake
The TLS handshake is an Authenticated Key Exchange (AKE) protocol
which is intended to provide both one-way authenticated (server-only)
and mutually authenticated (client and server) functionality. At the
completion of the handshake, each side outputs its view of the
following values:
* A set of "session keys" (the various secrets derived from the main
secret) from which can be derived a set of working keys.
* A set of cryptographic parameters (algorithms, etc.).
* The identities of the communicating parties.
We assume the attacker to be an active network attacker, which means
it has complete control over the network used to communicate between
the parties [RFC3552]. Even under these conditions, the handshake
should provide the properties listed below. Note that these
properties are not necessarily independent, but reflect the protocol
consumers' needs.
Establishing the same session keys: The handshake needs to output
the same set of session keys on both sides of the handshake,
provided that it completes successfully on each endpoint (see
[CK01]; Definition 1, part 1).
Secrecy of the session keys: The shared session keys should be known
only to the communicating parties and not to the attacker (see
[CK01]; Definition 1, part 2). Note that in a unilaterally
authenticated connection, the attacker can establish its own
session keys with the server, but those session keys are distinct
from those established by the client.
Peer Authentication: The client's view of the peer identity should
reflect the server's identity. If the client is authenticated,
the server's view of the peer identity should match the client's
identity.
Rescorla Expires 27 September 2023 [Page 138]
Internet-Draft TLS March 2023
Uniqueness of the session keys: Any two distinct handshakes should
produce distinct, unrelated session keys. Individual session keys
produced by a handshake should also be distinct and independent.
Downgrade Protection: The cryptographic parameters should be the
same on both sides and should be the same as if the peers had been
communicating in the absence of an attack (see [BBFGKZ16];
Definitions 8 and 9).
Forward secret with respect to long-term keys: If the long-term
keying material (in this case the signature keys in certificate-
based authentication modes or the external/resumption PSK in PSK
with (EC)DHE modes) is compromised after the handshake is
complete, this does not compromise the security of the session key
(see [DOW92]), as long as the session key itself (and all material
that could be used to recreate the session key) has been erased.
In particular, private keys corresponding to key shares, shared
secrets, and keys derived in the TLS Key Schedule other than
binder_key, resumption_secret, and PSKs derived from the
resumption_secret also need to be erased. The forward secrecy
property is not satisfied when PSK is used in the "psk_ke"
PskKeyExchangeMode. Failing to erase keys or secrets intended to
be ephemeral or connection-specific in effect creates additional
long-term keys that must be protected. Compromise of those long-
term keys (even after the handshake is complete) can result in
loss of protection for the connection's traffic.
Key Compromise Impersonation (KCI) resistance: In a mutually
authenticated connection with certificates, compromising the long-
term secret of one actor should not break that actor's
authentication of their peer in the given connection (see
[HGFS15]). For example, if a client's signature key is
compromised, it should not be possible to impersonate arbitrary
servers to that client in subsequent handshakes.
Protection of endpoint identities: The server's identity
(certificate) should be protected against passive attackers. The
client's identity (certificate) should be protected against both
passive and active attackers. This property does not hold for
cipher suites without confidentiality; while this specification
does not define any such cipher suites, other documents may do so.
Informally, the signature-based modes of TLS 1.3 provide for the
establishment of a unique, secret, shared key established by an
(EC)DHE key exchange and authenticated by the server's signature over
the handshake transcript, as well as tied to the server's identity by
a MAC. If the client is authenticated by a certificate, it also
signs over the handshake transcript and provides a MAC tied to both
Rescorla Expires 27 September 2023 [Page 139]
Internet-Draft TLS March 2023
identities. [SIGMA] describes the design and analysis of this type
of key exchange protocol. If fresh (EC)DHE keys are used for each
connection, then the output keys are forward secret.
The external PSK and resumption PSK bootstrap from a long-term shared
secret into a unique per-connection set of short-term session keys.
This secret may have been established in a previous handshake. If
PSK with (EC)DHE key establishment is used, these session keys will
also be forward secret. The resumption PSK has been designed so that
the resumption secret computed by connection N and needed to form
connection N+1 is separate from the traffic keys used by connection
N, thus providing forward secrecy between the connections. In
addition, if multiple tickets are established on the same connection,
they are associated with different keys, so compromise of the PSK
associated with one ticket does not lead to the compromise of
connections established with PSKs associated with other tickets.
This property is most interesting if tickets are stored in a database
(and so can be deleted) rather than if they are self-encrypted.
Forward secrecy limits the effect of key leakage in one direction
(compromise of a key at time T2 does not compromise some key at time
T1 where T1 < T2). Protection in the other direction (compromise at
time T1 does not compromise keys at time T2) can be achieved by
rerunning EC(DHE). If a long-term authentication key has been
compromised, a full handshake with EC(DHE) gives protection against
passive attackers. If the resumption_master_secret has been
compromised, a resumption handshake with EC(DHE) gives protection
against passive attackers and a full handshake with EC(DHE) gives
protection against active attackers. If a traffic secret has been
compromised, any handshake with EC(DHE) gives protection against
active attackers. Using the terms in [RFC7624], forward secrecy
without rerunning EC(DHE) does not stop an attacker from doing static
key exfiltration. After key exfiltration of
application_traffic_secret_N, an attacker can e.g., passively
eavesdrop on all future data sent on the connection including data
encrypted with application_traffic_secret_N+1,
application_traffic_secret_N+2, etc. Frequently rerunning EC(DHE)
forces an attacker to do dynamic key exfiltration (or content
exfiltration).
Rescorla Expires 27 September 2023 [Page 140]
Internet-Draft TLS March 2023
The PSK binder value forms a binding between a PSK and the current
handshake, as well as between the session where the PSK was
established and the current session. This binding transitively
includes the original handshake transcript, because that transcript
is digested into the values which produce the resumption secret.
This requires that both the KDF used to produce the resumption secret
and the MAC used to compute the binder be collision resistant. See
Appendix F.1.1 for more on this. Note: The binder does not cover the
binder values from other PSKs, though they are included in the
Finished MAC.
Note: This specification does not currently permit the server to send
a certificate_request message in non-certificate-based handshakes
(e.g., PSK). If this restriction were to be relaxed in future, the
client's signature would not cover the server's certificate directly.
However, if the PSK was established through a NewSessionTicket, the
client's signature would transitively cover the server's certificate
through the PSK binder. [PSK-FINISHED] describes a concrete attack
on constructions that do not bind to the server's certificate (see
also [Kraw16]). It is unsafe to use certificate-based client
authentication when the client might potentially share the same PSK/
key-id pair with two different endpoints. In the absence of some
other specification to the contrary, implementations MUST NOT combine
external PSKs with certificate-based authentication of either the
client or server. [RFC8773] provides an extension to permit this,
but has not received the level of analysis as this specification.
If an exporter is used, then it produces values which are unique and
secret (because they are generated from a unique session key).
Exporters computed with different labels and contexts are
computationally independent, so it is not feasible to compute one
from another or the session secret from the exported value. Note:
Exporters can produce arbitrary-length values; if exporters are to be
used as channel bindings, the exported value MUST be large enough to
provide collision resistance. The exporters provided in TLS 1.3 are
derived from the same Handshake Contexts as the early traffic keys
and the application traffic keys, respectively, and thus have similar
security properties. Note that they do not include the client's
certificate; future applications which wish to bind to the client's
certificate may need to define a new exporter that includes the full
handshake transcript.
For all handshake modes, the Finished MAC (and, where present, the
signature) prevents downgrade attacks. In addition, the use of
certain bytes in the random nonces as described in Section 4.1.3
allows the detection of downgrade to previous TLS versions. See
[BBFGKZ16] for more details on TLS 1.3 and downgrade.
Rescorla Expires 27 September 2023 [Page 141]
Internet-Draft TLS March 2023
As soon as the client and the server have exchanged enough
information to establish shared keys, the remainder of the handshake
is encrypted, thus providing protection against passive attackers,
even if the computed shared key is not authenticated. Because the
server authenticates before the client, the client can ensure that if
it authenticates to the server, it only reveals its identity to an
authenticated server. Note that implementations must use the
provided record-padding mechanism during the handshake to avoid
leaking information about the identities due to length. The client's
proposed PSK identities are not encrypted, nor is the one that the
server selects.
F.1.1. Key Derivation and HKDF
Key derivation in TLS 1.3 uses HKDF as defined in [RFC5869] and its
two components, HKDF-Extract and HKDF-Expand. The full rationale for
the HKDF construction can be found in [Kraw10] and the rationale for
the way it is used in TLS 1.3 in [KW16]. Throughout this document,
each application of HKDF-Extract is followed by one or more
invocations of HKDF-Expand. This ordering should always be followed
(including in future revisions of this document); in particular, one
SHOULD NOT use an output of HKDF-Extract as an input to another
application of HKDF-Extract without an HKDF-Expand in between.
Multiple applications of HKDF-Expand to some of the same inputs are
allowed as long as these are differentiated via the key and/or the
labels.
Note that HKDF-Expand implements a pseudorandom function (PRF) with
both inputs and outputs of variable length. In some of the uses of
HKDF in this document (e.g., for generating exporters and the
resumption_secret), it is necessary that the application of HKDF-
Expand be collision resistant; namely, it should be infeasible to
find two different inputs to HKDF-Expand that output the same value.
This requires the underlying hash function to be collision resistant
and the output length from HKDF-Expand to be of size at least 256
bits (or as much as needed for the hash function to prevent finding
collisions).
F.1.2. Certificate-Based Client Authentication
A client that has sent certificate-based authentication data to a
server, either during the handshake or in post-handshake
authentication, cannot be sure whether the server afterwards
considers the client to be authenticated or not. If the client needs
to determine if the server considers the connection to be
unilaterally or mutually authenticated, this has to be provisioned by
the application layer. See [CHHSV17] for details. In addition, the
analysis of post-handshake authentication from [Kraw16] shows that
Rescorla Expires 27 September 2023 [Page 142]
Internet-Draft TLS March 2023
the client identified by the certificate sent in the post-handshake
phase possesses the traffic key. This party is therefore the client
that participated in the original handshake or one to whom the
original client delegated the traffic key (assuming that the traffic
key has not been compromised).
F.1.3. 0-RTT
The 0-RTT mode of operation generally provides security properties
similar to those of 1-RTT data, with the two exceptions that the
0-RTT encryption keys do not provide full forward secrecy and that
the server is not able to guarantee uniqueness of the handshake (non-
replayability) without keeping potentially undue amounts of state.
See Section 8 for mechanisms to limit the exposure to replay.
F.1.4. Exporter Independence
The exporter_secret and early_exporter_secret are derived to be
independent of the traffic keys and therefore do not represent a
threat to the security of traffic encrypted with those keys.
However, because these secrets can be used to compute any exporter
value, they SHOULD be erased as soon as possible. If the total set
of exporter labels is known, then implementations SHOULD pre-compute
the inner Derive-Secret stage of the exporter computation for all
those labels, then erase the [early_]exporter_secret, followed by
each inner values as soon as it is known that it will not be needed
again.
F.1.5. Post-Compromise Security
TLS does not provide security for handshakes which take place after
the peer's long-term secret (signature key or external PSK) is
compromised. It therefore does not provide post-compromise security
[CCG16], sometimes also referred to as backwards or future secrecy.
This is in contrast to KCI resistance, which describes the security
guarantees that a party has after its own long-term secret has been
compromised.
F.1.6. External References
The reader should refer to the following references for analysis of
the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16],
[FGSW16], [LXZFH16], [FG17], and [BBK17].
Rescorla Expires 27 September 2023 [Page 143]
Internet-Draft TLS March 2023
F.2. Record Layer
The record layer depends on the handshake producing strong traffic
secrets which can be used to derive bidirectional encryption keys and
nonces. Assuming that is true, and the keys are used for no more
data than indicated in Section 5.5, then the record layer should
provide the following guarantees:
Confidentiality: An attacker should not be able to determine the
plaintext contents of a given record.
Integrity: An attacker should not be able to craft a new record
which is different from an existing record which will be accepted
by the receiver.
Order protection/non-replayability: An attacker should not be able
to cause the receiver to accept a record which it has already
accepted or cause the receiver to accept record N+1 without having
first processed record N.
Length concealment: Given a record with a given external length, the
attacker should not be able to determine the amount of the record
that is content versus padding.
Forward secrecy after key change: If the traffic key update
mechanism described in Section 4.6.3 has been used and the
previous generation key is deleted, an attacker who compromises
the endpoint should not be able to decrypt traffic encrypted with
the old key.
Informally, TLS 1.3 provides these properties by AEAD-protecting the
plaintext with a strong key. AEAD encryption [RFC5116] provides
confidentiality and integrity for the data. Non-replayability is
provided by using a separate nonce for each record, with the nonce
being derived from the record sequence number (Section 5.3), with the
sequence number being maintained independently at both sides; thus
records which are delivered out of order result in AEAD deprotection
failures. In order to prevent mass cryptanalysis when the same
plaintext is repeatedly encrypted by different users under the same
key (as is commonly the case for HTTP), the nonce is formed by mixing
the sequence number with a secret per-connection initialization
vector derived along with the traffic keys. See [BT16] for analysis
of this construction.
The rekeying technique in TLS 1.3 (see Section 7.2) follows the
construction of the serial generator as discussed in [REKEY], which
shows that rekeying can allow keys to be used for a larger number of
encryptions than without rekeying. This relies on the security of
Rescorla Expires 27 September 2023 [Page 144]
Internet-Draft TLS March 2023
the HKDF-Expand-Label function as a pseudorandom function (PRF). In
addition, as long as this function is truly one way, it is not
possible to compute traffic keys from prior to a key change (forward
secrecy).
TLS does not provide security for data which is communicated on a
connection after a traffic secret of that connection is compromised.
That is, TLS does not provide post-compromise security/future
secrecy/backward secrecy with respect to the traffic secret. Indeed,
an attacker who learns a traffic secret can compute all future
traffic secrets on that connection. Systems which want such
guarantees need to do a fresh handshake and establish a new
connection with an (EC)DHE exchange.
F.2.1. External References
The reader should refer to the following references for analysis of
the TLS record layer: [BMMRT15], [BT16], [BDFKPPRSZZ16], [BBK17], and
[PS18].
F.3. Traffic Analysis
TLS is susceptible to a variety of traffic analysis attacks based on
observing the length and timing of encrypted packets [CLINIC]
[HCJC16]. This is particularly easy when there is a small set of
possible messages to be distinguished, such as for a video server
hosting a fixed corpus of content, but still provides usable
information even in more complicated scenarios.
TLS does not provide any specific defenses against this form of
attack but does include a padding mechanism for use by applications:
The plaintext protected by the AEAD function consists of content plus
variable-length padding, which allows the application to produce
arbitrary-length encrypted records as well as padding-only cover
traffic to conceal the difference between periods of transmission and
periods of silence. Because the padding is encrypted alongside the
actual content, an attacker cannot directly determine the length of
the padding, but may be able to measure it indirectly by the use of
timing channels exposed during record processing (i.e., seeing how
long it takes to process a record or trickling in records to see
which ones elicit a response from the server). In general, it is not
known how to remove all of these channels because even a constant-
time padding removal function will likely feed the content into data-
dependent functions. At minimum, a fully constant-time server or
client would require close cooperation with the application-layer
protocol implementation, including making that higher-level protocol
constant time.
Rescorla Expires 27 September 2023 [Page 145]
Internet-Draft TLS March 2023
Note: Robust traffic analysis defenses will likely lead to inferior
performance due to delays in transmitting packets and increased
traffic volume.
F.4. Side Channel Attacks
In general, TLS does not have specific defenses against side-channel
attacks (i.e., those which attack the communications via secondary
channels such as timing), leaving those to the implementation of the
relevant cryptographic primitives. However, certain features of TLS
are designed to make it easier to write side-channel resistant code:
* Unlike previous versions of TLS which used a composite MAC-then-
encrypt structure, TLS 1.3 only uses AEAD algorithms, allowing
implementations to use self-contained constant-time
implementations of those primitives.
* TLS uses a uniform "bad_record_mac" alert for all decryption
errors, which is intended to prevent an attacker from gaining
piecewise insight into portions of the message. Additional
resistance is provided by terminating the connection on such
errors; a new connection will have different cryptographic
material, preventing attacks against the cryptographic primitives
that require multiple trials.
Information leakage through side channels can occur at layers above
TLS, in application protocols and the applications that use them.
Resistance to side-channel attacks depends on applications and
application protocols separately ensuring that confidential
information is not inadvertently leaked.
F.5. Replay Attacks on 0-RTT
Replayable 0-RTT data presents a number of security threats to TLS-
using applications, unless those applications are specifically
engineered to be safe under replay (minimally, this means idempotent,
but in many cases may also require other stronger conditions, such as
constant-time response). Potential attacks include:
* Duplication of actions which cause side effects (e.g., purchasing
an item or transferring money) to be duplicated, thus harming the
site or the user.
* Attackers can store and replay 0-RTT messages in order to reorder
them with respect to other messages (e.g., moving a delete to
after a create).
Rescorla Expires 27 September 2023 [Page 146]
Internet-Draft TLS March 2023
#x27; attribute defined in [PWG5100.13].
4.39. printer-charge-info-uri
( 1.3.18.0.2.24.46.1.106
NAME 'printer-charge-info-uri'
DESC 'A URI for a human-readable Web page for paid printing services
for this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
For example:
'http://example.com/charges'
See [STD66] for details of URI syntax.
Note: For compatibility with IPP/1.1 [RFC2911] and [PWG5100.13],
values of this attribute SHOULD NOT exceed 1023 octets in length.
Fleming & McDonald Informational [Page 39]
RFC 7612 LDAP Schema for Printer Services June 2015
Note: LDAP application clients SHOULD NOT attempt to use malformed
URI values read from this attribute. LDAP administrative clients
SHOULD NOT write malformed URI values into this attribute.
Note: The syntax and values for this attribute are aligned with the
equivalent 'printer-charge-info-uri' attribute defined in
[PWG5100.13].
4.40. printer-geo-location
( 1.3.18.0.2.24.46.1.107
NAME 'printer-geo-location'
DESC 'A geo: URI specifying the geographic location of this Printer.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
For example:
'geo:13.4125,103.8667'
Values of this attribute MUST conform to the 'geo' URI scheme
[RFC5870].
Note: For compatibility with IPP/1.1 [RFC2911] and [PWG5100.13],
values of this attribute SHOULD NOT exceed 1023 octets in length.
Note: LDAP application clients SHOULD NOT attempt to use malformed
URI values read from this attribute. LDAP administrative clients
SHOULD NOT write malformed URI values into this attribute.
Note: The syntax and values for this attribute are aligned with the
equivalent 'printer-geo-location' attribute defined in [PWG5100.13].
Fleming & McDonald Informational [Page 40]
RFC 7612 LDAP Schema for Printer Services June 2015
4.41. printer-ipp-features-supported
( 1.3.18.0.2.24.46.1.108
NAME 'printer-ipp-features-supported'
DESC 'Comma-delimited list of IPP protocol features that
this Printer supports.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
For example:
'none'
'unknown'
'proof-print'
'ipp-everywhere,proof-print,job-save'
Note: Length overflow in values of this attribute MUST be handled by
multiple instances of this attribute, i.e., individual
comma-delimited list members MUST NOT be truncated.
Values of this attribute SHOULD specify only IANA-registered keywords
for the 'ipp-features-supported' attribute defined in [PWG5100.13] or
other Standards Track IETF or IEEE-ISTO PWG specifications if this
Printer implementation meets all of the IPP feature-specific
conformance requirements.
IANA-registered values include:
'none' (No extension features are supported)
'document-object' (Document object defined in [PWG5100.5])
'job-save' (Job save defined in [PWG5100.11])
'ipp-everywhere' ("IPP Everywhere" defined in [PWG5100.14])
'page-overrides' (Page overrides defined in [PWG5100.6])
'proof-print' (Proof print defined in [PWG5100.11])
'subscription-object' (Subscription object defined in [RFC3995])
Note: The value 'unknown' MUST only be reported if the corresponding
IPP Printer attribute is not present, i.e., the value 'unknown' is an
artifact of this LDAP mapping.
Note: The syntax and values for this attribute are aligned with the
equivalent 'ipp-features-supported' attribute defined in
[PWG5100.13].
Fleming & McDonald Informational [Page 41]
RFC 7612 LDAP Schema for Printer Services June 2015
5. Definition of Syntaxes
No new attribute syntaxes are defined by this document.
The attribute types defined in Section 4 of this document reference
syntax OIDs defined in Section 3 of [RFC4517], which are summarized
below:
Syntax OID Syntax Description
------------------------------ -------------------------------
1.3.6.1.4.1.1466.115.121.1.7 Boolean
1.3.6.1.4.1.1466.115.121.1.15 DirectoryString (UTF-8 [STD63])
1.3.6.1.4.1.1466.115.121.1.27 Integer
6. Definition of Matching Rules
No new matching rules are defined by this document.
The attribute types defined in Section 4 of this document reference
matching rules defined in Section 4 of [RFC4517], which are
summarized below:
Matching Rule OID Matching Rule Name Usage
----------------------------- ------------------ --------
2.5.13.13 booleanMatch EQUALITY
2.5.13.2 caseIgnoreMatch EQUALITY
2.5.13.14 integerMatch EQUALITY
2.5.13.15 integerOrderingMatch ORDERING
2.5.13.4 caseIgnoreSubstringsMatch SUBSTR
7. IANA Considerations
This document does not define any new syntaxes or matching rules.
This document defines a few new attribute types that have been
registered by IANA per this document (see Section 7.1 below).
All of the object classes and most of the attribute types described
in this document were registered by IANA when RFC 3712 was published
(see Section 7.2 below).
Fleming & McDonald Informational [Page 42]
RFC 7612 LDAP Schema for Printer Services June 2015
7.1. Registration of Attribute Types
The following Attribute Type OIDs have been assigned by the IEEE-ISTO
PWG (see Section 1.3.2) and have been registered by IANA.
Subject: Request for Object Identifier Descriptor Registration
Descriptor (short name): see table below
Object Identifier: see table below
Person & email address to contact for further information: see below
Usage: attribute type
Specification: RFC 7612 (this document)
Author/Change Controller:
Ira McDonald
High North Inc.
221 Ridge Ave.
Grand Marais, MI 49839
United States
Phone: +1 906-494-2434
Email: blueroofmusic@gmail.com
Comments:
Attribute Type OID
------------------------------------ ----------------------
printer-device-id 1.3.18.0.2.24.46.1.101
printer-device-service-count 1.3.18.0.2.24.46.1.102
printer-uuid 1.3.18.0.2.24.46.1.104
printer-charge-info 1.3.18.0.2.24.46.1.105
printer-charge-info-uri 1.3.18.0.2.24.46.1.106
printer-geo-location 1.3.18.0.2.24.46.1.107
printer-ipp-features-supported 1.3.18.0.2.24.46.1.108
Fleming & McDonald Informational [Page 43]
RFC 7612 LDAP Schema for Printer Services June 2015
7.2. Object Classes and Attribute Types from RFC 3712
This section is strictly informative. None of the LDAP OIDs listed
in this section have been re-registered by IANA.
The following Object Class OIDs were assigned by IBM (see
Section 1.3.1) and were already registered by IANA when RFC 3712 was
published.
Object Class OID
------------------------------------ ----------------
slpServicePrinter 1.3.18.0.2.6.254
printerAbstract 1.3.18.0.2.6.258
printerService 1.3.18.0.2.6.255
printerServiceAuxClass 1.3.18.0.2.6.257
printerIPP 1.3.18.0.2.6.256
printerLPR 1.3.18.0.2.6.253
The following Attribute Type OIDs were assigned by IBM (see
Section 1.3.1) and were already registered by IANA when RFC 3712 was
published.
Attribute Type OID
------------------------------------ -----------------
printer-uri 1.3.18.0.2.4.1140
printer-xri-supported 1.3.18.0.2.4.1107
printer-name 1.3.18.0.2.4.1135
printer-natural-language-configured 1.3.18.0.2.4.1119
printer-location 1.3.18.0.2.4.1136
printer-info 1.3.18.0.2.4.1139
printer-more-info 1.3.18.0.2.4.1134
printer-make-and-model 1.3.18.0.2.4.1138
printer-ipp-versions-supported 1.3.18.0.2.4.1133
printer-multiple-document-jobs-supported 1.3.18.0.2.4.1132
printer-charset-configured 1.3.18.0.2.4.1109
printer-charset-supported 1.3.18.0.2.4.1131
printer-generated-natural-language-supported 1.3.18.0.2.4.1137
printer-document-format-supported 1.3.18.0.2.4.1130
printer-color-supported 1.3.18.0.2.4.1129
printer-compression-supported 1.3.18.0.2.4.1128
printer-pages-per-minute 1.3.18.0.2.4.1127
printer-pages-per-minute-color 1.3.18.0.2.4.1126
printer-finishings-supported 1.3.18.0.2.4.1125
printer-number-up-supported 1.3.18.0.2.4.1124
printer-sides-supported 1.3.18.0.2.4.1123
printer-media-supported 1.3.18.0.2.4.1122
printer-media-local-supported 1.3.18.0.2.4.1117
printer-resolution-supported 1.3.18.0.2.4.1121
Fleming & McDonald Informational [Page 44]
RFC 7612 LDAP Schema for Printer Services June 2015
printer-print-quality-supported 1.3.18.0.2.4.1120
printer-job-priority-supported 1.3.18.0.2.4.1110
printer-copies-supported 1.3.18.0.2.4.1118
printer-job-k-octets-supported 1.3.18.0.2.4.1111
printer-current-operator 1.3.18.0.2.4.1112
printer-service-person 1.3.18.0.2.4.1113
printer-delivery-orientation-supported 1.3.18.0.2.4.1114
printer-stacking-order-supported 1.3.18.0.2.4.1115
printer-output-features-supported 1.3.18.0.2.4.1116
printer-aliases 1.3.18.0.2.4.1108
8. Internationalization Considerations
All text string attributes defined in this document of syntax
'DirectoryString' [RFC4517] have values that are encoded in UTF-8
[STD63], as required by [RFC4517].
A language tag [BCP47] for all of the text string attributes defined
in this document is contained in the
printer-natural-language-configured attribute.
Therefore, all object classes defined in this document conform to the
IETF Policy on Character Sets and Languages [BCP18].
Note: For interoperability and consistent text display, values of
attributes defined in this document (a) SHOULD be normalized as
recommended in "Unicode Format for Network Interchange" [RFC5198];
(b) SHOULD NOT contain DEL or any C0 or C1 control characters except
for HT, CR, and LF; (c) SHOULD only contain CR and LF characters
together (not as singletons); and (d) SHOULD NOT contain HT, CR, or
LF characters in names, e.g., printer-name and printer-aliases.
9. Security Considerations
See [RFC4513] for detailed guidance on authentication methods for
LDAP and the use of TLS/1.2 [RFC5246] to supply connection
confidentiality and data integrity for LDAP sessions.
As with any LDAP schema, it is important to protect specific entries
and attributes with the appropriate access control. It is
particularly important that only administrators can modify entries
defined in this LDAP Printer schema. Otherwise, an LDAP client might
be fooled into diverting print service requests from the original
Printer (or spooler) to a malicious intruder's host system, thus
exposing the information in printed documents.
Fleming & McDonald Informational [Page 45]
RFC 7612 LDAP Schema for Printer Services June 2015
Note: Security vulnerabilities can arise if DEL or any C0 or C1
control characters are included in names, e.g., printer-name or
printer-aliases.
For additional security considerations regarding deploying Printers
in an IPP environment, see Section 8 of [RFC2911].
10. References
10.1. Normative References
[BCP47] Phillips, A. and M. Davis, "Matching of Language Tags",
BCP 47, RFC 4647, September 2006.
Phillips, A., Ed., and M. Davis, Ed., "Tags for
Identifying Languages", BCP 47, RFC 5646,
September 2009.
<http://www.rfc-editor.org/info/bcp47>
[IANACHAR] Internet Assigned Numbers Authority (IANA) registry
"Character Sets",
<http://www.iana.org/assignments/character-sets>.
[IANAIPP] Internet Assigned Numbers Authority (IANA) registry
"Internet Printing Protocol (IPP) Registrations",
<http://www.iana.org/assignments/ipp-registrations>.
[IANAMIME] Internet Assigned Numbers Authority (IANA) registry
"Media Types", <http://www.iana.org/assignments/
media-types/index.html>.
[PWG5100.5] Carney, D., Hastings, T., and P. Zehler, "IPP Document
Object", PWG 5100.5-2003, October 2003,
<http://www.pwg.org/standards.html>.
[PWG5100.6] Zehler, P., Herriot, R., and K. Ocke, "IPP Page
Overrides", PWG 5100.6-2003, October 2003,
<http://www.pwg.org/standards.html>.
[PWG5100.11] Hastings, T. and D. Fullman, "IPP Job and Printer
Extensions - Set 2 (JPS2)", PWG 5100.11-2010,
October 2010, <http://www.pwg.org/standards.html>.
[PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, "IPP
Version 2.0 Second Edition (IPP/2.0 SE)",
PWG 5100.12-2011, February 2011,
<http://www.pwg.org/standards.html>.
Fleming & McDonald Informational [Page 46]
RFC 7612 LDAP Schema for Printer Services June 2015
[PWG5100.13] Sweet, M., McDonald, I., and P. Zehler, "IPP Job and
Printer Extensions - Set 3 (JPS3)", PWG 5100.13-2012,
July 2012, <http://www.pwg.org/standards.html>.
[PWG5100.14] Sweet, M., McDonald, I., Mitchell, A., and J. Hutchings,
"IPP Everywhere", PWG 5100.14-2013, January 2013,
<http://www.pwg.org/standards.html>.
[PWG5101.1] Sweet, M., Bergman, R., and T. Hastings, "PWG Media
Standardized Names 2.0 (MSN2)", PWG 5101.1-2013,
March 2013, <http://www.pwg.org/standards.html>.
[PWG5107.2] McDonald, I., "PWG Command Set Format for IEEE 1284
Device ID v1.0", PWG 5107.2-2010, May 2010,
<http://www.pwg.org/standards.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, DOI 10.17487/RFC2617, June 1999,
<http://www.rfc-editor.org/info/rfc2617>.
[RFC2707] Bergman, R., Hastings, T., Isaacson, S., and H. Lewis,
"Job Monitoring MIB - V1.0", RFC 2707,
DOI 10.17487/RFC2707, November 1999,
<http://www.rfc-editor.org/info/rfc2707>.
[RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S.,
and P. Powell, "Internet Printing Protocol/1.1: Model
and Semantics", RFC 2911, DOI 10.17487/RFC2911,
September 2000,
<http://www.rfc-editor.org/info/rfc2911>.
[RFC2926] Kempf, J., Moats, R., and P. St. Pierre, "Conversion of
LDAP Schemas to and from SLP Templates", RFC 2926,
DOI 10.17487/RFC2926, September 2000,
<http://www.rfc-editor.org/info/rfc2926>.
[RFC3510] Herriot, R. and I. McDonald, "Internet Printing
Protocol/1.1: IPP URL Scheme", RFC 3510,
DOI 10.17487/RFC3510, April 2003,
<http://www.rfc-editor.org/info/rfc3510>.
Fleming & McDonald Informational [Page 47]
RFC 7612 LDAP Schema for Printer Services June 2015
[RFC3805] Bergman, R., Lewis, H., and I. McDonald, "Printer
MIB v2", RFC 3805, DOI 10.17487/RFC3805, June 2004,
<http://www.rfc-editor.org/info/rfc3805>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
January 2005, <http://www.rfc-editor.org/info/rfc3987>.
[RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol
(IPP): Event Notifications and Subscriptions", RFC 3995,
DOI 10.17487/RFC3995, March 2005,
<http://www.rfc-editor.org/info/rfc3995>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): Technical Specification Road Map",
RFC 4510, DOI 10.17487/RFC4510, June 2006,
<http://www.rfc-editor.org/info/rfc4510>.
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access
Protocol (LDAP): Authentication Methods and Security
Mechanisms", RFC 4513, DOI 10.17487/RFC4513, June 2006,
<http://www.rfc-editor.org/info/rfc4513>.
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517,
DOI 10.17487/RFC4517, June 2006,
<http://www.rfc-editor.org/info/rfc4517>.
[RFC4524] Zeilenga, K., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
DOI 10.17487/RFC4524, June 2006,
<http://www.rfc-editor.org/info/rfc4524>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for
Network Interchange", RFC 5198, DOI 10.17487/RFC5198,
March 2008, <http://www.rfc-editor.org/info/rfc5198>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
Fleming & McDonald Informational [Page 48]
RFC 7612 LDAP Schema for Printer Services June 2015
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280,
May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
Identifier for Geographic Locations ('geo' URI)",
RFC 5870, DOI 10.17487/RFC5870, June 2010,
<http://www.rfc-editor.org/info/rfc5870>.
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818,
January 2013, <http://www.rfc-editor.org/info/rfc6818>.
[RFC7235] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>.
[RFC7472] McDonald, I. and M. Sweet, "Internet Printing Protocol
(IPP) over HTTPS Transport Binding and the 'ipps' URI
Scheme", RFC 7472, DOI 10.17487/RFC7472, March 2015,
<http://www.rfc-editor.org/info/rfc7472>.
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003,
<http://www.rfc-editor.org/info/std63>.
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005,
<http://www.rfc-editor.org/info/std66>.
* Amplifying existing information leaks caused by side effects like
caching. An attacker could learn information about the content of
a 0-RTT message by replaying it to some cache node that has not
cached some resource of interest, and then using a separate
connection to check whether that resource has been added to the
cache. This could be repeated with different cache nodes as often
as the 0-RTT message is replayable.
If data can be replayed a large number of times, additional attacks
become possible, such as making repeated measurements of the speed of
cryptographic operations. In addition, they may be able to overload
rate-limiting systems. For a further description of these attacks,
see [Mac17].
Ultimately, servers have the responsibility to protect themselves
against attacks employing 0-RTT data replication. The mechanisms
described in Section 8 are intended to prevent replay at the TLS
layer but do not provide complete protection against receiving
multiple copies of client data. TLS 1.3 falls back to the 1-RTT
handshake when the server does not have any information about the
client, e.g., because it is in a different cluster which does not
share state or because the ticket has been deleted as described in
Section 8.1. If the application-layer protocol retransmits data in
this setting, then it is possible for an attacker to induce message
duplication by sending the ClientHello to both the original cluster
(which processes the data immediately) and another cluster which will
fall back to 1-RTT and process the data upon application-layer
replay. The scale of this attack is limited by the client's
willingness to retry transactions and therefore only allows a limited
amount of duplication, with each copy appearing as a new connection
at the server.
If implemented correctly, the mechanisms described in Section 8.1 and
Section 8.2 prevent a replayed ClientHello and its associated 0-RTT
data from being accepted multiple times by any cluster with
consistent state; for servers which limit the use of 0-RTT to one
cluster for a single ticket, then a given ClientHello and its
associated 0-RTT data will only be accepted once. However, if state
is not completely consistent, then an attacker might be able to have
multiple copies of the data be accepted during the replication
window. Because clients do not know the exact details of server
behavior, they MUST NOT send messages in early data which are not
safe to have replayed and which they would not be willing to retry
across multiple 1-RTT connections.
Rescorla Expires 27 September 2023 [Page 147]
Internet-Draft TLS March 2023
Application protocols MUST NOT use 0-RTT data without a profile that
defines its use. That profile needs to identify which messages or
interactions are safe to use with 0-RTT and how to handle the
situation when the server rejects 0-RTT and falls back to 1-RTT.
In addition, to avoid accidental misuse, TLS implementations MUST NOT
enable 0-RTT (either sending or accepting) unless specifically
requested by the application and MUST NOT automatically resend 0-RTT
data if it is rejected by the server unless instructed by the
application. Server-side applications may wish to implement special
processing for 0-RTT data for some kinds of application traffic
(e.g., abort the connection, request that data be resent at the
application layer, or delay processing until the handshake
completes). In order to allow applications to implement this kind of
processing, TLS implementations MUST provide a way for the
application to determine if the handshake has completed.
F.5.1. Replay and Exporters
Replays of the ClientHello produce the same early exporter, thus
requiring additional care by applications which use these exporters.
In particular, if these exporters are used as an authentication
channel binding (e.g., by signing the output of the exporter) an
attacker who compromises the PSK can transplant authenticators
between connections without compromising the authentication key.
In addition, the early exporter SHOULD NOT be used to generate
server-to-client encryption keys because that would entail the reuse
of those keys. This parallels the use of the early application
traffic keys only in the client-to-server direction.
F.6. PSK Identity Exposure
Because implementations respond to an invalid PSK binder by aborting
the handshake, it may be possible for an attacker to verify whether a
given PSK identity is valid. Specifically, if a server accepts both
external-PSK and certificate-based handshakes, a valid PSK identity
will result in a failed handshake, whereas an invalid identity will
just be skipped and result in a successful certificate handshake.
Servers which solely support PSK handshakes may be able to resist
this form of attack by treating the cases where there is no valid PSK
identity and where there is an identity but it has an invalid binder
identically.
Rescorla Expires 27 September 2023 [Page 148]
Internet-Draft TLS March 2023
F.7. Sharing PSKs
TLS 1.3 takes a conservative approach to PSKs by binding them to a
specific KDF. By contrast, TLS 1.2 allows PSKs to be used with any
hash function and the TLS 1.2 PRF. Thus, any PSK which is used with
both TLS 1.2 and TLS 1.3 must be used with only one hash in TLS 1.3,
which is less than optimal if users want to provision a single PSK.
The constructions in TLS 1.2 and TLS 1.3 are different, although they
are both based on HMAC. While there is no known way in which the
same PSK might produce related output in both versions, only limited
analysis has been done. Implementations can ensure safety from
cross-protocol related output by not reusing PSKs between TLS 1.3 and
TLS 1.2.
F.8. Attacks on Static RSA
Although TLS 1.3 does not use RSA key transport and so is not
directly susceptible to Bleichenbacher-type attacks [Blei98]if TLS
1.3 servers also support static RSA in the context of previous
versions of TLS, then it may be possible to impersonate the server
for TLS 1.3 connections [JSS15]. TLS 1.3 implementations can prevent
this attack by disabling support for static RSA across all versions
of TLS. In principle, implementations might also be able to separate
certificates with different keyUsage bits for static RSA decryption
and RSA signature, but this technique relies on clients refusing to
accept signatures using keys in certificates that do not have the
digitalSignature bit set, and many clients do not enforce this
restriction.
Appendix G. Change Log
[[RFC EDITOR: Please remove in final RFC.]] Since -06 - Updated text
about differences from RFC 8446. - Clarify which parts of IANA
considerations are new to this document. - Upgrade the requirement to
initiate key update before exceeding key usage limits to MUST. - Add
some text around use of the same cert for client and server.
Since -05
* Port in text on key update limits from RFC 9147 (Issue 1257)
* Clarify that you need to ignore NST if you don't do resumption
(Issue 1280)
* Discuss the privacy implications of external key reuse (Issue
1287)
* Advice on key deletion (PR 1282)
Rescorla Expires 27 September 2023 [Page 149]
Internet-Draft TLS March 2023
* Clarify what unsolicited extensions means (PR 1275)
* close_notify should be warning (PR 1290)
* Reference RFC 8773 (PR 1296)
* Add some more information about application bindings and cite
6125-bis (PR 1297)
Since -04
* Update the extension table (Issue 1241)
* Clarify user_canceled (Issue 1208)
* Clarify 0-RTT cache side channels (Issue 1225)
* Require that message reinjection be done with the current hash.
Potentially a clarification and potentially a wire format change
depending on previous interpretation (Issue 1227)
Changelog not updated between -00 and -03
Since -00
* Update TLS 1.2 terminology
* Specify "certificate-based" client authentication
* Clarify that privacy guarantees don't apply when you have null
encryption
* Shorten some names
* Address tracking implications of resumption
Contributors
Martin Abadi
University of California, Santa Cruz
abadi@cs.ucsc.edu
Christopher Allen
(co-editor of TLS 1.0)
Alacrity Ventures
ChristopherA@AlacrityManagement.com
Nimrod Aviram
Rescorla Expires 27 September 2023 [Page 150]
Internet-Draft TLS March 2023
Tel Aviv University
nimrod.aviram@gmail.com
Richard Barnes
Cisco
rlb@ipv.sx
Steven M. Bellovin
Columbia University
smb@cs.columbia.edu
David Benjamin
Google
davidben@google.com
Benjamin Beurdouche
INRIA & Microsoft Research
benjamin.beurdouche@ens.fr
Karthikeyan Bhargavan
(editor of [RFC7627])
INRIA
karthikeyan.bhargavan@inria.fr
Simon Blake-Wilson
(co-author of [RFC4492])
BCI
sblakewilson@bcisse.com
Nelson Bolyard
(co-author of [RFC4492])
Sun Microsystems, Inc.
nelson@bolyard.com
Ran Canetti
IBM
canetti@watson.ibm.com
Matt Caswell
OpenSSL
matt@openssl.org
Stephen Checkoway
University of Illinois at Chicago
sfc@uic.edu
Pete Chown
Skygate Technology Ltd
Rescorla Expires 27 September 2023 [Page 151]
Internet-Draft TLS March 2023
pc@skygate.co.uk
Katriel Cohn-Gordon
University of Oxford
me@katriel.co.uk
Cas Cremers
University of Oxford
cas.cremers@cs.ox.ac.uk
Antoine Delignat-Lavaud
(co-author of [RFC7627])
INRIA
antdl@microsoft.com
Tim Dierks
(co-author of TLS 1.0, co-editor of TLS 1.1 and 1.2)
Independent
tim@dierks.org
Roelof DuToit
Symantec Corporation
roelof_dutoit@symantec.com
Taher Elgamal
Securify
taher@securify.com
Pasi Eronen
Nokia
pasi.eronen@nokia.com
Cedric Fournet
Microsoft
fournet@microsoft.com
Anil Gangolli
anil@busybuddha.org
David M. Garrett
dave@nulldereference.com
Illya Gerasymchuk
Independent
illya@iluxonchik.me
Alessandro Ghedini
Cloudflare Inc.
Rescorla Expires 27 September 2023 [Page 152]
Internet-Draft TLS March 2023
alessandro@cloudflare.com
Daniel Kahn Gillmor
ACLU
dkg@fifthhorseman.net
Matthew Green
Johns Hopkins University
mgreen@cs.jhu.edu
Jens Guballa
ETAS
jens.guballa@etas.com
Felix Guenther
TU Darmstadt
mail@felixguenther.info
Vipul Gupta
(co-author of [RFC4492])
Sun Microsystems Laboratories
vipul.gupta@sun.com
Chris Hawk
(co-author of [RFC4492])
Corriente Networks LLC
chris@corriente.net
Kipp Hickman
Alfred Hoenes
David Hopwood
Independent Consultant
david.hopwood@blueyonder.co.uk
Marko Horvat
MPI-SWS
mhorvat@mpi-sws.org
Jonathan Hoyland
Royal Holloway, University of London
jonathan.hoyland@gmail.com
Subodh Iyengar
Facebook
subodh@fb.com
Rescorla Expires 27 September 2023 [Page 153]
Fleming & McDonald Informational [Page 49]
RFC 7612 LDAP Schema for Printer Services June 2015
10.2. Informative References
[BCP13] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, December 2005.
Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013.
<http://www.rfc-editor.org/info/bcp13>
[BCP18] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998,
<http://www.rfc-editor.org/info/bcp18>.
[BCP19] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000,
<http://www.rfc-editor.org/info/bcp19>.
[RFC1179] McLaughlin, L., "Line printer daemon protocol",
RFC 1179, DOI 10.17487/RFC1179, August 1990,
<http://www.rfc-editor.org/info/rfc1179>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951,
DOI 10.17487/RFC1951, May 1996,
<http://www.rfc-editor.org/info/rfc1951>.
[RFC1952] Deutsch, P., "GZIP file format specification
version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996,
<http://www.rfc-editor.org/info/rfc1952>.
[RFC1977] Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
DOI 10.17487/RFC1977, August 1996,
<http://www.rfc-editor.org/info/rfc1977>.
[RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers
(URIs)", RFC 2079, DOI 10.17487/RFC2079, January 1997,
<http://www.rfc-editor.org/info/rfc2079>.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and
P. Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, DOI 10.17487/RFC2566, April 1999,
<http://www.rfc-editor.org/info/rfc2566>.
Fleming & McDonald Informational [Page 50]
RFC 7612 LDAP Schema for Printer Services June 2015
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
DOI 10.17487/RFC2608, June 1999,
<http://www.rfc-editor.org/info/rfc2608>.
[RFC3712] Fleming, P. and I. McDonald, "Lightweight Directory
Access Protocol (LDAP): Schema for Printer Services",
RFC 3712, DOI 10.17487/RFC3712, February 2004,
<http://www.rfc-editor.org/info/rfc3712>.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<http://www.rfc-editor.org/info/rfc4559>.
[SLPPRT20] IANA, "Service Location Protocol, Version 2 (SLPv2)
Templates",
<http://www.iana.org/assignments/svrloc-templates>.
Fleming & McDonald Informational [Page 51]
RFC 7612 LDAP Schema for Printer Services June 2015
Appendix A. Changes since RFC 3712
1) Added many editorial corrections and clarifications
- corrected typos, missing words, and ambiguous sentences;
- replaced lowercase 'printer' with titlecase 'Printer' for
readability and consistency with IETF and IEEE-ISTO PWG IPP
standards usage;
- added implementation notes;
- updated and added references.
2) Deleted length restrictions from formal definitions of
DirectoryString syntax attributes
- replaced with notes recommending length restrictions for
compatibility with existing implementations of [RFC3712] and
underlying string length limits in [RFC2707], [RFC2911],
[RFC3805], [PWG5107.2], [PWG5100.13], and [PWG5100.14].
3) Added new Printer attributes defined in [PWG5107.2], [PWG5100.13],
and [PWG5100.14] (see Section 7.1)
- updated the table of Printer attributes and source documents in
Section 4 ("Definition of Attribute Types");
- added support for IEEE-ISTO PWG "IPP Everywhere" [PWG5100.14]
project.
4) Added implementation note to Section 4 about string encodings
- added discussion of 'List of xxx' and 'One of xxx' encodings;
- stated that any of these attributes can be represented as
multiple instances (i.e., to avoid length overflow).
5) Improved comma-delimited examples of string attributes
- added both single-valued and multi-valued examples.
Fleming & McDonald Informational [Page 52]
RFC 7612 LDAP Schema for Printer Services June 2015
6) Clarified use of printer-xri-supported and
printer-resolution-supported attributes, and their corresponding
field delimiters
- added note in Section 4 ("Definition of Attribute Types") to
explain the origin of the different field delimiters;
- added examples to show optional *trailing* whitespace after '<'
delimiters in printer-xri-supported;
- added examples to show optional *trailing* whitespace after '>'
delimiters in printer-resolution-supported.
7) Clarified Section 8 ("Internationalization Considerations")
- added note about Net-Unicode [RFC5198] and avoiding use of C0
and C1 control characters.
8) Clarified Section 9 ("Security Considerations")
- added note about security vulnerabilities caused by use of DEL
or any C0 or C1 control characters in names.
9) Clarified terms and abbreviations
- renamed Section 2 ("Conventions Used in This Document");
- added Section 2.1 ("Requirements Language");
- added Section 2.2 ("LDAP Schema Descriptions");
- added Section 2.3 ("Abbreviations").
Internet-Draft TLS March 2023
Benjamin Kaduk
Akamai Technologies
kaduk@mit.edu
Hubert Kario
Red Hat Inc.
hkario@redhat.com
Phil Karlton
(co-author of SSL 3.0)
Leon Klingele
Independent
mail@leonklingele.de
Paul Kocher
(co-author of SSL 3.0)
Cryptography Research
paul@cryptography.com
Hugo Krawczyk
IBM
hugokraw@us.ibm.com
Adam Langley
(co-author of [RFC7627])
Google
agl@google.com
Olivier Levillain
ANSSI
olivier.levillain@ssi.gouv.fr
Xiaoyin Liu
University of North Carolina at Chapel Hill
xiaoyin.l@outlook.com
Ilari Liusvaara
Independent
ilariliusvaara@welho.com
Atul Luykx
K.U. Leuven
atul.luykx@kuleuven.be
Colm MacCarthaigh
Amazon Web Services
colm@allcosts.net
Rescorla Expires 27 September 2023 [Page 154]
Internet-Draft TLS March 2023
Carl Mehner
USAA
carl.mehner@usaa.com
Jan Mikkelsen
Transactionware
janm@transactionware.com
Bodo Moeller
(co-author of [RFC4492])
Google
bodo@acm.org
Kyle Nekritz
Facebook
knekritz@fb.com
Erik Nygren
Akamai Technologies
erik+ietf@nygren.org
Magnus Nystrom
Microsoft
mnystrom@microsoft.com
Kazuho Oku
DeNA Co., Ltd.
kazuhooku@gmail.com
Kenny Paterson
Royal Holloway, University of London
kenny.paterson@rhul.ac.uk
Christopher Patton
University of Florida
cjpatton@ufl.edu
Alfredo Pironti
(co-author of [RFC7627])
INRIA
alfredo.pironti@inria.fr
Andrei Popov
Microsoft
andrei.popov@microsoft.com
John {{{Preuß Mattsson}}}
Ericsson
Rescorla Expires 27 September 2023 [Page 155]
Internet-Draft TLS March 2023
john.mattsson@ericsson.com
Marsh Ray
(co-author of [RFC7627])
Microsoft
maray@microsoft.com
Robert Relyea
Netscape Communications
relyea@netscape.com
Kyle Rose
Akamai Technologies
krose@krose.org
Jim Roskind
Amazon
jroskind@amazon.com
Michael Sabin
Joe Salowey
Tableau Software
joe@salowey.net
Rich Salz
Akamai
rsalz@akamai.com
David Schinazi
Apple Inc.
dschinazi@apple.com
Sam Scott
Royal Holloway, University of London
me@samjs.co.uk
Thomas Shrimpton
University of Florida
teshrim@ufl.edu
Dan Simon
Microsoft, Inc.
dansimon@microsoft.com
Brian Smith
Independent
brian@briansmith.org
Rescorla Expires 27 September 2023 [Page 156]
Internet-Draft TLS March 2023
Ben Smyth
Ampersand
www.bensmyth.com
Brian Sniffen
Akamai Technologies
ietf@bts.evenmere.org
Nick Sullivan
Cloudflare Inc.
nick@cloudflare.com
Bjoern Tackmann
University of California, San Diego
btackmann@eng.ucsd.edu
Tim Taubert
Mozilla
ttaubert@mozilla.com
Martin Thomson
Mozilla
mt@mozilla.com
Hannes Tschofenig
Arm Limited
Hannes.Tschofenig@arm.com
Sean Turner
sn3rd
sean@sn3rd.com
Steven Valdez
Google
svaldez@google.com
Filippo Valsorda
Cloudflare Inc.
filippo@cloudflare.com
Thyla van der Merwe
Royal Holloway, University of London
tjvdmerwe@gmail.com
Victor Vasiliev
Google
vasilvv@google.com
Rescorla Expires 27 September 2023 [Page 157]
Internet-Draft TLS March 2023
Hoeteck Wee
Ecole Normale Superieure, Paris
hoeteck@alum.mit.edu
Tom Weinstein
David Wong
NCC Group
david.wong@nccgroup.trust
Christopher A. Wood
Apple Inc.
cawood@apple.com
Tim Wright
Vodafone
timothy.wright@vodafone.com
Peter Wu
Independent
peter@lekensteyn.nl
Kazu Yamamoto
Internet Initiative Japan Inc.
kazu@iij.ad.jp
Author's Address
Eric Rescorla
Mozilla
Email: ekr@rtfm.com
Rescorla Expires 27 September 2023 [Page 158]