+1 to defining separate extensions and avoiding unnecessary coupling.
-----Original Message-----
From: TLS <tls-boun...@ietf.org> On Behalf Of Martin Thomson
Sent: Friday, July 29, 2022 8:42 AM
To: Erik Nygren <erik+i...@nygren.org>; David Benjamin <david...@chromium.org>
Cc: TLS@ietf.org
Subject: [EXTERNAL] Re: [TLS] Representing IP addresses in SNI -- proposed draft
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>> > datatracker.ietf.org%2Fdoc%2Fdraft-nygren-tls-ip-in-sni%2F&dat
>>> > a=05%7C01%7CAndrei.Popov%40microsoft.com%7C9e531fd5d3634c79fb6b08d
>>> > a71791222%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63794706208
>>> > 9321629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
>>> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w5M5RQ3
>>> > Ivo8%2FjWc6VQcoI4fXdAP2Yg8fXIQTzFmM7aw%3D&reserved=0
>>> >
>>> > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-nygren-tls-ip-in-sni-00.txt&data=05%7C01%7CAndrei.Popov%40microsoft.com%7C9e531fd5d3634c79fb6b08da71791222%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637947062089321629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q6yJ59t1MXOLJ9w1qVJZgVHPIGhXY%2FBdsfSGENpK2TA%3D&reserved=0
>>> > Status:
>>> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-nygren-tls-ip-in-sni%2F&data=05%7C01%7CAndrei.Popov%40microsoft.com%7C9e531fd5d3634c79fb6b08da71791222%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637947062089321629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w5M5RQ3Ivo8%2FjWc6VQcoI4fXdAP2Yg8fXIQTzFmM7aw%3D&reserved=0
>>> > Htmlized:
>>> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>> > datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-nygren-tls-ip-in-sni&
>>> > ;data=05%7C01%7CAndrei.Popov%40microsoft.com%7C9e531fd5d3634c79fb6
>>> > b08da71791222%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6379470
>>> > 62089321629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>>> > luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7QJ
>>> > dCRUccCI6K%2Fce0u0PuyqtQQdH%2Bup2bMLZGsfK%2F8w%3D&reserved=0
>>> >
>>> >
>>> > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>> > www.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7CAndrei.
>>> > Popov%40microsoft.com%7C9e531fd5d3634c79fb6b08da71791222%7C72f988b
>>> > f86f141af91ab2d7cd011db47%7C1%7C0%7C637947062089321629%7CUnknown%7
>>> > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
>>> > CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YOEVTTNuIgMLf%2FevfvNUzxtJ
>>> > taFN36px0FCdTZuwpaM%3D&reserved=0
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>>> w.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7CAndrei.Popo
>>> v%40microsoft.com%7C9e531fd5d3634c79fb6b08da71791222%7C72f988bf86f14
>>> 1af91ab2d7cd011db47%7C1%7C0%7C637947062089321629%7CUnknown%7CTWFpbGZ
>>> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>>> %3D%7C3000%7C%7C%7C&sdata=YOEVTTNuIgMLf%2FevfvNUzxtJtaFN36px0FCd
>>> TZuwpaM%3D&reserved=0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7CAndrei.Popov%40microsoft.com%7C9e531fd5d3634c79fb6b08da71791222%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637947062089321629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YOEVTTNuIgMLf%2FevfvNUzxtJtaFN36px0FCdTZuwpaM%3D&reserved=0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
