< draft-roughtime-aanchal-00.txt   draft-roughtime-aanchal-01.txt >
Internet Engineering Task Force A. Malhotra Internet Engineering Task Force A. Malhotra
Internet-Draft Boston University Internet-Draft Boston University
Intended status: Informational A. Langly Intended status: Informational A. Langley
Expires: August 12, 2019 Google Expires: September 12, 2019 Google
W. Ladd W. Ladd
Cloudflare Cloudflare
February 8, 2019 March 11, 2019
Roughtime Roughtime
draft-roughtime-aanchal-00 draft-roughtime-aanchal-01
Abstract Abstract
This document specifies Roughtime - a protocol that aims to achieve This document specifies Roughtime - a protocol that aims to achieve
rough time synchronization while detecting servers that provide rough time synchronization while detecting servers that provide
inaccurate time and providing cryptographic proof of their inaccurate time and providing cryptographic proof of their
malfeasance. malfeasance.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 12, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Motivation 1. Motivation
Time synchronization is essential to Internet security as many Time synchronization is essential to Internet security as many
security protocols and other applications require synchronization security protocols and other applications require synchronization
[RFC7384][MCBG]. Unfortunately widely deployed protocols such as the [RFC7384][MCBG]. Unfortunately widely deployed protocols such as the
Network Time Protocol (NTP) [RFC5905] lack essential security Network Time Protocol (NTP) [RFC5905] lack essential security
features, and even newer protocols like Network Time Security (NTS) features, and even newer protocols like Network Time Security (NTS)
[I-D.ietf-ntp-using-nts-for-ntp] fail to ensure that the servers [I-D.ietf-ntp-using-nts-for-ntp] fail to ensure that the servers
behave correctly. Authenticating time servers prevents network behave correctly. Authenticating time servers prevents network
adversaries from modifying time packets. An authenticated time adversaries from modifying time packets, but an authenticated time
server still has full control over the contents of time packet and server still has full control over the contents of time packet and
may go rogue. Roughtime protocol provides cryptographic proof of may go rogue. The Roughtime protocol provides cryptographic proof of
malfeasance, enabling clients to detect and prove to a third party malfeasance, enabling clients to detect and prove to a third party
server's attempts to influence the time a client computes. server's attempts to influence the time a client computes.
+--------------+----------------------+-----------------------------+ +--------------+----------------------+-----------------------------+
| Protocol | Authenticated Server | Server Malfeasance Evidence | | Protocol | Authenticated Server | Server Malfeasance Evidence |
+--------------+----------------------+-----------------------------+ +--------------+----------------------+-----------------------------+
| NTP, Chronos | N | N | | NTP, Chronos | N | N |
| NTP-MD5 | Y* | N | | NTP-MD5 | Y* | N |
| NTP-Autokey | Y** | N | | NTP-Autokey | Y** | N |
| NTS | Y | N | | NTS | Y | N |
skipping to change at page 3, line 17 skipping to change at page 3, line 17
Roughtime is a protocol for rough time synchronization that enables Roughtime is a protocol for rough time synchronization that enables
clients to provide cryptographic proof of server malfeasance. It clients to provide cryptographic proof of server malfeasance. It
does so by having responses from servers include a signature with a does so by having responses from servers include a signature with a
certificate rooted in long term public/private key pair over a certificate rooted in long term public/private key pair over a
portion of the initial request, thus providing cryptographic proof portion of the initial request, thus providing cryptographic proof
that the timestamp was issued after previous responses and before that the timestamp was issued after previous responses and before
future ones. future ones.
Single server mode: At its most basic level, Roughtime is a one round Single server mode: At its most basic level, Roughtime is a one round
protocol in which a completely fresh client requests the current time protocol in which a completely fresh client requests the current time
and the server sends a signed response. The response inculdes a and the server sends a signed response. The response includes a
timestamp (the number of microseconds since the Unix epoch) and a timestamp (the number of microseconds since the Unix epoch) and a
radius (in microseconds) used to indicate the servers certainty about radius (in microseconds) used to indicate the server's certainty
the reported time. For example, a radius of 1,000,000 microseconds about the reported time. For example, a radius of 1,000,000
means the server is absolutely confident that the true time is within microseconds means the server is absolutely confident that the true
one second of the reported time. time is within one second of the reported time.
The server proves freshness of its response as follows: The request The server proves freshness of its response as follows: The request
contains a random challenge. The server incorporates the challenge contains a random challenge. The server incorporates the challenge
into its signed response so that its needed to verify the signature. into its signed response so that its needed to verify the signature.
This proves that the signed response could only have been generated This proves that the signed response could only have been generated
after the challenge was issued if the challenge has sufficient after the challenge was issued if the challenge has sufficient
entropy. entropy.
Chaining multiple servers: For subsequent requests, the client Chaining multiple servers: For subsequent requests, the client
generates its nonce by hashing the reply from the first server with a generates its nonce by hashing the reply from the first server with a
skipping to change at page 3, line 49 skipping to change at page 3, line 49
server is before the first, then the client has proof of misbehavior; server is before the first, then the client has proof of misbehavior;
the reply from the second server implicitly shows that it was created the reply from the second server implicitly shows that it was created
later because of the way that the client constructed the nonce. If later because of the way that the client constructed the nonce. If
the time from the second server is after, then the client can contact the time from the second server is after, then the client can contact
the first server again and get a signature that was provably created the first server again and get a signature that was provably created
afterwards, but with an earlier timestamp. afterwards, but with an earlier timestamp.
With only two servers, the client can end up with proof that With only two servers, the client can end up with proof that
something is wrong, but no idea what the correct time is. But with something is wrong, but no idea what the correct time is. But with
half a dozen or more independent servers, the client will end up with half a dozen or more independent servers, the client will end up with
chain of proof of any servers misbehavior, signed by several others, chain of proof of any server's misbehavior, signed by several others,
and (presumably) enough accurate replies to establish what the and (presumably) enough accurate replies to establish what the
correct time is. Furthermore this proof may be validated by third correct time is. Furthermore this proof may be validated by third
parties ultimately leading to a revocation of trust in the parties ultimately leading to a revocation of trust in the
misbehaving server. misbehaving server.
4. Message Format 4. Message Format
A uint32 is a 32 bit unsigned integer. It is serialized in bytes
with the least significant byte first. A uint64 is a 64 bit unsigned
integer. It is also seralized with the least significant byte first.
A Roughtime packet is a UDP packet whose contents are interpreted as A Roughtime packet is a UDP packet whose contents are interpreted as
a map from uint32s to strings of bytes. The byte strings must all a map from uint32s to strings of bytes. The byte strings must all
have lengths a multiple of four. All uint32 are encoded with the have lengths a multiple of four. All uint32 are encoded with the
least significant byte first. The keys of this map are called tags, least significant byte first. The keys of this map are called tags,
and we speak of the value of a tag as the string of bytes it is and we speak of the value of a tag as the string of bytes it is
mapped to. mapped to.
A Roughtime packet is serialized as follows: First there is a header, A Roughtime packet is serialized as follows: First there is a header,
The first four bytes in the header are the uint32 number of tags N, The first four bytes in the header are the uint32 number of tags N,
and hence of (tag, value) pairs. 4*(N-1) bytes are offsets, each and hence of (tag, value) pairs. 4*(N-1) bytes are offsets, each
skipping to change at page 4, line 35 skipping to change at page 4, line 39
Immediately following the header is a concatenation of all the Immediately following the header is a concatenation of all the
strings. The first post-header byte is at offset 0, and the end of strings. The first post-header byte is at offset 0, and the end of
the final byte string is indicated by the end of the packet. The ith the final byte string is indicated by the end of the packet. The ith
byte string ends at offset[i+1]-1, counting of course from 0, and byte string ends at offset[i+1]-1, counting of course from 0, and
begins at offset[i]. It is the value associated to the ith tag. begins at offset[i]. It is the value associated to the ith tag.
This encoding may be recursive: a value may be said to be in This encoding may be recursive: a value may be said to be in
Roughtime format and thus have a header, etc. Tags may be listed as Roughtime format and thus have a header, etc. Tags may be listed as
four ASCII characters [RFC0020]. In this case the tag when four ASCII characters [RFC0020]. In this case the tag when
serialized will be those four ASCII characters. Exempli gratia NONC serialized will be those four ASCII characters. For example NONC
would be the numeric value 0x434e4f4e. They may also be listed as would be the numeric value 0x434e4f4e. They may also be listed as
fewer then four ASCII characters with hex escape codes at the end. fewer then four ASCII characters with hex escape codes at the end.
5. Protocol 5. Protocol
5.1. Queries 5.1. Queries
A query is a Roughtime packet with the tag NONC. The contents of A query is a Roughtime packet with the tag NONC. The contents of
NONC are 64 bytes. The request packet MUST be a minimum of 1024 NONC are 64 bytes. The request packet MUST be a minimum of 1024
bytes. To attain this size the tag PAD\xff MAY be added at the end bytes. To attain this size the tag PAD\xff MAY be added at the end
skipping to change at page 5, line 14 skipping to change at page 5, line 16
5.2. Responses 5.2. Responses
A response contains the following tags: SREP, SIG\x00, CERT, INDX, A response contains the following tags: SREP, SIG\x00, CERT, INDX,
PATH, SREP value is itself in Roughtime format that contains the PATH, SREP value is itself in Roughtime format that contains the
folowing tags: ROOT, MIDP, RADI. SIG\x00 is an Ed25519 signature folowing tags: ROOT, MIDP, RADI. SIG\x00 is an Ed25519 signature
[RFC8032] over the SREP value using the public key contained in CERT [RFC8032] over the SREP value using the public key contained in CERT
as explained later. as explained later.
CERT in Roughtime format and contains the following tags: DELE, CERT in Roughtime format and contains the following tags: DELE,
SIG\x00. This SIG\x00 is an Ed25519 signature over DELE using the SIG\x00. This SIG\x00 is an Ed25519 signature over DELE that can be
long term public key of the server. DELE is itself in Roughtime verified using the long term public key of the server. DELE is
format containing tags MINT, MAXT, PUBK. itself in Roughtime format containing tags MINT, MAXT, PUBK.
5.2.1. SREP 5.2.1. SREP
ROOT contains the root hash value of a Merkle tree using SHA512 as ROOT contains the root hash value of a Merkle tree using SHA512 as
described when we reach the PATH and INDX blocks MIDP contains an described when we reach the PATH and INDX blocks
uint64 value consisting of the number of microseconds since the Unix
epoch in the smeared scale. RADI contains the server's estimate of MIDP contains an uint64 value consisting of the number of
the accuracy of MIDP. Servers MUST ensure the true time is within microseconds since the Unix epoch.
(MIDP-RADI, MIDP+RADI) at the time they compose the response packet.
RADI contains the server's estimate of the accuracy of MIDP.
Servers MUST ensure the true time is within (MIDP-RADI, MIDP+RADI)
at the time they compose the response packet.
LEAP contains the TAI-UTC offset at MIDP as a signed 32 bit
integer in two's complement. In cases of ambiguity due to leap
seconds either acceptable offset result is acceptable.
5.2.2. DELE 5.2.2. DELE
MINT is the minimum uint64 timestamp at which the key in PUBK is MINT is the minimum uint64 timestamp at which the key in PUBK is
trusted to begin signing time. MIDP > MINT for validity. MAXT is trusted to begin signing time. MIDP > MINT for validity.
the maximum uint64 timestamp at which PUBK may sign. MIDP < MAXT for
validity. PUBK is a temporary Ed25519 public key. The use of this MAXT is the maximum uint64 timestamp at which PUBK may sign. MIDP
field is to enable seperation of a root public key from keys on < MAXT for validity.
devices exposed to the public Internet.
PUBK is a temporary Ed25519 public key. The use of this field is
to enable seperation of a root public key from keys on devices
exposed to the public Internet.
5.2.3. INDX and PATH 5.2.3. INDX and PATH
INDX is a uint32 determining the position of NONC in a Merkle tree. INDX is a uint32 determining the position of NONC in a Merkle tree.
PATH determines the values to be hashed with the running hash as one PATH contains the values to be hashed with the running hash as one
ascends the tree. The final value MUST be equal to ROOT. PATH is a ascends the tree. PATH is a multiple of 64 bytes long. The
multiple of 64 bytes long. One starts by computing the hash of the following algorithm verifies inclusion in the Merkle tree:
NONC value from the request, with \x00 preappended. Then one walks
from the least significant bit of INDX to the most significant bit, One starts by computing the hash of the NONC value from the request,
and also walks towards the end of PATH. If PATH ends then the with \x00 preappended. Then one walks from the least significant bit
remaining bits of the INDX MUST be all zero. This indicates the of INDX to the most significant bit, and also walks towards the end
termination of the walk. If the current bit is 0, one hashes \x01, of PATH.
the current hash, and the value from PATH. If the current bit is 1
one hashes \x01, the value from PATH, and the current HASH. This If PATH ends then the remaining bits of the INDX MUST be all zero.
enables servers to batch signing when busy. This indicates the termination of the walk, and the current value
MUST equal ROOT if the response is valid.
If the current bit is 0, one hashes \x01, the current hash, and the
value from PATH.
If the current bit is 1 one hashes \x01, the value from PATH, and the
current hash.
5.3. Validity of response 5.3. Validity of response
A client MUST check the following properties when it receives a A client MUST check the following properties when it receives a
response. We assume the long term server public key is known to the response. We assume the long term server public key is known to the
client through other means. client through other means.
The signature in CERT was made with the long-term key of the The signature in CERT was made with the long-term key of the
server server
skipping to change at page 6, line 27 skipping to change at page 7, line 5
tree with value ROOT tree with value ROOT
The signature of SREP in SIG\x00 validates with the public key in The signature of SREP in SIG\x00 validates with the public key in
DELE DELE
A response that passes these checks is said to be valid. Validity of A response that passes these checks is said to be valid. Validity of
a response does not prove the time is correct, but merely that the a response does not prove the time is correct, but merely that the
server signed it, and more specifically began to compute the server signed it, and more specifically began to compute the
signature at a time in between (MIDP-RADI, MIDP+RADI). signature at a time in between (MIDP-RADI, MIDP+RADI).
6. The smeared scale 6. Time
Every day in Roughtime has 86400 seconds. A day without a leap
second is a day where all seconds are SI seconds. A day with a
positive leap second is one where every second is 86401/86400 SI
seconds long. A day with a negative leap second is a day where every
second is 86399/86400 SI seconds long. Days begin and end at noon,
and when a leap-second is added or removed from UTC it is smeared out
over the course of a day.
Arithemtic on the smeared scale requires knowing when the seconds All times in Roughtime are the number of seconds since the Unix
changed length and thus requires a leap second table. epoch. The Unix epoch is midnight, 1 January, 1970. This is a
constant offset from TAI. Servers SHOULD use GPS or other
realizations of TAI that have been highly accurate in the past for
Roughtime to meet their accuracy promises.
7. Cheater detection 7. Cheater detection
A chain of responses is a series of responses where the SHA-512 hash A chain of responses is a series of responses where the SHA-512 hash
of the preceding response H, is concatenated with a 64 bit blind X, of the preceding response H, is concatenated with a 64 byte blind X,
and then SHA-512(H, X) is the NONC used in the subsequent response. and then SHA-512(H, X) is the NONC used in the subsequent response.
These may be represented in JSON as TBD These may be represented as an array of objects in JSON where each
object may have keys "blind" and "packet". Packet has the base64
encoded bytes of the packet and blind is the blind used for the next
nonce. The last packet needs no blind.
A pair of responses (r_1, r_2) is invalid if MIDP_1-RADI_1 > A pair of responses (r_1, r_2) is invalid if MIDP_1-RADI_1 >
MIDP_2+RADI_2. A chain of longer length is invalid if for any i, j MIDP_2+RADI_2. A chain of longer length is invalid if for any i, j
such that i < j, (r_i, r_j) is an invalid pair. such that i < j, (r_i, r_j) is an invalid pair.
Invalidity of a chain is proof that causality has been violated if Invalidity of a chain is proof that causality has been violated if
all servers were reporting correct time. An invalid chain where all all servers were reporting correct time. An invalid chain where all
individual responses are valid is cryptographic proof of malfeasance individual responses are valid is cryptographic proof of malfeasance
of at least one server: if all servers had the correct time in the of at least one server: if all servers had the correct time in the
chain, causality would imply that MIDP_1-RADI_1 < MIDP_2+RADI_2. chain, causality would imply that MIDP_1-RADI_1 < MIDP_2+RADI_2.
8. Grease 8. Grease
Servers MAY send back a fraction of responses that are syntactically Servers MAY send back a fraction of responses that are syntactically
invalid or contain invalid signatures as well as incorrect times. invalid or contain invalid signatures as well as incorrect times.
Clients MUST properly reject such responses. Clients MUST properly reject such responses. Servers MUST NOT send
back responses with incorrect times and valid signatures. Either
signature MAY be invalid for this application.
9. Roughtime Servers 9. Roughtime Servers
The below list contains a list of servers with their public keys in The below list contains a list of servers with their public keys in
either Base64 or hexidecimal format. Base64 format.
roughtime.int08h.com:2002; roughtime.int08h.com:2002;
016e6e0284d24c37c6e4d7d8d5b4e1d3c1949ceaa545bf875616c9dce0 AW5uAoTSTDfG5NfY1bTh08GUnOqlRb+HVhbJ3ODJvsE=
roughtime.cloudflare.com:2002; gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/ roughtime.cloudflare.com:2002; gD63hSj3ScS+wuOeGrubXlq35N1c5Lby/
S+T7MNTjxo= S+T7MNTjxo=
roughtime.sandbox.google.com:2002; roughtime.sandbox.google.com:2002;
etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ= etPaaIxcBMY1oUeGpwvPMCJMwlRVNxv51KK/tktoJTQ=
10. Acknowledgements 10. Trust anchors and policies
TBD A trust anchor is any distributor of a list of trusted servers. It
is RECOMMENDED that trust anchors subscribe to TBD where evidence of
malfeasance may be shared and discussed. Trust anchors SHOULD
subscribe to a zero-tolerance policy: any generation of incorrect
timestamps will result in removal. To enable this trust anchors
SHOULD list a wide variety of servers so the removal of a server does
not result in operational issues for clients. Clients SHOULD attempt
to detect malfeasance and have a way to report it to trust anchors.
11. IANA Considerations Trust anchors SHOULD include any roughtime server with an uptime
greater then 99.9% over the past 6 months and with no malfeasance.
They SHOULD also aggressively collect evidence of such malfeasance.
This memo includes no request to IANA. Because only a single roughtime server is required for successful
synchronization, Roughtime does not have the incentive problems that
have prevented effective enforcement of discipline on the web PKI.
We expect that some clients will aggressively monitor server
behavior.
12. Security Considerations 11. Acknowledgements
Thomas Peterson corrected multiple nits. Marcus Dansarie, Tal
Mizrahi, and the other members of the NTP working group contributed
comments and suggestions.
12. IANA Considerations
We request IANA assign a UDP port and create a new registry for
Roughtime tags.
13. Security Considerations
This protocol will not survive the advent of quantum computers. This protocol will not survive the advent of quantum computers.
Currently only one signature scheme is supported. Maintaining a list Currently only one signature scheme is supported. Maintaining a list
of trusted servers and adjudicating violations of the rules by of trusted servers and adjudicating violations of the rules by
servers are not discussed in this document and are essential for servers are not discussed in this document and are essential for
security. Arithmetic on the adjusted timescale is interesting with security. Arithmetic on the adjusted timescale is interesting with
intervals, and this may impact the interpretation of the MAXT and intervals, and this may impact the interpretation of the MAXT and
MINT fields. Servers carry out a significant amount of computation MINT fields. Servers carry out a significant amount of computation
in response to clients, and thus may experience vulnerability to in response to clients, and thus may experience vulnerability to
denial of service attacks. denial of service attacks.
This protocol does not provide any confidentiality, and given the This protocol does not provide any confidentiality, and given the
nature of timestamps such impact is minor. The compromise of a nature of timestamps such impact is minor. The compromise of a
PUBK's private key, even past MAXT, is a problem as the private key PUBK's private key, even past MAXT, is a problem as the private key
can be used to sign invalid times that are in the range MINT to MAXT, can be used to sign invalid times that are in the range MINT to MAXT,
and thus violate the good behavior guarantee of the server. and thus violate the good behavior guarantee of the server.
13. Privacy Considerations Roughtime clients MUST update their view of which servers are
trustworthy in order to benefit from the detection of misbehavior.
Packets sent by the client MUST be at least 1024 bytes in length in
order to mitigate amplification attacks, and servers MUST ignore
request packets that are smaller than this length.
14. Privacy Considerations
This protocol is designed to obscure all client identifiers. Servers This protocol is designed to obscure all client identifiers. Servers
necessarily have persistent long term identities essential to necessarily have persistent long term identities essential to
enforcing correct behavior. enforcing correct behavior.
14. Informative References 15. References
15.1. Normative References
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
15.2. Informative References
[Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures", [Autokey] Rottger, S., "Analysis of the NTP Autokey Procedures",
2012, <https://zero-entropy.de/autokey_analysis.pdf>. 2012, <https://zero-entropy.de/autokey_analysis.pdf>.
[I-D.ietf-ntp-mac] [I-D.ietf-ntp-mac]
Malhotra, A. and S. Goldberg, "Message Authentication Code Malhotra, A. and S. Goldberg, "Message Authentication Code
for the Network Time Protocol", draft-ietf-ntp-mac-06 for the Network Time Protocol", draft-ietf-ntp-mac-06
(work in progress), January 2019. (work in progress), January 2019.
[I-D.ietf-ntp-using-nts-for-ntp] [I-D.ietf-ntp-using-nts-for-ntp]
Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time Sundblad, "Network Time Security for the Network Time
Protocol", draft-ietf-ntp-using-nts-for-ntp-16 (work in Protocol", draft-ietf-ntp-using-nts-for-ntp-17 (work in
progress), February 2019. progress), February 2019.
[MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
"Attacking the Network Time Protocol", 2015, "Attacking the Network Time Protocol", 2015,
<https://eprint.iacr.org/2015/1020>. <https://eprint.iacr.org/2015/1020>.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses Authors' Addresses
Aanchal Malhotra Aanchal Malhotra
Boston University Boston University
111 Cummington Mall 111 Cummington Mall
Boston 02215 Boston 02215
USA USA
Email: aanchal4@bu.edu Email: aanchal4@bu.edu
Adam Langly Adam Langley
Google Google
Watson Ladd Watson Ladd
Cloudflare Cloudflare
101 Townsend St 101 Townsend St
San Francisco San Francisco
USA USA
Email: watson@cloudflare.com Email: watson@cloudflare.com
 End of changes. 35 change blocks. 
76 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/