Both of these are very good concerns about the compatibility risk.
I think David's alternative of having a new extension (eg, server_name_ip)
might address a bunch of the issues and be cleaner than any of the other
hacks.
It would have a higher implementation overhead, but also might be more
likely to be deployable.
I checked search.censys.io and there appear to be around 150M certificates
with IP addresses in them that it is aware of, and that is pretty much a
guarantee
that some of them will break with sending something new in an existing SNI
extension...
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
