Diff: draft-zhang-trans-ct-dnssec-01.txt - draft-zhang-trans-ct-dnssec-02.txt

	< draft-zhang-trans-ct-dnssec-01.txt	draft-zhang-trans-ct-dnssec-02.txt >

	Network Working Group D. Zhang	Network Working Group D. Zhang

	Internet-Draft Huawei	Internet-Draft
	Intended status: Experimental D. Gillmor	Intended status: Experimental D. Gillmor

	Expires: June 26, 2015 CMRG	Expires: November 6, 2015 CMRG
	D. He	D. He
	Huawei	Huawei

	December 23, 2014	B. Sarikaya
		Huawei USA
		May 5, 2015

	Certificate Transparency for Domain Name System Security Extensions	Certificate Transparency for Domain Name System Security Extensions

	draft-zhang-trans-ct-dnssec-01	draft-zhang-trans-ct-dnssec-02

	Abstract	Abstract

	In draft-ietf-trans-rfc6962-bis, a solution is proposed for publicly	In draft-ietf-trans-rfc6962-bis, a solution is proposed for publicly
	logging the existence of Transport Layer Security (TLS) certificates	logging the existence of Transport Layer Security (TLS) certificates
	using Merkle Hash Trees. This document tries to use this idea in	using Merkle Hash Trees. This document tries to use this idea in
	DNSSEC and publicly logging the DS RRs in order to notice the	DNSSEC and publicly logging the DS RRs in order to notice the
	issuance of suspect key signing keys.	issuance of suspect key signing keys.

	Requirements Language	Requirements Language

	skipping to change at page 1, line 43 ¶	skipping to change at page 1, line 45 ¶
	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 26, 2015.	This Internet-Draft will expire on November 6, 2015.

	Copyright Notice	Copyright Notice


	Copyright (c) 2014 IETF Trust and the persons identified as the	Copyright (c) 2015 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
	described in the Simplified BSD License.	described in the Simplified BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Cryptographic Components of Certificate Transparency . . . . 4	2. Cryptographic Components of Certificate Transparency . . . . 4
	3. Motivation Scenario . . . . . . . . . . . . . . . . . . . . . 4	3. Motivation Scenario . . . . . . . . . . . . . . . . . . . . . 4
	4. Log Format and Operation . . . . . . . . . . . . . . . . . . 5	4. Log Format and Operation . . . . . . . . . . . . . . . . . . 5
	4.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 5	4.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 5

	4.2. Structure of the Signed Certificate Timestamp . . . . . . 6	4.2. Structure of the Signed Certificate Timestamp . . . . . . 7
	4.3. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 8	4.3. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Including the Signed Certificate Timestamp into DNS Security	5. Including the Signed Certificate Timestamp into DNS Security

	Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 8	Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. SCT RR . . . . . . . . . . . . . . . . . . . . . . . . . 9	5.1. SCT RR . . . . . . . . . . . . . . . . . . . . . . . . . 9

	5.1.1. The Key Tag Field . . . . . . . . . . . . . . . . . . 9	5.1.1. The Key Tag Field . . . . . . . . . . . . . . . . . . 10
	5.1.2. The Algorithm Field . . . . . . . . . . . . . . . . . 9	5.1.2. The Algorithm Field . . . . . . . . . . . . . . . . . 10
	5.1.3. The Digest Type Field . . . . . . . . . . . . . . . . 10	5.1.3. The Digest Type Field . . . . . . . . . . . . . . . . 10
	5.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 10	5.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 10
	5.1.5. The SCT Field . . . . . . . . . . . . . . . . . . . . 10	5.1.5. The SCT Field . . . . . . . . . . . . . . . . . . . . 10

	5.1.6. The Signature Field . . . . . . . . . . . . . . . . . 10	5.1.6. The Signature Field . . . . . . . . . . . . . . . . . 11
	5.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 10	5.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 10	6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 11
	6.1. Add DNSSEC RR Chain to Log . . . . . . . . . . . . . . . 10	6.1. Add DNSSEC RR Chain to Log . . . . . . . . . . . . . . . 11
	6.2. Retrieve Accepted Root DNSKEY RRs . . . . . . . . . . . . 11	6.2. Retrieve Accepted Root DNSKEY RRs . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8.1. Logging other types of RRs . . . . . . . . . . . . . . . 11	8.1. Logging other types of RRs . . . . . . . . . . . . . . . 12
	8.2. Scalability Concerns . . . . . . . . . . . . . . . . . . 12	8.2. Scalability Concerns . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	10. Normative References . . . . . . . . . . . . . . . . . . . . 12	10. Normative References . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13

	1. Introduction	1. Introduction

	[I-D.ietf-trans-rfc6962-bis] specifies a Certificate Transparency	[I-D.ietf-trans-rfc6962-bis] specifies a Certificate Transparency
	(CT) mechanism to disclosing TLS certificates into public logs so as	(CT) mechanism to disclosing TLS certificates into public logs so as
	to benefit the public to monitor the operations in issuing	to benefit the public to monitor the operations in issuing
	certificates to improper subscribers. The logs do not prevent mis-	certificates to improper subscribers. The logs do not prevent mis-
	issuing behavior directly, but the provided public audibility can	issuing behavior directly, but the provided public audibility can
	increase the possibility in detecting the improper behaviors of	increase the possibility in detecting the improper behaviors of

	skipping to change at page 12, line 26 ¶	skipping to change at page 13, line 17 ¶
	The log MAY limit accepting entries where the TTL is too short or the	The log MAY limit accepting entries where the TTL is too short or the
	RRSIG times are too far in the future or the past, to avoid spamming	RRSIG times are too far in the future or the past, to avoid spamming
	the log. It should probably also put a maximum on the number of	the log. It should probably also put a maximum on the number of
	child zones to avoid getting spammed.	child zones to avoid getting spammed.

	9. Acknowledgements	9. Acknowledgements

	10. Normative References	10. Normative References

	[I-D.ietf-trans-rfc6962-bis]	[I-D.ietf-trans-rfc6962-bis]

	Laurie, B., Langley, A., Kasper, E., and R. Stradling,	Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
	"Certificate Transparency", draft-ietf-trans-	Stradling, "Certificate Transparency", draft-ietf-trans-
	rfc6962-bis-04 (work in progress), July 2014.	rfc6962-bis-07 (work in progress), March 2015.

	[RFC1035] Mockapetris, P., "Domain names - implementation and	[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.	specification", STD 13, RFC 1035, November 1987.

	[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security	[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
	Extensions", RFC 2065, January 1997.	Extensions", RFC 2065, January 1997.

	[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.


	skipping to change at page 13, line 11 ¶	skipping to change at page 13, line 49 ¶
	[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation	[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation
	Requirements for Encapsulating Security Payload (ESP) and	Requirements for Encapsulating Security Payload (ESP) and
	Authentication Header (AH)", RFC 4305, December 2005.	Authentication Header (AH)", RFC 4305, December 2005.

	[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.

	Authors' Addresses	Authors' Addresses

	Dacheng Zhang	Dacheng Zhang

	Huawei

	Email: zhangdacheng@huawei.com


		Email: dacheng.zhang@gmail.com
	Daniel Kahn Gillmor	Daniel Kahn Gillmor
	CMRG	CMRG

	Email: dkg@fifthhorseman.net	Email: dkg@fifthhorseman.net

	Danping He	Danping He
	Huawei	Huawei

	Email: ana.hedanping@huawei.com	Email: ana.hedanping@huawei.com


		Behcet Sarikaya
		Huawei USA
		5340 Legacy Dr. Building 3
		Plano, TX 75024

		Email: sarikaya@ieee.org

End of changes. 15 change blocks.
	28 lines changed or deleted	28 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/