Internet DRAFT - draft-pkupisie-dnsop-dprot
draft-pkupisie-dnsop-dprot
INTERNET-DRAFT Piotr Kupisiewicz
Intended Status: Proposed Standard (Cisco Systems)
Expires: June 14, 2016 February 1, 2016
DNS Extension to provide Default (Preferred) Protocol
draft-pkupisie-dnsop-dprot-01
Abstract
This document defines extension to the Domain Name System to support
Default Protocol. Default Protocol extension allows owners of the
resources to determine which are preferred protocols to be used with
their Services (i.e. https protocol to be preferred instead of http
for specific servers).
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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
Piotr Kupisiewicz Expires June 14, 2016 [Page 1]
INTERNET DRAFT DNS Extension to provide DPROT field February 1, 2016
(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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 State of Art . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 Application side implementation . . . . . . . . . . . . . . . 4
4.1 Application implementation: Various Service Types . . . . . 5
5 DNS Security Considerations . . . . . . . . . . . . . . . . . . 5
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Normative References . . . . . . . . . . . . . . . . . . . 5
5.2 Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Piotr Kupisiewicz Expires June 14, 2016 [Page 2]
INTERNET DRAFT DNS Extension to provide DPROT field February 1, 2016
1 Introduction
Currently applications are not able to determine what are default
protocols which are used for specific Internet hosts.
Taking Web Browser as an example: It is relying on user to choose
http [RFC2616] or https [RFC2818] during initial connection. If user
specifies http://rfc-editor.org initial connection will be done using
http on port 80, if user enters https://rfc-editor.org Browser will
use https as protocol on port 443.
However, If user does not specify protocol at all (i.e. puts in the
address bar of Web Browser rfc-editor.org instead of http://rfc-
editor.org or https://rfc-editor.org), application needs to decide
which protocol should be used. This is done based on local settings
(i.e. default configuration of Web Browser) and usually is not host-
specific. Most of current Web Browsers will use http:// as default
protocol (with some exceptios, see chapter 1.1 "State of Art")
If specific service i.e. Online Banking wants to recommend specific
protocol, it might use application layer protocol to redirect the
application to different protocol. For example if initial connection
is done to http://rfc-editor.org, there might be Redirect message
(HTTP 302) used to redirect Browser to https://rfc-editor.org
(alternatively html redirect might be used).
In that scenario redirect is done using non-secure connection (http),
which allows potential man-in-the-middle attacker to redirect user to
different webpage, or perform redirect using the same non-secure
protocol (http://rfc.org redirecting to http://rfc.org/index.html
instead of https://rfc.org/index.html).
Essentially applications are relying on user to choose proper
protocol. If user does not specify protocol applications need to
choose specific protocol (for user's convenience).
Aim of Default Protocol extension is to allow Service Owner i.e.
Online Banking Service to specific that for that specific host given
default protocol will be used. I.e. for rfc-editor.org default
protocol could say that default protocol is https, allowing browser
to directly attempt https as initial connection. VPN Terminator owner
could say that ISAKMP protocol is preferred over SSL etc.
1.1 State of Art
One of similar solutions (limited to Web only though) is HTTP Strict
Transport Security (HSTS) [HSTS]. Disadvantage of HSTS is that
initial connection is still done using HTTP unless address is
Piotr Kupisiewicz Expires June 14, 2016 [Page 3]
INTERNET DRAFT DNS Extension to provide DPROT field February 1, 2016
statically defined, in browser, as HTTPS only (HSTS Pre-Loaded List).
Since this does not scale and it is Web specific, DPROT is being
proposed (not as alternative to HSTS, but more as supplement to
replace HSTS Pre-Loaded List).
Taking other examples (different than HSTS limited to Web only):- One
might want to suggest ISAKMP instead of SSL while connecting to VPN
Gateway, not leaving decision to end-user. - One might want to
suggest IMAPS to be used instead of POP3S (both might be allowed, but
one might be preferred)
1.2 Terminology
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 RFC 2119 [RFC2119].
2 Publishing
Domain owners who would like to specify default protocols for
specific ports MUST use TXT extensions in following format:
rfc-editor.org TXT "DPROT=https"
rfc-editor.org TXT "DPROT=ssh"
rfc-editor.org TXT "DPROT=isakmp"
192.168.10.15 TXT "DPROT=https"
Protocol names should be used as defined by IANA in [RFC6335] and
[IANA_PORTS]
4 Application side implementation
Implementation on the Application side queries it's DNS Server for
TXT record type entries for the host that Application is about to
connect to (unless protocol is specifically given by user, i.e. by
using http:// specifically in the Web Browser).
For example Web Browser after user puts rfc-editor.org (without
protocol) in the address bar, queries DNS Server for TXT query type
with host rfc-editor.org. DNS returns entry:
rfc-editor.org TXT "DPROT=https"
Based on that Web Browser MUST use https://rfc.org as initial
Piotr Kupisiewicz Expires June 14, 2016 [Page 4]
INTERNET DRAFT DNS Extension to provide DPROT field February 1, 2016
connection attempt.
If the https connection fails Web Browser SHOULD alert the user and
by default not attempt to fallback to http protocol. Fallback to
different protocol SHOULD happen only after explicit customer's
permission.
In case there is no DPROT entry for specific host, it's up to
application's implementation on which protocol should be used.
4.1 Application implementation: Various Service Types It might happen
that for specific host there will be multiple different default
protocols specified for multiple different type of services
(Web/VPN/Remote Connection etc.). In example: rfc-editor.org TXT
"DPROT=https"
rfc-editor.org TXT "DPROT=ssh"
rfc-editor.org TXT "DPROT=ipsec"
It's up to application to understand which protocols are relevant to
the specific use cases. Web Browser SHOULD be aware that https is
relevant, ignoring ssh and ipsec.
5 DNS Security Considerations
Hence original DNS design does not provide any mechanism to prevent
man-in-middle attacks, DNS Security solutions like DNSSEC SHOULD be
used [DNSSEC].
In addition entries in DPROT, SHOULD be specify protocol only, it
SHOULD NOT contain addition protocol's specific information (like
suggested ciphers).
5 References
5.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1 1995.
[TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1 1996.
Piotr Kupisiewicz Expires June 14, 2016 [Page 5]
INTERNET DRAFT DNS Extension to provide DPROT field February 1, 2016
5.2 Informative References
[DNSSEC] D. Eastlake, "Domain Name System Security Extensions",
RFC 2535, March 1999
[HSTS] J. Hodges, C. Jackson, A. Barth, "HTTP Strict Transport
Security (HSTS)", RFC 6797, November 2012
[IANA_PORTS] http://www.iana.org/assignments/service-names-port-
numbers/service-names-port-numbers.txt
Authors' Addresses
Piotr Kupisiewicz
EMail: pkupisie@cisco.com
Piotr Kupisiewicz Expires June 14, 2016 [Page 6]
