National Institute of Standards and Technology における超伝導研究及び生活

This specification describes an optimized expression of the semantics
of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version
2 (HTTP/2). HTTP/2 enables a more efficient use of network resources
and a reduced perception of latency by introducing header field
compression and allowing multiple concurrent exchanges on the same
connection. It also introduces unsolicited push of representations
from servers to clients. This specification is an alternative to, but
does not obsolete, the HTTP/1.1 message syntax. HTTP's existing
semantics remain unchanged.

https://greenbytes.de/tech/webdav/rfc7540.pdf

Hypertext Transfer Protocol Version 2 (HTTP/2)

Transmeta's Crusoe microprocessor is a full, system-level implementation of the x86 architecture, comprising a native VLIW microprocessor with a software layer, the Code Morphing Software (CMS), that combines an interpreter, dynamic binary translator, optimizer, and run-time system. In its general structure, CMS resembles other binary translation systems described in the literature, but it is unique in several respects. The wide range of PC workloads that CMS must handle gracefully in real-life operation, plus the need for full system-level x86 compatibility, expose several issues that have received little or no attention in previous literature, such as exceptions and interrupts, I/O, DMA, and self-modifying code. In this paper we discuss some of the challenges raised by these issues, and present the techniques developed in Crusoe and CMS to meet those challenges. The key to these solutions is the Crusoe paradigm of aggressive speculation, recovery to a consistent x86 state using unique hardware commit-and-rollback support, and adaptive retranslation when exceptions occur too often to be handled efficiently by interpretation.

/pdf/the-transmeta-code-morphing-spl-trade-software-using-1hco8m7ogj.pdf

The Transmeta Code Morphing/spl trade/ Software: using speculation, recovery, and adaptive retranslation to address real-life challenges

A virtual machine monitor (VMM) allows multiple operating systems to run concurrently on virtual machines (VMs) on a single hardware platform. Each VM can be treated as an independent operating system platform. A secure VMM would enforce an overarching security policy on its VMs.

The potential benefits of a secure VMM for PCs include: a more secure environment, familiar COTS operating systems and applications, and enormous savings resulting from the elimination of the need for separate platforms when both high assurance policy enforcement, and COTS software are required.

This paper addresses the problem of implementing secure VMMs on the Intel Pentium architecture. The requirements for various types of VMMs are reviewed. We report an analysis of the virtualizability of all of the approximately 250 instructions of the Intel Pentium platform and address its ability to support a VMM. Current "virtualization" techniques for the Intel Pentium architecture are examined and several security problems are identified. An approach to providing a virtualizable hardware base for a highly secure VMM is discussed.

/pdf/analysis-of-the-intel-pentium-s-ability-to-support-a-secure-2se4rclx82.pdf

Analysis of the Intel Pentium's ability to support a secure virtual machine monitor

If a host is located behind a NAT, then in certain situations it can
be impossible for that host to communicate directly with other hosts
(peers). In these situations, it is necessary for the host to use the
services of an intermediate node that acts as a communication relay.
This specification defines a protocol, called TURN (Traversal Using
Relays around NAT), that allows the host to control the operation of
the relay and to exchange packets with its peers using the relay. TURN
differs from some other relay control protocols in that it allows a
client to communicate with multiple peers using a single relay
address. [STANDARDS-TRACK]

/pdf/traversal-using-relays-around-nat-turn-relay-extensions-to-1scwzxvyji.pdf

Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)

A new processor architecture poses significant financial risk to hardware and software developers alike, so both have a vested interest in easily porting code from one processor to another. Binary translation offers solutions for automatically converting executable code to run on new architectures without recompiling the source code.

Welcome to the opportunities of binary translation

Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) are widely used to protect data exchanged over application
protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last
few years, several serious attacks on TLS have emerged, including
attacks on its most commonly used cipher suites and their modes of
operation. This document provides recommendations for improving the
security of deployed services that use TLS and DTLS. The
recommendations are applicable to the majority of use cases.

/pdf/recommendations-for-secure-use-of-transport-layer-security-3mos87afqx.pdf

Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

Over the last few years, there have been several serious attacks on
Transport Layer Security (TLS), including attacks on its most commonly
used ciphers and modes of operation. This document summarizes these
attacks, with the goal of motivating generic and protocol-specific
recommendations on the usage of TLS and Datagram TLS (DTLS).

{RFC~7457: Summarizing} Known Attacks on {Transport Layer Security (TLS)} and {Datagram TLS (DTLS)}

/pdf/summarizing-known-attacks-on-transport-layer-security-tls-2ujs0rbdvx.pdf

Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)

The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number of
round-trips required and the cryptographic operations involved. In
remote access situations, the Extensible Authentication Protocol (EAP)
is used for authentication, which adds several more round trips and
consequently latency. To re-establish security associations (SA) upon
a failure recovery condition is time consuming, especially when an
IPsec peer, such as a VPN gateway, needs to re-establish a large
number of SAs with various end points. A high number of concurrent
sessions might cause additional problems for an IPsec peer during SA
re-establishment. In order to avoid the need to re-run the key
exchange protocol from scratch it would be useful to provide an
efficient way to resume an IKE/IPsec session. This document proposes
an extension to IKEv2 that allows a client to re-establish an IKE SA
with a gateway in a highly efficient manner, utilizing a previously
established IKE SA. A client can reconnect to a gateway from which it
was disconnected. The proposed approach uses a IKEv2 state (or a
reference into a state store). to store state information that is
later made available to the IKEv2 responder for re-authentication.
Restoring state information by utilizing a ticket is one possible way.
This document does not specify the format of the ticket but
recommendations are provided.

Yaron Sheffer

Papers

Welcome to the opportunities of binary translation

Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

{RFC~7457: Summarizing} Known Attacks on {Transport Layer Security (TLS)} and {Datagram TLS (DTLS)}

Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)

Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption