draft-ietf-tls-cached-info-16.txt   draft-ietf-tls-cached-info-17.txt 
TLS S. Santesson TLS S. Santesson
Internet-Draft 3xA Security AB Internet-Draft 3xA Security AB
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: August 18, 2014 ARM Ltd. Expires: May 17, 2015 ARM Ltd.
February 14, 2014 November 13, 2014
Transport Layer Security (TLS) Cached Information Extension Transport Layer Security (TLS) Cached Information Extension
draft-ietf-tls-cached-info-16.txt draft-ietf-tls-cached-info-17.txt
Abstract Abstract
Transport Layer Security (TLS) handshakes often include fairly static Transport Layer Security (TLS) handshakes often include fairly static
information, such as the server certificate and a list of trusted information, such as the server certificate and a list of trusted
Certification Authorities (CAs). This information can be of Certification Authorities (CAs). This information can be of
considerable size, particularly if the server certificate is bundled considerable size, particularly if the server certificate is bundled
with a complete certificate chain (i.e., the certificates of with a complete certificate chain (i.e., the certificates of
intermediate CAs up to the root CA). intermediate CAs up to the root CA).
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014. This Internet-Draft will expire on May 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Cached Information Extension . . . . . . . . . . . . . . . . 3 3. Cached Information Extension . . . . . . . . . . . . . . . . 3
4. Exchange Specification . . . . . . . . . . . . . . . . . . . 4 3.1. Certificate_list Fingerprint . . . . . . . . . . . . . . 4
4.1. Omitting the Certificate Chain . . . . . . . . . . . . . 5 3.2. Certificate_authorities Fingerprint . . . . . . . . . . . 4
4.2. Omitting the Trusted CAs . . . . . . . . . . . . . . . . 5 3.3. Fingerprint Hash Algorithm . . . . . . . . . . . . . . . 4
4. Exchange Specification . . . . . . . . . . . . . . . . . . . 5
4.1. Omitting the Certificate List . . . . . . . . . . . . . . 5
4.2. Omitting the Trusted Certificate Authorities . . . . . . 6
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 8 7.1. New Entry to the TLS ExtensionType Registry . . . . . . . 9
7.2. New Registry for CachedInformationType . . . . . . . . . 8 7.2. New Registry for CachedInformationType . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Transport Layer Security (TLS) handshakes often include fairly static Reducing the amount of information exchanged during a Transport Layer
information, such as the server certificate and a list of trusted Security handshake to a minimum helps to improve performance in
Certification Authorities (CAs). This information can be of environments where devices are connected to a network with a low
considerable size, particularly if the server certificate is bundled bandwidth, and lossy radio technology. With Internet of Things such
with a complete certificate chain (i.e., the certificates of
intermediate CAs up to the root CA).
Optimizing the exchange of information to a minimum helps to improve
performance in environments where devices are connected to a network
with a low bandwidth, and lossy radio technology. These types of
environments exist, for example, when smart objects are connected environments exist, for example, when smart objects are connected
using a low power IEEE 802.15.4 radio or via Bluetooth Low Energy. using a low power IEEE 802.15.4 radio or via Bluetooth Smart. For
For more information about the challenges with smart object more information about the challenges with smart object deployments
deployments please see [RFC6574]. please see [RFC6574].
This specification defines a TLS extension that allows a client and a This specification defines a TLS extension that allows a client and a
server to exclude transmission of cached information from the TLS server to exclude transmission information cached in an earlier TLS
handshake. handshake.
A typical example exchange may therefore look as follows. First, the A typical example exchange may therefore look as follows. First, the
client and the server executes the usual TLS handshake. The client client and the server executes the usual TLS handshake. The client
may, for example, decide to cache the certificate provided by the may, for example, decide to cache the certificate provided by the
server. When the TLS client connects to the TLS server some time in server. When the TLS client connects to the TLS server some time in
the future, without using session resumption, it then attaches the the future, without using session resumption, it then attaches the
cached_information extension defined in this document to the client cached_info extension defined in this document to the client hello
hello message to indicate that it had cached the certificate, and it message to indicate that it had cached the certificate, and it
provides the fingerprint of it. If the server's certificate had not provides the fingerprint of it. If the server's certificate has not
changed then the TLS server does not need to send the complete changed then the TLS server does not need to send its' certificate
certificate chain to the client again. In case the information had and the corresponding certificate list again. In case information
changed, the certificate payload is transmitted to the client to has changed, which can be seen from the fingerprint provided by the
allow the client to update its state information. client, the certificate payload is transmitted to the client to allow
the client to update the cache.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document refers to the TLS protocol but the description is
equally applicable to DTLS as well.
3. Cached Information Extension 3. Cached Information Extension
This document defines a new extension type (cached_information(TBD)), This document defines a new extension type (cached_info(TBD)), which
which is used in client hello and server hello messages. The is used in client hello and server hello messages. The extension
extension type is specified as follows. type is specified as follows.
enum { enum {
cached_information(TBD), (65535) cached_info(TBD), (65535)
} ExtensionType; } ExtensionType;
The extension_data field of this extension, when included in the The extension_data field of this extension, when included in the
client hello, MUST contain the CachedInformation structure. client hello, MUST contain the CachedInformation structure. The
client MUST NOT send multiple CachedObjects with the same
CachedInformationType.
enum { enum {
certificate_chain(1), trusted_cas(2) (255) certificate_list(1), certificate_authorities(2) (255)
} CachedInformationType; } CachedInformationType;
struct { struct {
CachedInformationType type; select (type) {
HashAlgorithm hash; case client:
opaque hash_value<1..255>; CachedInformationType type;
HashAlgorithm hash;
opaque hash_value<1..255>;
case server:
CachedInformationType type;
} body;
} CachedObject; } CachedObject;
struct { struct {
CachedObject cached_info<1..2^16-1>; CachedObject cached_info<1..2^16-1>;
} CachedInformation; } CachedInformation;
When the CachedInformationType identifies a certificate_chain, then This document establishes a registry for CachedInformationType types;
additional values can be added following the policy described in
Section 7.
3.1. Certificate_list Fingerprint
When the CachedInformationType identifies a certificate_list, then
the hash_value field MUST include the hash calculated over the the hash_value field MUST include the hash calculated over the
certificate_list element of the Certificate payload provided by the certificate_list element of the Certificate payload provided by the
TLS server in an earlier exchange, excluding the three length bytes TLS server in an earlier exchange, excluding the three length bytes
of the certificate_list vector. of the certificate_list vector.
When the CachedInformationType identifies a trusted_cas, then the 3.2. Certificate_authorities Fingerprint
hash_value MUST include a hash calculated over the
certificate_authorities element of the CertificateRequest payload When the CachedInformationType identifies a certificate_authorities,
provided by the TLS server in an earlier exchange, excluding the two then the hash_value MUST include a hash calculated over
length bytes of the certificate_authorities vector. CertificateRequest payload provided by the TLS server in an earlier
exchange, excluding the msg_type and length field.
3.3. Fingerprint Hash Algorithm
The hash algorithm used to calculate hash values is conveyed in the The hash algorithm used to calculate hash values is conveyed in the
'hash' field of the CachedObject element. The list of registered 'hash' field of the CachedObject element. The list of registered
hash algorithms can be found in the TLS HashAlgorithm Registry, which hash algorithms can be found in the TLS HashAlgorithm Registry, which
was created by RFC 5246 [RFC5246]. The value zero (0) for 'none' is was created by RFC 5246 [RFC5246]. The value zero (0) for 'none' and
not an allowed choice for a hash algorithm and MUST NOT be used. one (1) for 'md5' is not an allowed choice for a hash algorithm and
MUST NOT be used.
This document establishes a registry for CachedInformationType types
and additional values can be added following the policy described in
Section 7.
4. Exchange Specification 4. Exchange Specification
Clients supporting this extension MAY include the Clients supporting this extension MAY include the "cached_info"
"cached_information" extension in the (extended) client hello, which extension in the (extended) client hello. If the client includes the
MAY contain zero or more CachedObject attributes. extension then it MUST contain one or more CachedObject attributes.
Clients and servers MUST NOT include more than one CachedObject
attribute per info type.
A server supporting this extension MAY include the A server supporting this extension MAY include the "cached_info"
"cached_information" extension in the (extended) server hello, which extension in the (extended) server hello. By returning the
MAY contain one or more CachedObject attributes it supports. By "cached_info" extension the server indicates that it supports the
returning the "cached_information" extension the server indicates cached info types. For each indicated cached info type the server
that it supports caching of each present CachedObject that matches MUST alters the transmission of respective payloads, as specified for
the specified hash value. The server MAY support other cached each type. If the server includes the extension it MUST only include
objects that are not present in the extension. CachedObjects of a type also supported by the client (as expressed in
the client hello).
Note: If clients make use of the Server Name Indication [RFC6066] Note that the client includes a fingerprint of the cached information
then clients may need to cache multiple data items for a single to give the server enough information to determine whether cached
server since servers may host multiple 'virtual' servers at a single information is stale. If the server supports this specification and
underlying network address. notices a mismatch between the data cached by the client and its own
information then the server MUST include the information in full and
MUST NOT list the respective item in the "cached_info" extension.
Following a successful exchange of the "cached_information" Note: Clients may cache multiple data items for a single server if
extensions in the client and server hello, the server omits sending those servers are part of a hosting environment. To allow the client
the corresponding handshake message. How information is omitted from to select the appropriate information from the cached it is
the handshake message is defined per cached info type. Section 4.1 RECOMMENDED that the client uses information from the Server Name
and Section 4.2 defines the syntax of the fingerprinted information. Indication [RFC6066].
The handshake protocol MUST proceed using the information as if it Following a successful exchange of the "cached_info" extensions in
was provided in the handshake protocol. The Finished message MUST be the client and server hello, the server alters sending the
calculated over the actual data exchanged in the handshake protocol. corresponding handshake message. How information is altered from the
That is, the Finished message will be calculated over the information handshake messages is defined per cached info type. Section 4.1 and
that was omitted from transmission by means of its present hash in Section 4.2 defines the syntax of the fingerprinted information.
the client hello and not through its presence in the handshake
exchange.
The server MUST NOT include more than one fingerprint for a single The handshake protocol MUST proceed using the information as if it
information element, i.e., at maximum only one CachedObject structure was provided in the handshake protocol. Since the Finished message
per replaced information is provided. is calculated over the exchanged data it will also include the hash
of the cached data.
4.1. Omitting the Certificate Chain 4.1. Omitting the Certificate List
When an object of type 'certificate_chain' is provided in the client When an object of type 'certificate_list' is provided in the client
hello, the server MAY replace the sequence of certificates with an hello, the server MAY replace the list of certificates with an empty
empty sequence with an actual length field of zero (=empty vector). sequence with an actual length field of zero (=empty vector).
The original handshake message syntax is defined in RFC 5246 The original handshake message syntax is defined in RFC 5246
[RFC5246] and has the following structure: [RFC5246] and has the following structure:
opaque ASN.1Cert<1..2^24-1>; opaque ASN.1Cert<1..2^24-1>;
struct { struct {
ASN.1Cert certificate_list<0..2^24-1>; ASN.1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
Note that [I-D.ietf-tls-oob-pubkey] allows the certificate payload to Note that [RFC7250] allows the certificate payload to contain only
contain only the SubjectPublicKeyInfo instead of the full information the SubjectPublicKeyInfo instead of the full information typically
typically found in a certificate. Hence, when this specification is found in a certificate. Hence, when this specification is used in
used in combination with [I-D.ietf-tls-oob-pubkey] and the negotiated combination with [RFC7250] and the negotiated certificate type is a
certificate type is a raw public key then the TLS server omits raw public key then the TLS server omits sending a Certificate
sending a Certificate payload that contains an ASN.1Cert structure of payload that contains an ASN.1Cert structure of the
the SubjectPublicKeyInfo. SubjectPublicKeyInfo.
4.2. Omitting the Trusted CAs 4.2. Omitting the Trusted Certificate Authorities
When a fingerprint for an object of type 'trusted_cas' is provided in When a fingerprint for an object of type 'certificate_authorities' is
the client hello, the server MAY send a DistinguishedName in the provided in the client hello, the server MAY replace the
Certificate Request message with an actual length field of zero CertificateRequest message with an empty sequence with an actual
(=empty vector). length field of zero.
The original handshake message syntax is defined in RFC 5246 The original handshake message syntax is defined in RFC 5246
[RFC5246] and has the following structure: [RFC5246] and has the following structure:
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>; supported_signature_algorithms<2^16-1>;
skipping to change at page 6, line 23 skipping to change at page 6, line 50
5. Example 5. Example
Figure 1 illustrates an example exchange using the TLS cached info Figure 1 illustrates an example exchange using the TLS cached info
extension. In the normal TLS handshake exchange shown in flow (A) extension. In the normal TLS handshake exchange shown in flow (A)
the TLS server provides its certificate in the Certificate payload to the TLS server provides its certificate in the Certificate payload to
the client, see step [1]. This allows the client to store the the client, see step [1]. This allows the client to store the
certificate for future use. After some time the TLS client again certificate for future use. After some time the TLS client again
interacts with the same TLS server and makes use of the TLS cached interacts with the same TLS server and makes use of the TLS cached
info extension, as shown in flow (B). The TLS client indicates info extension, as shown in flow (B). The TLS client indicates
support for this specification via the cached_information extension, support for this specification via the "cached_info" extension, see
see [2], and indicates that it has stored the certificate_chain from
the earlier exchange. With [3] the TLS server indicates that it also [2], and indicates that it has stored the 'certificate_list' from the
supports this specification and informs the client that it also earlier exchange. With [3] the TLS server acknowledges the supports
supports caching of other objects beyond the 'certificate_chain', of this specification and informs the client that it alterned the
namely 'trusted_cas' (also defined in this document), and the 'foo- content of the certificate payload (see [4], as described in
bar' extension (i.e., an imaginary extension that yet needs to be Section 4.1).
defined). With [4] the TLS server omits sending the certificate
chain, as described in Section 4.1.
(A) Initial (full) Exchange (A) Initial (full) Exchange
client_hello -> ClientHello ->
<- server_hello, <- ServerHello
certificate, // [1] Certificate* // [1]
server_key_exchange, ServerKeyExchange*
server_hello_done CertificateRequest*
ServerHelloDone
client_key_exchange, Certificate*
change_cipher_spec, ClientKeyExchange
finished -> CertificateVerify*
[ChangeCipherSpec]
Finished ->
<- change_cipher_spec, <- [ChangeCipherSpec]
finished Finished
Application Data <-------> Application Data Application Data <-------> Application Data
(B) TLS Cached Extension Usage (B) TLS Cached Extension Usage
client_hello, ClientHello
cached_information=(certificate_chain) -> // [2] cached_info=(certificate_list) -> // [2]
<- server_hello, <- ServerHello
cached_information= // [3] cached_info=
(certificate_chain, trusted_cas, foo-bar) (certificate_list) // [3]
certificate, // [4] Certificate* // [4]
server_key_exchange, ServerKeyExchange*
server_hello_done CertificateRequest*
ServerHelloDone
client_key_exchange, Certificate*
change_cipher_spec, ClientKeyExchange
finished -> CertificateVerify*
[ChangeCipherSpec]
Finished ->
<- change_cipher_spec, <- [ChangeCipherSpec]
finished Finished
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 1: Example Message Exchange Figure 1: Example Message Exchange
6. Security Considerations 6. Security Considerations
This specification defines a mechanism to reference stored state This specification defines a mechanism to reference stored state
using a fingerprint. Sending a fingerprint of cached information in using a fingerprint. Sending a fingerprint of cached information in
an unencrypted handshake, as the client and server hello is, may an unencrypted handshake, as the client and server hello is, may
allow an attacker or observer to correlate independent TLS exchanges. allow an attacker or observer to correlate independent TLS exchanges.
While some information elements used in this specification, such as While some information elements used in this specification, such as
server certificates, are public objects and usually not sensitive in server certificates, are public objects and usually not sensitive in
this regard, others may be. Those who implement and deploy this this regard, others may be. Those who implement and deploy this
specification should therefore make an informed decision whether the specification should therefore make an informed decision whether the
cached information is inline with their security and privacy goals. cached information is inline with their security and privacy goals.
In case of concerns, it is advised to avoid sending the fingerprint In case of concerns, it is advised to avoid sending the fingerprint
of the data objects in clear. of the data objects in clear.
The hash algorithm used in this specification is required to have The hash algorithm used in this specification is required to have
reasonable random properties in order to provide reasonably unique
identifiers. There is no requirement that this hash algorithm must
have strong collision resistance. have strong collision resistance.
7. IANA Considerations 7. IANA Considerations
7.1. New Entry to the TLS ExtensionType Registry 7.1. New Entry to the TLS ExtensionType Registry
IANA is requested to add an entry to the existing TLS ExtensionType IANA is requested to add an entry to the existing TLS ExtensionType
registry, defined in RFC 5246 [RFC5246], for cached_information(TBD) registry, defined in RFC 5246 [RFC5246], for cached_info(TBD) defined
defined in this document. in this document.
7.2. New Registry for CachedInformationType 7.2. New Registry for CachedInformationType
IANA is requested to establish a registry for TLS IANA is requested to establish a registry for TLS
CachedInformationType values. The first entries in the registry are CachedInformationType values. The first entries in the registry are
o certificate_chain(1) o certificate_list(1)
o trusted_cas(2) o certificate_authorities(2)
The policy for adding new values to this registry, following the The policy for adding new values to this registry, following the
terminology defined in RFC 5226 [RFC5226], is as follows: terminology defined in RFC 5226 [RFC5226], is as follows:
o 0-63 (decimal): Standards Action o 0-63 (decimal): Standards Action
o 64-223 (decimal): Specification Required o 64-223 (decimal): Specification Required
o 224-255 (decimal): reserved for Private Use o 224-255 (decimal): reserved for Private Use
8. Acknowledgments 8. Acknowledgments
We would like to thank the following persons for your detailed We would like to thank the following persons for your detailed
document reviews: document reviews:
o Paul Wouters and Nikos Mavrogiannopoulos (December 2011) o Paul Wouters and Nikos Mavrogiannopoulos (December 2011)
o Rob Stradling (February 2012) o Rob Stradling (February 2012)
o Ondrej Mikle (in March 2012) o Ondrej Mikle (in March 2012)
o Ilari Liusvaara, Adam Langley, and Eric Rescorla (in July 2014)
Additionally, we would like to thank the TLS working group chairs, Additionally, we would like to thank the TLS working group chairs,
Eric Rescorla and Joe Salowey, as well as the security area Sean Turner and Joe Salowey, as well as the responsible security area
directors, Sean Turner and Stephen Farrell, for their feedback and director, Stephen Farrell, for his support.
support.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224",
RFC 3874, September 2004. RFC 3874, September 2004.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
9.2. Informative References 9.2. Informative References
[I-D.ietf-tls-oob-pubkey]
Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
T. Kivinen, "Using Raw Public Keys in Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress),
January 2014.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object
Workshop", RFC 6574, April 2012. Workshop", RFC 6574, April 2012.
Authors' Addresses [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
T. Kivinen, "Using Raw Public Keys in Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7250, June 2014.
Authors' Addresses
Stefan Santesson Stefan Santesson
3xA Security AB 3xA Security AB
Scheelev. 17 Scheelev. 17
Lund 223 70 Lund 223 70
Sweden Sweden
Email: sts@aaa-sec.com Email: sts@aaa-sec.com
Hannes Tschofenig Hannes Tschofenig
ARM Ltd. ARM Ltd.
110 Fulbourn Rd Hall in Tirol 6060
Cambridge CB1 9NJ Austria
Great Britain
Email: Hannes.tschofenig@gmx.net Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 47 change blocks. 
155 lines changed or deleted 174 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/