[TLS] RFC 3546 (Transport Layer Security Extensions) - 3.1 Server Name Indication

Anton Luka Šijanec <anton@sijanec.eu> Sun, 07 February 2021 16:58 UTC

Return-Path: <anton@sijanec.eu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFC73A110F for <tls@ietfa.amsl.com>; Sun, 7 Feb 2021 08:58:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.857
X-Spam-Level:
X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sijanec.eu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lroiA1AEjwUG for <tls@ietfa.amsl.com>; Sun, 7 Feb 2021 08:58:01 -0800 (PST)
Received: from sijanec.eu (93-103-235-126.static.t-2.net [93.103.235.126]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B1C3A1111 for <TLS@ietf.org>; Sun, 7 Feb 2021 08:57:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sijanec.eu; s=mail; t=1612717077; bh=79h+RyGikHlWFDzhJqilyUJF8UVX89zIyVQKaZno4Mo=; h=Date:From:To:Subject:From; b=wHgIJdyhkhlM4Mr0thiZU2rRQNJgoQyqRqJeMnJXVr/Np+sSjGV8q7IvsgCZ92IJl hX1lS5qR7QKtyMMKUfA/m1UyWTczmMhQ1yrjSKIbyuNNAd4yts2j/PRE+3ZTZyvhc8 KIAKcUXyMxhLmUyiuLHC+5mVgScj40eSO0JEWKpu512bj/OwUcxEVyyBDDNI+nMP9u 0kNHMVWGsHsKEIBZ4grLVW8fztk7ChVf1pJoxC/KNu4keuumE6qhdUTbHdB1BLAxqE 1klkiEChZGKRzyAspmZB1E7dFY81yUSasatTMJUJoZ7PrvZuebmFizWLoLS8hP68ME nuOgJJZL30jug==
Date: Sun, 07 Feb 2021 17:57:57 +0100
From: Anton Luka Šijanec <anton@sijanec.eu>
To: TLS@ietf.org
Message-Id: <20210207175757.659e93ffae88e3bda7f13752@sijanec.eu>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YCzNGiR3AI3nJvKOMMoGSbp-ZlU>
Subject: [TLS] RFC 3546 (Transport Layer Security Extensions) - 3.1 Server Name Indication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Feb 2021 16:58:04 -0000

Hello!

I have a question regarding a paragraph in the definition of SNI in RFC 3546. Citing:
> Literal IPv4 and IPv6 addresses are not permitted in "HostName".

As far as I understand, the HostName field is used by the (web) server when deciding what certificate to send based on the ClientHello. Let's say, for backwards compatibility with older clients that do not support SNI, that the server will always respond with domain.example TLS certificate when SNI is not present. The server, however, also has a specific certificate for use when the client connects directly to the IP address (in case of HTTPS that would for example be a request for https://192.0.2.1/).

Using the current specifications and configurations there is no way for a client to get the correct certificate for 192.0.2.1, because it can't signal to the server that it's connecting directly to an IP address.

This sounds like a limitation to me. Is there any way for a server to differentiate between a client that does not support SNI and connects to domain.example and a client that supports SNI but connects to 192.0.2.1?

What issues would be created if the above-mentioned paragraph was removed and the definition of HostName would be changed to allow FQDNs AND IP addresses?

What is the reasoning behind limiting HostName field only to FQDNs?

If allowing HostName would break something, would it be possible to add another NameType, IPAddress, that would support signaling IP addresses to the server?

A similar issue was already discussed in quic-issues@ietf on 2020-01-07.

Thanks!

-- 
Anton Luka Šijanec <anton@sijanec.eu>