Please don't define an "extended SNI". A new extension to signal the target IP
address would be fine. Keep it narrowly focused.
Having a separate extension might allow the DDR client to express both the SNI
and the IP it is seeking.
A separate expected certificate extension is another, separate, separable idea
that can have its own extension.
However...Both of these need ECH protection. Which means new ECH parameters.
I'm not sure that I like that idea very much.
On Fri, Jul 29, 2022, at 09:50, Erik Nygren wrote:
> 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>
>>> > <mailto:erik%2bi...@nygren.org <mailto:erik%252bi...@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
