RFC 8160

IUTF8 Terminal Mode in Secure Shell (SSH)

📅 published April 2017, from ietf

RFC 8160: IUTF8 Terminal Mode in Secure Shell (SSH) 💖✨

Okay bestie, let's get into it! 🎀 This RFC was written by Simon Tatham (PuTTY) and Darren Tucker (OpenSSH). It's a Standards Track document, published in April 2017. It doesn't obsolete or update any other RFCs, so it's a fresh start. 🦋

The whole point is that it adds a brand new opcode for the widely used IUTF8 terminal mode, which tells the terminal that its I/O is UTF-8 encoded. Lowkey iconic 👑

1. Introduction 🌸

Okay so, the Secure Shell (SSH) connection protocol [RFC4254] has a way to encode terminal modes, and those get used in the "pty-req" channel request type. 💅

IUTF8 is a super common terminal mode. It basically says the terminal driver should assume that terminal I/O uses the UTF-8 character encoding [RFC3629]. The kernel's terminal driver on the server uses this to figure out how many bytes of input count as one logical character during line editing. It's giving "know your characters" energy 🧚

Here's the tea, though: SSH doesn't currently have an encoding for IUTF8. 😭 This document fixes that by specifying one. 🫶

2. Conventions Used in This Document 🍓

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those are the official rules-words, so keep an eye out for them! 🔥

3. New IUTF8 Opcode for Terminal Mode Encoding 🦋

The opcode value 42 is defined for the IUTF8 terminal mode. 💜

As specified in Section 8 of [RFC4254], all opcodes in the range 1 to 159 have a single uint32 argument. So the IUTF8 opcode gets followed by one uint32 argument. 🎀 The value 0 means IUTF8 is disabled, and the value 1 means it's enabled. Simple and iconic ✨

As with all the other encoded terminal modes, the client SHOULD transmit a value for this mode if it knows about one, and the server MAY ignore it. 🙈

4. IANA Considerations 🌈

This document augments the list of "Pseudo-Terminal Encoded Terminal Modes" defined in Section 8 of [RFC4254]. 💅

IANA has added the following opcode to the "Pseudo-Terminal Encoded Terminal Modes" registry:

opcode  mnemonic       description
------  --------       -----------
42      IUTF8          Terminal input and output is assumed to be
                       encoded in UTF-8.

5. Security Considerations 💀

Okay, bestie, this one's serious, so read carefully! 🚨

The security considerations of [RFC4254] apply. This extra terminal mode encoding is believed to have no security implications that differ from the existing set of encoded terminal modes. 🫶

Since the IUTF8 terminal mode is meant to be used with the UTF-8 character encoding, the security considerations of [RFC3629] also apply to systems where this mode is enabled. 😭 In particular, terminal drivers that read this bit as turning on UTF-8-aware line-editing behavior SHOULD carefully consider how that behavior will treat illegal sequences, overlong encodings, and redundant representations of composed characters (see [UNICODE]). Not me getting the Unicode drama in a security section 💀

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgements 🎀

The authors are so grateful to Colin Watson, who first suggested this terminal mode back in 2005. They also owe a big thank you to David Madore and Jakub Jelen for their earlier implementation work. Iconic squad goals 👑🫶

Authors' Addresses 💌

Simon Tatham PuTTY

Email: anakin@pobox.com

Darren Tucker OpenSSH

Email: dtucker@openssh.com

📦 where this page comes from