idnits 2.17.1 draft-hallam-http-session-id-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Gill96], [Turkel96], [Smith96], [Netscape95], [Kristol95], [Rivest92]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 107 has weird spacing: '...r field which...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1996) is 10291 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: 'Turkel96' is mentioned on line 159, but not defined == Unused Reference: 'Hallam96' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'Connoly96' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'Hallam93' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'Berners-Lee96' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'Hallam-Baker94' is defined on line 557, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Netscape95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hallam96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kristol95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Connoly96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hallam93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Smith96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Rivest92' -- Possible downref: Non-RFC (?) normative reference: ref. 'Berners-Lee96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Gill96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hallam-Baker94' Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Session Identification URI 4 INTERNET DRAFT Phillip M. Hallam-Baker, W3C 5 Expires in six months email: 6 Dan Connolly, W3C 7 email: 8 21st February 1996 10 Session Identification URI 12 14 Status of this Memo 16 This document is an Internet draft. Internet drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas 18 and its working groups. Note that other groups may also distribute 19 working information as Internet drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months and can be updated, replaced or obsoleted by other documents 23 at any time. It is inappropriate to use Internet drafts as reference 24 material or to cite them as other than as "work in progress". 26 To learn the current status of any Internet draft please check the 27 "lid-abstracts.txt" listing contained in the Internet drafts shadow 28 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or 30 ftp.isi.edu (US West coast). Further information about the IETF can 31 be found at URL: http://www.cnri.reston.va.us/ 33 Distribution of this document is unlimited. Please send comments to 34 the HTTP working group (HTTP-WG) of the Internet Engineering Task 35 Force (IETF) at < http://www.ics.uci.edu/pub/ietf/http/. This note 36 is also avaliable as a World Wide Web Consortium Working Draft 37 WD-session-id-960221, archived at 38 http://www.w3.org/pub/WWW/TR/WD-session-id-960221.html 40 Abstract 42 A Uniform Resource Identifier for identifying HTTP sessions is 43 described. Session identification URIs permit HTTP transactions to 44 be linked within a limited domain. This provides a balance between 45 the needs of commercial servers for demographic data collection and 46 the privacy concerns of users. In addition session identification 47 URIs may be used as part of a high security authentication mechanism 48 to prevent replay attacks. 50 Introduction 52 HTTP is specified as a stateless protocol. This permits HTTP servers 53 to handle a large number of simultaneous requests. The stateless 54 nature of HTTP reduces its utility however. It is not possible to 55 track user reading patterns on a single server nor is is possible 57 Session Identification URI 59 for a server to adapt its behavior on the basis of previous 60 interactions. 62 The ability to trace the path of readers within a Web is important 63 for maintainers of larger sites. Trace information may be used to 64 analyze the efficacy of cross references within the site, and to 65 build profiles of typical users. If it is known for example, that 66 readers of an online newspaper who visit the computer section are 67 very likely to also visit the business section reporters might be 68 asked to provide more cross linkages between these sections. 69 Administrators may also wish to discover the number of users 70 visiting their site rather than the number of visits. 72 Advertising as Revenue for Web Content Providers. 74 Many content providers raise revenue through advertising. 75 Advertisers therefore need to know the effectiveness of Web based 76 advertising. Content providers who can provide advertisers with 77 detailed profiles of the readership of their material will be able 78 to charge higher rates. Reader profiling would permit those 79 advertisements most likely to obtain a response to be chosen. 81 A distinctive feature of the Web is its interactive nature. Gill 82 [Gill96] points out that the interactive nature of the Web may make 83 traditional models of "targeted" advertising obsolete, replacing 84 them with participatory models. The Web is an information system and 85 users who wish to purchase goods are likely to use it to find out 86 details. It may be unnecessary to target advertising in an intrusive 87 manner (e.g. unsolicited email). As users become accustomed to more 88 participatory modes of advertising intrusive methods may become 89 counter productive. 91 There are many metrics which an advertiser may with to use to asses 92 the value of a Web placement. These include: 94 Hit counts 95 The number of times an advertisement is downloaded. These 96 roughly correspond to exposures as understood in conventional 97 media. 99 Referrals 100 The number of times an advertising hyperlink is followed. This 101 implies that the advertiser also has a Web site. 103 Hot leads and Sales. 104 Referrals which result in readers demonstrating a significant 105 level of interest or which generate sales. 107 Referrals may be determined using the HTTP referer field which 108 informs a server of the URI of the resource which referred the 109 client to a resource. Unfortunately current log file formats do not 110 include this information. A companion document describes an 111 extension to the logfile format to record this data. 113 Session Identification URI 115 The number of hot leads and/or sales generated by a placement may be 116 determined by correlating trace data within the advertiser's home 117 Web site with the referer field. This procedure creates an 118 interesting correspondence of interest between the parties which 119 removes the need for conventional auditing. An advertiser might pay 120 the publisher according to the business generated by a placement. It 121 is in the advertisers interest to be honest in determining the 122 amount paid since the publisher would determine placement frequency 123 according to the rate of return. This mechanism is of particular 124 interest for adverts targeted at a particular readership where 125 auditing may be difficult. 127 Privacy Concerns 129 Just because an advertiser is interested in information does not 130 mean that the user is willing to provide it. If care is not taken to 131 protect the privacy of its users the Web could enable more extensive 132 surveillance of its users than has been available to the most 133 ruthless dictatorships. 135 The Internet has a strongly developed but highly unpredictable 136 ethical sense. It is a medium of active participants, not of passive 137 consumers. Users may complain very publically about perceived wrongs 138 (whether justified or not) via Usenet which has a readership of 139 several millions. Privacy issues in particular are a frequently 140 issues. Consequently it is advisable to approach the issue of 141 personal privacy cautiously. 143 Users may be prepared to exchange information about themselves in 144 return for access to content. Such systems may provide inaccurate 145 data however. Users who believe their privacy to be threatened may 146 deliberately supply incorrect information, supplying a false address 147 and telephone number to prevent unsolicited mail and phone calls. 149 Personal data is often collected by financial institutions to serve 150 as a means of customer authentication. Disclosure of personal data 151 may therefore increase fraud risks. 153 Many countries have enacted privacy legislation which controls 154 storage and use of personal data. Sites which are governed by such 155 laws may wish to avoid unnecessary acquisition and recording of 156 personal data. 158 Although the Web has gained popularity as a publishing medium it was 159 conceived as a collaboration tool. As Turkel points out [Turkel96], 160 a part of the interest of cyberspace may be the ability to take on 161 different personas, the ability to voice unpopular views without 162 risk. Such partitioning of identity requires the ability to separate 163 online activity from offline activity and online activity at one 164 site with activity at another. The Web should therefore permit users 165 to take on new cyberspace identities through use of pseudonyms and 166 the boundaries between these identities must be carefully protected. 168 Session Identification URI 170 Privacy or lack thereof has often been an unanticipated consequence 171 of a particular technology. Early telephone users had little privacy 172 since every conversation could be overheard by the operator. This 173 lead directly to the automatic exchange which was invented by an 174 undertaker whose rival was stealing his business by bribing 175 telephone operators. 177 Transactions in the HTTP 1.0 protocol are disjoint. A single request 178 is made which results in a single response after which the operation 179 is completed and the TCP/IP connection closed. The HTTP/1.1 allows 180 the same TCP/IP connection to be used to perform multiple 181 operations. 183 Pseudo Session Identifiers. 185 IP addresses and ports may be used to provide pseudo identifiers for 186 analysis of demographic data. The usefulness of such identifiers is 187 severely limited. It is not possible to differentiate two users 188 timesharing on a single machine. Nor do users necessarily use the 189 same IP address each time. The value of IP addresses for analysis is 190 rapidly decreasing due to the growing use of proxies and dynamic IP 191 address assignment. These trends will be exacerbated by new 192 developments such as mobile IP. 194 Although these pseudo session identifiers are unreliable and 195 unsatisfactory they should be taken into consideration when 196 considering the privacy issues raised by this proposal. In 197 particular it is unnecessary to provide exhaustive proofs of that 198 certain forms of linkage cannot be achieved where this is possible 199 through similar analysis of IP addresses and ports. 201 Relationship to State-Info (Cookies) 203 State Info [Kristol95] is a proposed extension to the HTTP 204 protocol. It is a refinement of the Netscape "Cookies" proposal 205 [Netscape95]. This mechanism permits a server to generate a token 206 which a client which is returned with future requests. This 207 mechanism is requires clients to store data for every server visited 208 and is consequently unusable with a tracking mechanism unless the 209 number of sites using it is small. In the Session Identifier URI 210 proposal identifiers are generated by clients, not servers. This 211 provides for scalability since a client need only store a fixed 212 amount of identifier information regardless of the number of sites 213 visited. 215 URI Format 217 Session IDs have the form: 219 SID:_type_:_realm_:_identifier[_-_thread][_:_count]_ 221 Session Identification URI 223 Where the fields _type_, _realm_, _identifier_. _thread_ and _count_ 224 are defined as follows: 226 type 227 Type of session identifier. This field allows other session 228 identifier types to be defined. This draft specifies the 229 identifier type "ANON". 231 realm 232 Specifies the realm within which linkage of the identifier is 233 possible. Realms have the same format as DNS names. 235 identifier 236 Unstructured random integer specific to realm generated using a 237 procedure with a negligible probability of collision. The 238 identifier is encoded using base 64. 240 thread 241 Optional extension of identifier field used to differentiate 242 concurrent uses of the same session identifier. The thread field 243 is an integer encoded in hexadecimal. 245 count 246 Optional Hexadecimal encoded Integer containing a monotonically 247 increasing counter value. A client should increment the count 248 field after each operation. 250 Examples 252 The following example shows a sequence of session identifiers 253 created by the same client. Note that the same counter register is 254 used to generate all the session identifiers within the same thread. 256 SID:ANON:www.w3.org:j6oAOxCWZh/CD723LGeXlf-01:34 257 SID:ANON:mc.ai.mit.edu:NRviSpoYm7mdkYB4W2471l-01:35 258 SID:ANON:www.w3.org:j6oAOxCWZh/CD723LGeXlf-01:36 259 SID:ANON:mc.ai.mit.edu:NRviSpoYm7mdkYB4W2471l-01:37 260 SID:ANON:www.w3.org:j6oAOxCWZh/CD723LGeXlf-02:01 261 SID:ANON:www.w3.org:j6oAOxCWZh/CD723LGeXlf-01:38 263 Limited Linkage of Session Identifiers. 265 Session Identifier URIs permit linkage of transactions within a 266 single _realm_. A realm may be considered to approximate to a DNS 267 name. DNS names correlate reasonably well with administrative 268 divisions. This allows a content provider to track activities within 269 sites on their network but does not permit data from different sites 270 to be correlated without specific user authorization in advance. 272 Prevention of Replay Attacks 273 Session Identification URI 275 Session Identifiers may also be used within a strong authentication 276 scheme to prevent replay attacks. A replay attack involve the 277 recording of authentic traffic then replaying it at a later date. 278 For example Mallet might intercept Alice's request to download her 279 mail file on Monday and then replays it each day to receive the mail 280 for the rest of the week. 282 Replay attacks may be prevented by checking message timestamps. 283 Unfortunately this requires accurate and secure synchronisation of 284 clocks at both ends of the communication which is difficult. 285 Alternatively a challenge/response sequence may be employed. This 286 introduces an additional round trip delay into the transaction and 287 requires the server to maintain a check of which challenges have 288 already been responded to. 290 The session identifier URI may be used to prevent replay attacks in 291 combination with a timestamp. The server maintains a record of each 292 identifier used and checks that subsequent requests with that 293 identifier have a higher count field. The volume of data storage 294 required may be minimized by checking that the timestamp falls 295 within an acceptable validity interval. 297 Implementation Issues 299 A standardized method of constructing session identifiers would 300 permit users to use the same session identification information on 301 different machines avoiding the need to re-register with content 302 providers. This would also be convenient for content providers, 303 avoiding a user with more than one machine being counted twice. The 304 nature of the session identifiers prevents enforcement of such a 305 policy however and the following construction method is therefore 306 only advisory. 308 A convenient method of constructing session identifiers which does 309 not require separate storage for each realm visited is to use a 310 Message Authentication Code (MAC) based upon a cryptographically 311 secure one way function such as MD5 [Rivest92]. 313 On initialization the client obtains a value _key_. This value 314 should be selected in a random manner so as to provide at least 128 315 bits of ergodicity. When a realm is visited the value of the 316 identifier field is created using the formula 318 _identifier = MD5 (realm + key)_. 320 The client should store the value of _key_ and the counter value 321 associated with each thread. 323 HTTP Integration 325 Session identifiers may be incorporated in HTTP messages using the 326 Session-Id header. The existing WWW-Authenticate header is extended 327 to permit use of session identifiers as a lightweight authentication 329 Session Identification URI 331 mechanism. 333 Session-Id 335 Session-Id: _URI_ 337 The Session-Id header may be incorporated in a http request or 338 response. The header accepts a single parameter, the identifier URI. 340 Session identifiers are only created by clients. A Session-Id header 341 should only be present in a response if one was specified in the 342 corresponding request and should return the same session identifier 343 value as the request. 345 Example 347 The following example shows a HTTP request incorporating a session 348 identifier. 350 GET / HTTP/1.0 351 Accept: text/plain 352 Accept: text/html 353 Session-Id: SID:ANON:w3.org:j6oAOxCWZh/CD723LGeXlf-01:034 354 User-Agent: libwww/4.1 356 A client supporting session identifier URIs should by default attach 357 a session identifier to every request using the DNS name of the 358 server as the realm. Clients must provide users with an option to 359 disable session identifier generation. Clients are encouraged to 360 provide a means of selecting the _realm -> identifier_ mapping. 362 WWW-Authenticate 364 WWW-Authenticate: _1#challenge_ 366 The WWW-Authenticate header is used by a server to request that a 367 client to provide a session identifier where none was given or to 368 specify one for an alternative realm. This mechanism permits linkage 369 of identifiers across realms, but only under user control. 371 Example 373 The following data shows a server requesting an identifier for the 374 realm "w3.org". 376 Session Identification URI 378 HTTP/1.1 401 Unauthorized 379 WWW-Authenticate: Session, realm=w3.org 380 Server: libwww/4.1 382 Clients must not automatically respond to a WWW-Authenticate 383 challenge without user direction. 385 A client may offer the user a facility whereby requests for session 386 identifiers in alternative names are automatically accepted provided 387 they are compatible. Realms may be considered compatible provided 388 they are a non trivial prefix of the server dns name. For example a 389 server www.w3.org request for the session identifier in the realm 390 w3.org would be regarded as compatible but requests for w3.com, 391 mit.edu or org would not. DNS names in the toplevel domains com, 392 edu, gov, mil and org may generally be considered non trivial 393 prefixes (the exclusion of net from this list is intentional. Other 394 DNS domains may be considered non trivial prefixes if they are below 395 the second level of the DNS hierarchy. 397 Security Considerations 399 Security considerations are discussed throughout this paper in 400 addition to this section. 402 Unintended Linkage 404 Collusion between sites may permit linkage of session identifiers 405 between realms. A server may permit linkage between identifiers 406 within its own realm and another by incorporating the identifier 407 component in a URI. The server www.w3.org receiving the session 408 identifier SID:ANON:www.w3.org:j6oAOxCWZh/CD723LGeXlf-01:34 could 409 construct an identifier 410 http://ai.mit.edu/link/j6oAOxCWZh/CD723LGeXlf. If the link was 411 followed the server ai.mit.edu would be able to track the user's 412 activity across both realms. 414 Unsafe Construction Techniques. 416 Care must be taken in constructing session identifiers. A keyed 417 digest technique known to be cryptographically sound is recommended. 418 In particular implementors should note that a number of techniques 419 for constructing MACs from ciphers using XOR functions are insecure 420 for this application. 422 Further Work 424 Data Escrow Agents. 426 The method for constructing session identification URIs described 427 provides only one possible compromise between privacy and tracking. 428 In particular no provision is made for supporting joint registration 430 Session Identification URI 432 services. Such services would permit a user to register demographic 433 details (age, sex, interests etc.) with a single server 435 Data Escrow Agents support Joint registration services without 436 compromising user privacy. A data escrow agent would capture 437 demographic data at a central location, and analyze content 438 providers log files on their behalf. Escrow agents would be 439 responsible for preventing content providers receiving data detailed 440 enough to compromise user privacy. 442 In order to protect user privacy session identifiers must only be 443 linkable by the data escrow agent. This may be achieved using either 444 public key cryptography or message authentication codes. 446 In an implementation of a data escrow agent using public keys the 447 data escrow agent provides each content provider with the public 448 component of a public key pair. A user visiting a content provider's 449 site first creates a session identifier as if the escrow agent's 450 realm were to be visited then encrypts it using the content 451 provider's public key to create a session identifier specific to the 452 content provider. In order to analyze a log file the escrow agent 453 decrypts the session identifiers using the private portion of the 454 key. 456 In an implementation of a data escrow agent using a MAC, the user 457 provides the data escrow agent with demographic data indexed by a 458 session identifier keyed to the agent's realm. When contacting a 459 content provider the client constructs a session identifier using a 460 MAC of the session identifier keyed by the provider's realm. The 461 escrow agent may construct a linkage between the provider's logfiles 462 and entries in the escrowed database by calculating a MAC for every 463 entry in the database. Although this technique involves a larger 464 number of operations that the public key based scheme, these 465 operations are approximately four orders of magnitude faster. 467 Interaction with Proxies and Caches. 469 Many Web users browse the Web through a caching proxy. In many 470 countries this mode of operation is essential due to saturation of 471 international network connections. When a proxy serves a user from a 472 local cache the originating server has no knowledge of the 473 transaction. Consequently logfiles may be incomplete. This problem 474 is most serious for commercial sites which use hit counts as a 475 measure of readership. 477 A number of techniques may be used to prevent proxies from caching 478 data. This permits demographic data to be collected at the cost of 479 severely reducing network response. In a significant number of cases 480 this will prevent a user from receiving any data at all [Smith96]. 482 A better solution is to provide a mechanism whereby a proxy supplies 483 a server on request with a log of hits served from the cache. Such 484 logs are potentially of value as an indication of audited 486 Session Identification URI 488 circulation, particularly if they were to be authenticated using a 489 digital signature technique. In some circumstances it may be 490 desirable for providers of such information to mask usernames by 491 using session identifiers. It is intended to address these issues in 492 a separate document. 494 Acknowledgments 496 Dave Raggett made the original proposal to use an anonymous session 497 identifier for capture of demographic data. Rohit Khare and Dan 498 Connoly helped refine many of the ideas. Roger Hurwitz and John 499 Mallery made many helpful comments on early versions of this draft. 501 Authors Addresses 503 Phillip M. Hallam-Baker 504 hallam@w3.org 505 World Wid Web Consortium 506 Cambridge MA 508 Dan Connolly 509 connolly@w3.org 510 World Wid Web Consortium 511 Cambridge MA 513 References 515 [Netscape95] 516 Netscape Communications Corp. Persistent client State HTTP 517 Cookies_ 519 [Hallam96] 520 Phillip M. Hallam-Baker _ Extended Log File Format_ 522 [Kristol95] 523 Kristol, D. _ Proposed HTTP State-Info Mechanism _ 525 [Connoly96] 526 Dan Connoly _Proposals for Gathering Consumer Demographics_ 528 [Hallam93] 529 Phillip M. Hallam-Baker _Design note on HTTP referer field._ 530 Memo to Tim Berners-Lee. 532 [Smith96] 533 Neil Smith, Address at MIT _Workshop on Internet Survey 534 Methodology and Web Demographics_ January 29-30 1996. Cambridge 535 Ma. 537 [Rivest92] 539 Session Identification URI 541 Rivest, R., _"The MD4 Message-Digest Algorithm"_, RFC 1321, MIT 542 and RSA Data Security, Inc., April 1992 544 [Berners-Lee96] 545 Tim Berners-Lee, Roy T. Fielding, and Henrik Frystyk Nielsen. 546 _Hypertext Transfer Protocol -- HTTP/1.0_ 548 [Gill96] 549 Neil Smith, Address at MIT _Workshop on Internet Survey 550 Methodology and Web Demographics_ January 29-30 1996. Cambridge 551 Ma. 553 [RFC1034] 554 P. Mockapetris. _Domain Name System_ . ( RFC1034, RFC1035) 555 November 1987 557 [Hallam-Baker94] 558 Phillip M. Hallam-Baker _Shen Secure Hypertext Environment, 559 Design Notes._ CERN Programming Techniques Group.