draft-ietf-tls-cached-info-21.txt   draft-ietf-tls-cached-info-22.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: June 23, 2016 ARM Ltd. Expires: July 29, 2016 ARM Ltd.
December 21, 2015 January 26, 2016
Transport Layer Security (TLS) Cached Information Extension Transport Layer Security (TLS) Cached Information Extension
draft-ietf-tls-cached-info-21.txt draft-ietf-tls-cached-info-22.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 June 23, 2016. This Internet-Draft will expire on July 29, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
This document refers to the TLS protocol but the description is This document refers to the TLS protocol but the description is
equally applicable to DTLS as well. equally applicable to DTLS as well.
3. Cached Information Extension 3. Cached Information Extension
This document defines a new extension type (cached_info(TBD)), which This document defines a new extension type (cached_info(TBD)), which
is used in client hello and server hello messages. The extension is used in client hello and server hello messages. The extension
type is specified as follows. type is specified as follows.
enum { enum {
cached_info(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. The client hello, MUST contain the CachedInformation structure. The
client MAY send multiple CachedObjects of the same client MAY send multiple CachedObjects of the same
CachedInformationType. This may, for example, be the case when the CachedInformationType. This may, for example, be the case when the
client has cached multiple certificates from a server. client has cached multiple certificates from a server.
enum { enum {
cert(1), cert_req(2) (255) cert(1), cert_req(2) (255)
} CachedInformationType; } CachedInformationType;
struct { struct {
select (type) { select (type) {
case client: case client:
CachedInformationType type; CachedInformationType type;
opaque hash_value<1..255>; opaque hash_value[4];
case server: case server:
CachedInformationType type; CachedInformationType type;
} body; };
} CachedObject; } CachedObject;
struct { struct {
CachedObject cached_info<1..2^8-1>; CachedObject cached_info<1..255>;
} CachedInformation; } CachedInformation;
This document defines the following two types: This document defines the following two types:
'cert' Type for not sending the complete Server Certificate Message: 'cert' Type for not sending the complete Server Certificate Message:
With the type field set to 'cert', the client MUST include the With the type field set to 'cert', the client MUST include the
fingerprint of the Certificate message in the hash_value field. fingerprint of the Certificate message in the hash_value field.
For this type the fingerprint MUST be calculated using the For this type the fingerprint MUST be calculated using the
procedure described in Section 5 with the Certificate message as procedure described in Section 5 with the Certificate message as
input data. input data.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
'cert_req' Type for not sending the complete CertificateRequest 'cert_req' Type for not sending the complete CertificateRequest
Message: Message:
With the type set to 'cert_req', the client MUST include the With the type set to 'cert_req', the client MUST include the
fingerprint of the CertificateRequest message in the hash_value fingerprint of the CertificateRequest message in the hash_value
field. For this type the fingerprint MUST be calculated using the field. For this type the fingerprint MUST be calculated using the
procedure described in Section 5 with the CertificateRequest procedure described in Section 5 with the CertificateRequest
message as input data. message as input data.
New cached info types can be added following the policy described in New cached info types can be added following the policy described in
the IANA considerations section, see Section 8. New message digest the IANA considerations section, see Section 8. New hash algorithms
algorithms for use with these types can also be added by registering can also be added by registering a new type. For practical reasons
a new type that makes use of the updated message digest algorithm. we recommend to re-use hash algorithms already available with TLS
There are no specific requirements for the use of specific hash ciphersuites to avoid additional code and to keep the collision
algorithms but for practical reason it is useful to re-use algorithms probably low new hash algorithms MUST NOT have a collision resistance
already available with TLS ciphersuites to avoid additional code and worse than SHA-256 when truncated to 4 bytes.
to keep the collision probably low.
4. Exchange Specification 4. Exchange Specification
Clients supporting this extension MAY include the "cached_info" Clients supporting this extension MAY include the "cached_info"
extension in the (extended) client hello. If the client includes the extension in the (extended) client hello. If the client includes the
extension then it MUST contain one or more CachedObject attributes. extension then it MUST contain one or more CachedObject attributes.
A server supporting this extension MAY include the "cached_info" A server supporting this extension MAY include the "cached_info"
extension in the (extended) server hello. By returning the extension in the (extended) server hello. By returning the
"cached_info" extension the server indicates that it supports the "cached_info" extension the server indicates that it supports the
skipping to change at page 6, line 35 skipping to change at page 6, line 35
Note: We assume that the server implementation is able to select the Note: We assume that the server implementation is able to select the
appropriate certificate or SubjectPublicKeyInfo from the received appropriate certificate or SubjectPublicKeyInfo from the received
hash value. If the SNI extension is used by the client then the hash value. If the SNI extension is used by the client then the
server has additional information to guide the selection of the server has additional information to guide the selection of the
appropriate cached info. appropriate cached info.
When the cached info specification is used then a modified version of When the cached info specification is used then a modified version of
the Certificate message is exchanged. The modified structure is the Certificate message is exchanged. The modified structure is
shown in Figure 1. shown in Figure 1.
struct { struct {
opaque hash_value[1..255]; opaque hash_value[4];
} Certificate; } Certificate;
Figure 1: Cached Info Certificate Message. Figure 1: Cached Info Certificate Message.
4.2. CertificateRequest Message 4.2. CertificateRequest Message
When a fingerprint for an object of type 'cert_req' is provided in When a fingerprint for an object of type 'cert_req' is provided in
the client hello, the server MAY send the CertificateRequest message the client hello, the server MAY send the CertificateRequest message
shown in Figure 2 message under the following conditions: shown in Figure 2 message under the following conditions:
o The server software implements the "cached_info" extension defined o The server software implements the "cached_info" extension defined
skipping to change at page 7, line 18 skipping to change at page 7, line 18
check ensures that the information cached by the client is check ensures that the information cached by the client is
current. The procedure for calculating the fingerprint is current. The procedure for calculating the fingerprint is
described in Section 5. described in Section 5.
o The server wants to request a certificate from the client. o The server wants to request a certificate from the client.
The original CertificateRequest handshake message syntax is defined The original CertificateRequest handshake message syntax is defined
in [RFC5246]. The modified structure of the CertificateRequest in [RFC5246]. The modified structure of the CertificateRequest
message is shown in Figure 2. message is shown in Figure 2.
struct { struct {
opaque hash_value<1..255>; opaque hash_value[4];
} CertificateRequest; } CertificateRequest;
Figure 2: Cached Info CertificateRequest Message. Figure 2: Cached Info CertificateRequest Message.
The CertificateRequest payload is the input parameter to the The CertificateRequest payload is the input parameter to the
fingerprint calculation described in Section 5. fingerprint calculation described in Section 5.
5. Fingerprint Calculation 5. Fingerprint Calculation
The fingerprint MUST be computed as follows: The fingerprint MUST be computed as follows:
skipping to change at page 11, line 27 skipping to change at page 11, line 27
o Ilari Liusvaara, Adam Langley, and Eric Rescorla (July 2014) o Ilari Liusvaara, Adam Langley, and Eric Rescorla (July 2014)
o Sean Turner (August 2014) o Sean Turner (August 2014)
o Martin Thomson (August 2015) o Martin Thomson (August 2015)
o Jouni Korhonen (November 2015) o Jouni Korhonen (November 2015)
o Matt Miller (December 2015) o Matt Miller (December 2015)
o Dave Garrett (December 2015)
We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp
Bagaria and Eric Rescorla for their feedback regarding the Bagaria and Eric Rescorla for their feedback regarding the
fingerprint calculation. fingerprint calculation.
Finally, we would like to thank the TLS working group chairs, Sean Finally, we would like to thank the TLS working group chairs, Sean
Turner and Joe Salowey, as well as the responsible security area Turner and Joe Salowey, as well as the responsible security area
director, Stephen Farrell, for their support and their reviews. director, Stephen Farrell, for their support and their reviews.
10. References 10. References
skipping to change at page 17, line 47 skipping to change at page 17, line 47
9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54
2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42
49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45
Figure 7: Hex Encoding of the Example Certificate. Figure 7: Hex Encoding of the Example Certificate.
Applying the SHA-256 hash function to the Certificate message, which Applying the SHA-256 hash function to the Certificate message, which
is starts with 0b 00 02 and ends with 9E 57 45, produces is starts with 0b 00 02 and ends with 9E 57 45, produces
0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af. 0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af.
Subsequently, this output is truncated to 32 bits, which leads to a Subsequently, this output is truncated to 32 bits, which leads to a
fingerpint of 0x086eefb4. fingerprint of 0x086eefb4.
Authors' Addresses 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
 End of changes. 13 change blocks. 
37 lines changed or deleted 38 lines changed or added

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