idnits 2.17.1 draft-wouters-dane-otrfp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 280, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'OTRSPEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMPP' -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track October 21, 2013 5 Expires: April 24, 2014 7 Using DANE to Associate OTR public keys with email addresses 8 draft-wouters-dane-otrfp-01 10 Abstract 12 The Off-The-Record Messaging protocol (OTR) exchanges public keys in- 13 band. This document describes how to use DANE to securely associate 14 an Instant Message user identified by their email address with an OTR 15 public key. This association helps to authenticate users and protect 16 against MITM attacks. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 24, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. The OTRFP Resource Record . . . . . . . . . . . . . . . . . . 3 55 2.1. Location of the OTRFP record . . . . . . . . . . . . . . 3 56 2.2. The OTRFP RDATA Format . . . . . . . . . . . . . . . . . 4 57 3. Building the fingerprint data . . . . . . . . . . . . . . . . 5 58 3.1. Multiprecision Integers (MPI) . . . . . . . . . . . . . . 5 59 3.2. OTR public key representation . . . . . . . . . . . . . . 6 60 3.3. Calculating a DSA fingerprint . . . . . . . . . . . . . . 6 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. OTRFP RRtype . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 5.1. Email address information leak . . . . . . . . . . . . . 7 65 5.2. UI presentation . . . . . . . . . . . . . . . . . . . . . 7 66 5.3. DNSSEC required . . . . . . . . . . . . . . . . . . . . . 7 67 6. Reference example . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 8.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Off-the-Record [OTRSPEC] is an encryption and authentication method 77 for two parties exchanging messages that works independantly of the 78 transport layer. There are OTR implementations for Instant Message 79 networks such as [XMPP], IRC [RFC2812], commercial IM networks, the 80 GSM SMS network and others. 82 OTR offers encryption, authentication, repudiation and perfect 83 forward secrecy. To authenticate the other party after an 84 unauthenticated Diffie-Hellman key exchange, a "long term" identity 85 keypair is used. It is up to both users to mutually verify each 86 other's OTR public key. One can make an out-of-band phone call, and 87 read out each other's public key fingerprint, assuming both parties 88 can recognise and trust each other's voice. Another option is to use 89 the shared secret. A third option is for both parties to ask each 90 other a question to which only the other party knows the answer. 92 None of the above listed methods allow a person to pre-publish their 93 OTR public key or finger print, or allow for a trusted third party or 94 PKI to vouch for OTR public keys. As a result, most users feel it is 95 too cumbersome to authenticate each other. As such, these users are 96 not protected against MITM attacks. 98 This document describes a mechanism to associate a user's OTR public 99 key with their email address, using a new DNS RRtype. This is 100 similar to the SSHFP [RFC4255] RRType, except that this method 101 associates keys with users, not hosts. Client implementations that 102 support this document will be able to protect their users against 103 MITM attacks, without requiring all users to manually verify each 104 other's identity. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 This document also makes use of standard DNSSEC and DANE terminology. 113 See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for 114 these terms. 116 2. The OTRFP Resource Record 118 The OTRFP DNS resource record (RR) is used to associate an end entity 119 OTR public key with an email address, thus forming a "OTRFP public 120 key association". 122 The type value allocated for the OTRFP RR type is [TBD]. The OTRFP 123 RR is class independent. The OTRFP RR has no special TTL 124 requirements. 126 2.1. Location of the OTRFP record 128 Domain names are prepared for requests in the following manner. 130 1. The user name (the "left-hand side" of the email address, called 131 the "local-part" in the mail message format definition [RFC2822] 132 and the "local part" in the specification for internationalized 133 email [RFC6530]), is encoded with Base32 [RFC4648], to become the 134 left-most label in the prepared domain name. This does not 135 include the "@" character that separates the left and right sides 136 of the email address. 138 2. The string "_otrfp" becomes the second left-most label in the 139 prepared domain name. 141 3. The domain name (the "right-hand side" of the email address, 142 called the "domain" in RFC 2822) is appended to the result of 143 step 2 to complete the prepared domain name. 145 For example, to request an OTRFP resource record for a user whose 146 address is "hugh@example.com", you would use 147 "nb2wo2a=._otrfp.example.com" in the request. The corresponding RR 148 in the example.com zone might look like: 150 nb2wo2a=._otrfp.example.com. IN OTRFP ( 151 3 0 1 5fdb8166f9089e253b90f95a91f48a8d2d2359ce ) 153 Design note: Encoding the user name with Base32 allows local parts 154 that have characters that would prevent their use in domain names. 155 For example, a period (".") is a valid character in a local part, but 156 would wreak havoc in a domain name. Similarly, RFC 6530 allows non- 157 ASCII characters in local parts, and encoding a local part with non- 158 ASCII characters with Base32 renders the name usable in the DNS. 160 2.2. The OTRFP RDATA Format 162 The RDATA for an OTRFP RR consists of an OTR protocol version, key 163 type, hash type and the fingerprint of the user's OTR public key. 165 1 2 3 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +---------------+-------------------------------+---------------+ 168 ! protocol ! Key Type ! Hash Type | 169 +---------------+-------------------------------+---------------+ 170 ! ! 171 ~ Fingerprint data ~ 172 ! ! 173 +---------------------------------------------------------------+ 175 The fields have the following meaning and encoding: 177 Protocol: 179 One octet specifying the OTR protocol version. The following 180 values are assigned: 182 Value Protocol 183 ----- -------------- 184 0 reserved 185 1 reserved 186 2 version 2 (obsoleted) 187 3 version 3 189 Key Type: 191 Two octets specifying the OTR Key Type as defined in 192 [draft-individual-otr]. The following values are assigned: 194 Value Key Type 195 ----- -------------- 196 0 DSA 198 Hash Type: 200 One octet value specifying the hash algorithm used to compute 201 the fingerprint data. The following values are assigned: 203 Value Hash Type 204 ----- -------------- 205 0 reserved 206 1 SHA-1 208 Fingerprint data: 210 The actual fingerprint data in hexadecimal (see below) 212 3. Building the fingerprint data 214 OTR represents keys using multiprecision integers (also called MPIs) 215 which are unsigned integers used to hold large integer values such as 216 the ones used in cryptographic calculations. The OTR Public Key 217 representation depends on the Key Type and the fingerprint is a human 218 readable representation of the message-digest (hash) of the OTR 219 Public Key. 221 3.1. Multiprecision Integers (MPI) 223 An MPI consists of two pieces: a two-octet scalar that is the length 224 of the MPI in bits followed by a string of octets that contain the 225 actual integer. 227 These octets form a big-endian number; a big-endian number can be 228 made into an MPI by prefixing it with the appropriate length. 230 Examples (all numbers are in hexadecimal): 232 The string of octets [00 01 01] forms an MPI with the value 1. The 233 string [00 09 01 FF] forms an MPI with the value of 511. 235 Additional rules: 237 The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. 239 The length field of an MPI describes the length starting from its 240 most significant non-zero bit. Thus, the MPI [00 02 01] is not 241 formed correctly. It should be [00 01 01]. 243 Unused bits of an MPI MUST be zero. 245 Also note that when an MPI is encrypted, the length refers to the 246 plaintext MPI. It may be ill-formed in its ciphertext. OTR does not 247 use encrypted MPIs. 249 3.2. OTR public key representation 251 An OTR Public Key is representated using a concatenation of its two 252 octet Key Type, followed by the MPI typed components that make up a 253 key. The number of components is dependant on the Key Type used. 255 A fingerprint is a hexadecimal representation of the message-digest 256 (hash) of an OTR Public Key. Currently, the only supported hash is 257 SHA-1. 259 There is an exception for backwards compatibility: if the OTR Key 260 Type is 0x0000 (DSA), then the two leading 0x00 octets are omitted 261 from the data to be hashed. 263 This encoding assures that, assuming the hash function itself has no 264 useful collisions, and DSA keys have a length of less than 524281 265 bits (500 times larger than most DSA keys), no two public keys will 266 have the same fingerprint. 268 3.3. Calculating a DSA fingerprint 270 For OTR Key Type 0x0000 (DSA), the public key is represented by its 271 Key Type (0x0000) concatenated with p(MPI) q(MPI) g(MPI) y(MPI) 273 This representation is hashed by the desired hashing function and 274 represented in hexadecimal to create the fingerprint data to be 275 included in the OTRFP RDATA section. 277 4. IANA Considerations 278 4.1. OTRFP RRtype 280 This document uses a new DNS RR type, OTRFP, whose value [TBD] has 281 been allocated by IANA from the Resource Record (RR) TYPEs 282 subregistry of the Domain Name System (DNS) Parameters registry. 284 5. Security Considerations 286 5.1. Email address information leak 288 DNS zones that are signed with DNSSEC using NSEC for denial of 289 existence are susceptible to zone-walking, a mechanism that allow 290 someone to enumerate all the names in the zone. Someone who wanted 291 to collect email addresses from a zone that uses OTRFP might use such 292 a mechanism. DNSSEC-signed zones using NSEC3 for denial of existence 293 are significantly less susceptible to zone-walking. Someone could 294 still attempt a dictionary attack on the zone to find OTRFP records, 295 just as they can use dictionary attacks on an SMTP server to see 296 which addresses are valid. 298 5.2. UI presentation 300 Client treatment of any information included in the OTRFP record is a 301 matter of local policy. Clients are strongly encouraged to not 302 visually equate a DANE verified fingerprint with a human-verified 303 fingerprint. Padlock icons are strongly discouraged as the 304 verification state of a public key is not a binary selection. 306 5.3. DNSSEC required 308 If an OTRFP resource record is received without DNSSEC protection, it 309 MUST be ignored. If the DNS request returned an "indeterminate" or 310 "bogus" answer, the user MUST be warned that they might be under 311 attack. Bogus data MUST NOT be used. 313 6. Reference example 315 Given a textual representation of a DSA private key for 316 hugh@example.com of: 318 (dsa 319 (p #0085CAB74C71F78ACBAF92E3959E772050E8332D1262CF7989D1ACDFBB545E 320 16E757DBAAD3047E306E250C69CA4347CC7347F68070DE46B8EC4C4B41579F 321 1D57F00E76EBFDD7EF5494D6E726428BE17D7E4BEFE0ECE6BA661E7BE799B6 322 E5BF5EF8BB02CD1466A06114EF517CCBC21D68CC769F5A15D4FC473BA27482 323 AC4F42C667#) 324 (q #0086CBA0573319CFA3D3EBD8225651E58B316B22F5#) 325 (g #2CE973832A3B23A9E8E5BC324E16A9445C0EBB73C03ACBBE5EEC6504F640DB 326 A49C97A42282271BA6127F848EC70F1A4AB784BE0A712081DF721452C87EE6 327 9B5C4FA963E933C2E592AF9631C3FDF94A85593A1BF6170889DBB8DD55A0A2 328 BB19874EBDA2D96929A541576D7800BFEB467D6F991E437883F8BC7D6A3654 329 5C04BDFC#) 330 (y #30CCBADF74E0313E1E6274DB8CC08FA6DC5EB6FA4729BB573034D75EB564CB 331 1F3DBECA70DF6A7337BD2A9EFA63986C2F64B4D4B32CFDB9F3BF6719DC4A98 332 43E60319236D8EB936FFE845C5A6B856557F0E9A4CA769041FBA92CA2CCE88 333 E2E3441650437FF5FB315F4AFF5CA43BFF3539B520297EC1C5BAF3E437F829 334 3F9E2DA8#) 335 (x #4EB9993416934FAE476E4655B5A520373F1321CE#) 336 ) 338 The fingerprint is calculated (leaving out the 0x0000 Key Type for 339 DSA) by hashing: 341 SHA-1( p(MPI) | q(MPI) | g(MPI) | y(MPI) ) 343 which yields (in hexadecimal): 345 35b3c7c02cf9e74bd53f33a0bb815ccd39e60a8d 347 Resulting in the following OTRFP record: 349 nb2wo2a=._otrfp.example.com. IN OTRFP ( 350 3 0 1 35b3c7c02cf9e74bd53f33a0bb815ccd39e60a8d ) 352 7. Acknowledgements 354 This document is based on RFC-4255 and draft-ietf-dane-smime whose 355 authors are Paul Hoffman, Jacob Schlyter and W. Griffin. The MPI 356 section has been taken verbatim from RFC-4880. 358 8. References 360 8.1. Normative References 362 [OTRSPEC] , "Off-the-Record Messaging Protocol version 3", September 363 2012, 364 . 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, March 1997. 369 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 370 Rose, "DNS Security Introduction and Requirements", RFC 371 4033, March 2005. 373 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 374 Rose, "Resource Records for the DNS Security Extensions", 375 RFC 4034, March 2005. 377 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 378 Rose, "Protocol Modifications for the DNS Security 379 Extensions", RFC 4035, March 2005. 381 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 382 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 383 January 2006. 385 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 386 Encodings", RFC 4648, October 2006. 388 [XMPP] , "XMPP Standards Foundation RFCs", February 2003, 389 . 391 8.2. Informative References 393 [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 394 2812, April 2000. 396 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 397 2001. 399 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 400 Internationalized Email", RFC 6530, February 2012. 402 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 403 of Named Entities (DANE) Transport Layer Security (TLS) 404 Protocol: TLSA", RFC 6698, August 2012. 406 Author's Address 408 Paul Wouters 409 Red Hat 411 Email: pwouters@redhat.com