Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Token Binding for Transport Layer Security (TLS) Version 1.3 Connections
draft-ietf-tokbind-tls13-01

Versions:

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 "Expired".
	Author	Nick Harper
	Last updated	2018-05-21
	Replaces	draft-nharper-tokbind-tls13
	RFC stream	Internet Engineering Task Force (IETF)
	Formats	txt htmlized pdf bibtex bibxml
	Reviews	SECDIR Early review (of -00) by Stephen Kent Ready
	Additional resources	Mailing list discussion
Stream	WG state	WG Document
	Document shepherd	(None)
IESG	IESG state	I-D Exists
	Consensus boilerplate	Unknown
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors Email WG IPR References Referenced by Nits Search email archive

draft-ietf-tokbind-tls13-01

Network Working Group N. Harper Internet-Draft Google Inc. Updates: TBNEGO (if approved) May 21, 2018 Intended status: Standards Track Expires: November 22, 2018 Token Binding for Transport Layer Security (TLS) Version 1.3 Connections draft-ietf-tokbind-tls13-01 Abstract Negotiation of the Token Binding protocol is only defined for Transport Layer Security (TLS) versions 1.2 and earlier. Token Binding users may wish to use it with TLS 1.3; this document defines a backwards compatible way to negotiate Token Binding on TLS 1.3 connections. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on November 22, 2018. Copyright Notice Copyright (c) 2018 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Harper Expires November 22, 2018 [Page 1] Internet-Draft TLS 1.3 Token Binding May 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction Negotiating Token Binding using a TLS [I-D.ietf-tls-tls13] extension as described in [I-D.ietf-tokbind-negotiation] is fairly straightforward, but is restricted to TLS 1.2 and earlier. Only one minor change is needed to use this extension to negotiate Token Binding on connections using TLS 1.3 and later. Instead of the server putting the "token_binding" extension in the ServerHello like in TLS 1.2, in TLS 1.3 the server puts it in EncryptedExtensions instead. This document also non-normatively provides a clarification for the definition of the TokenBinding.signature field from [I-D.ietf-tokbind-protocol], since TLS 1.3 defines an alternate (but API-compatible) exporter mechanism to the one in [RFC5705] used in [I-D.ietf-tokbind-protocol]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Token Binding TLS Extension In TLS 1.3, the "token_binding" TLS extension may be present only in ClientHello and EncryptedExtensions handshake messages. The format of the "token_binding" TLS extension remains the same as defined in [I-D.ietf-tokbind-negotiation]. A client puts the "token_binding" TLS extension in its ClientHello to indicate its support for the Token Binding protocol. The client should follow the same rules for when to send this extension and the contents of its data as in section 2 of [I-D.ietf-tokbind-negotiation]. Since the "token_binding" extension remains unchanged from TLS 1.2 to TLS 1.3 in the ClientHello, a client sending the "token_binding" extension in a TLS 1.3 ClientHello is backwards compatible with a server that only supports TLS 1.2. A server puts the "token_binding" TLS extension in the EncryptedExtensions message following its ServerHello to indicate support for the Token Binding protocol and to select protocol version and key parameters. The server includes the extension following the Harper Expires November 22, 2018 [Page 2] Internet-Draft TLS 1.3 Token Binding May 2018 same rules as section 3 of [I-D.ietf-tokbind-negotiation], with the following changes: o The "token_binding&

Collecting "Typical" Domain Names for Web Servers - Paul Hoffman (10 min)
* See accompanying report here: https://www.icann.org/en/system/files/files/octo-023-24feb21-en.pdf
* work done for DPRIVE, ICANN
* Motivation: How long does it take to set up a TLS connection on a typical server?
* Alexa, Tranco, etc. are not representative, DNS resolvers tend to be local/regional
* Using Wikipedia external links from all languages as a better sample, after cleanup
* Actual analysis was performed on about 110,000 domain names
* If you are interested in large random samples of domain names, please see Paul privately
* around 17% dualstack. 4% DNSSEC signed

Comments/Questions:
- Alexander Mayrhofer - did you consider CT? Paul at the time no, but subsequently yes.
- Sample isn't "typical", but it is MORE typical - e.g. lots of online food orders going to local restaurants, domains are not in wikipedia, so not captured
- Oliver Gasser - starting assumption toplists not representative: did you compare your dataset with them? Paul yes. IPv6 adoption was almost identical, DNSSEC adoption was not (2% on the tranco list) -shows there are variances (eg less likely to use DNSSEC on alexa class lists)

Measuring DNS over TLS from the Edge: Adoption, Reliability, and Response Times - Trinh Viet Doan (15 min)
* This is preview of an accepted paper for PAM 2021, March 29-31 2021: https://www.pam2021.b-tu.de/program/
* Interested how it looks from home networks
* Open resolver support for DoT increased by 23% from 0.17 to mid 2019 to early 2020
* Daily RIPE Atlas measurements, both DoT and Do53: only 13 of more than 3000 probes support DoT
* Most errors from timeouts, sockets errors, TCP/TLS errors (DoT exclusive, higher failure rate)
* Guessing that at least some failures are from middleboxes dropping DoT requests
* Failures differ based on continent
* Measuring response times for DoT is trickier than for DNS53 - measurements include full TCP/TLS handshakes
* Limitation of Atlas: experiment isolation == can't see benefit of keep-alive in TLS and other expensive connect protocols
* DoT response times inflated by more than 100ms from DNS53
* Again, response times vary by continent/region. South America and Africa are slowest response times

Comments/Questions:
- Mirja - comment about DoH vs DoT in chat: TVD: cannot run DoH in Atlas. Some other papers have looked at that

Assessing the Privacy Benefits of Domain Name Encryption - Nguyen Phong Hoang (15 min)
* This paper was presented at ASIA CCS ’20, October 5–9, 2020, Taipei, Taiwan, and is available here: https://arxiv.org/pdf/1911.00563.pdf
* Domain names contain sensitive information, sent in plaintext during the traditional TLS handshake
* Looking at DoH/TLS and ESNI
* IP addresses are still visible to on-path observers and can be mapped to one or more domain names served by the IP address - single-server domains are "privacy-detrimental"
* Using Alexa and Majestic toplists (7.5 million domains) to back-map the commonality of the underlying IP authority/hosting
* Taking CDNs into consideration
* comes up with a metric to define 'privacy benefit'
* 70 percent of IP addresses host only one domain
* 80 percent of domains are hosted on multiple IP addresses
* The more domains you host on an IP address, the better the privacy benefit
* Top domain hosting providers use very small numbers of IP addresses often they are small enterprises
* Major providers have lots of IP addresses and a small degree of co-hosting
* Only 13% of domain-to-IP mappings are stable for at least two months
* Website: https://homepage.np-tokumei.net/publication/publication_2020_asiaccs/

Comments/Questions:
- Andrew Campling - privacy benefit from colo/CDN, but did you consider the privacy risks, security risks of increased centralisation? NPH: another paper submitted last year on centralizing all queries to one resolver. Orthogonal problem, queries can be distributed to multiple resolvers
- Eric Rescorla: looked at this, consequences of bad choices here terrible. Any assessment of relative impact of actual size of the sets. in some cases, 10 is good. eg. facebook/telegram hiding telegram in facebook is good. And, traffic analysis defences? NPH: sensitivity of website, debateable, what we consider is/is-not. an IP in AS-GOOGLE people don't really care, but anonimity set here can be 100-150. the whole set can be very sensitive. do Traffic-Analysis per website. 200,000 half are popular, half "sensitive" and solely on IP ad, can pinpoint 90% of them with high precision.