I was thinking about the new extension idea more. It has the downside of
potentially being an API change in client/server TLS stacks,
but opening this up might generally be worth considering. If we added an
"Extended SNI" extension to support IPAddress,
we might also want to consider if there are other things worth adding.
Also including an Extended SNI option for "Certificate Fingerprint" would
solve a bunch of issues
that have come up from time-to-time. For example, it might help with DANE.
We've also talked in the past about being able to include a certificate
fingerprint
in URIs, and being able to signal that in Extended SNI would likely make
that work better.
(A use-case for this is for using TLS in local/private network environments
such as to
home network devices or even localhost processes where being able to have a
URI
with an {IP,cert_fingerprint(s)} pairing would have better security
properties than trying
to use some global PKIX framework.)
Is this something worth considering or that others in the WG might be
interested in?
Erik
On Wed, Jul 27, 2022 at 4:16 PM David Benjamin <david...@chromium.org>
wrote:
> I agree this is quite a compatibility risk. In addition to messing with
> SNI lookup, there are servers that try to correlate TLS SNI and HTTP Host.
> Indeed, when we accidentally sent IP literals in SNI, we broke a server
> that tried to do that but got very confused by the colons in an IPv6
> literal. That server would likely also be confused by this draft, less by
> syntax and more by SNI/Host mismatch. I would be surprised if this option
> were viable.
>
> Another option, which doesn't require redefining existing fields, is to
> simply allocate a new extension. Though I agree with Martin that one would
> expect the server to know its own IP. If you implicitly interpret a missing
> server_name extension as "I want the IP cert for this connection's IP",
> it's already unambiguous. Granted, there may be edge cases because missing
> server_name can also mean "I want the default cert" and perhaps your
> "default" cert and IP cert are different.
>
> On Wed, Jul 27, 2022 at 12:17 PM Martin Thomson <m...@lowentropy.net> wrote:
>
>> Hi Erik,
>>
>> As far as it goes, this might work. However, I'm not sure about the
>> effect of this on compatibility. I'm concerned that maybe this would end
>> up causing some servers to choke. Servers that receive SNI can sometimes
>> use that SNI value to lookup the correct certificate. Your design could
>> have those servers searching for a certificate that doesn't exist.
>>
>> Anything along these lines would need to be tested for compatibility -
>> extensively - before it could even be trialed.
>>
>> (I never saw the DDR as having deployment problems along these lines. It
>> isn't THAT hard to know your own IP address for that purpose.)
>>
>> On Wed, Jul 27, 2022, at 14:38, Erik Nygren wrote:
>> > Following discussions in ADD around the DDR draft (as well as in UTA
>> > around Martin Thomson's PR to add IP address SANs to 6125-bis),
>> > I wrote up a draft on how IP addresses might be represented in SNI:
>> >
>> > https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>> >
>> > There are at least three different ways we could do it, but this draft
>> > proposes what seems to be the least bad while also talking about the
>> > other alternatives. (I suspect we'd want to move the alternatives
>> > to an appendix or remove entirely from a final version.)
>> >
>> > Is this interesting to the working group?
>> > While IP address SANs have a bunch of corner cases and gaps,
>> > they do seem to be picking up new uses.
>> >
>> > What motivated me to realize we need to solve this is that
>> > draft-ietf-add-ddr uses IP SANs in a new way. Rather than the
>> > client connecting to an IP address and expecting to see a SAN
>> > (where returning a cert associated with the IP address containing
>> > a SAN that the client connected to is straight-forward),
>> > DDR has clients connecting to a different IP and then
>> > expects to find an original IP also in the SAN list.
>> > This means that for an ISP with a large number of IPs
>> > (or using a services who operates DoH service on-behalf
>> > of many entities), you'd need to quickly/wastefully burn through IPv4
>> > addresses to enable a unique cert per original IP.
>> >
>> > Erik
>> >
>> >
>> > ---------- Forwarded message ---------
>> > From: <internet-dra...@ietf.org>
>> > Date: Wed, Jul 27, 2022 at 2:20 PM
>> > Subject: New Version Notification for draft-nygren-tls-ip-in-sni-00.txt
>> > To: Erik Nygren <erik+i...@nygren.org <mailto:erik%2bi...@nygren.org>>,
>>
>> > Rich Salz <rs...@akamai.com>
>> >
>> >
>> >
>> > A new version of I-D, draft-nygren-tls-ip-in-sni-00.txt
>> > has been successfully submitted by Erik Nygren and posted to the
>> > IETF repository.
>> >
>> > Name: draft-nygren-tls-ip-in-sni
>> > Revision: 00
>> > Title: Representing IP addresses in TLS Server Name Indication
>> > (SNI)
>> > Document date: 2022-07-27
>> > Group: Individual Submission
>> > Pages: 7
>> > URL:
>> > https://www.ietf.org/archive/id/draft-nygren-tls-ip-in-sni-00.txt
>> > Status:
>> > https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>> > Htmlized:
>> > https://datatracker.ietf.org/doc/html/draft-nygren-tls-ip-in-sni
>> >
>> >
>> > Abstract:
>> > This specification provides a mechanism for clients to send IP
>> > addresses in a TLS Server Name Indication (SNI) extension as part of
>> > TLS handshakes, allowing servers to return a certificate containing
>> > that subjectAltName. This is done by converting the IP address to a
>> > special-use domain name.
>> >
>> >
>> >
>> >
>> > The IETF Secretariat
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
