Re: [TLS] Representing IP addresses in SNI -- proposed draft
On Fri, Jul 29, 2022 at 09:50:56AM -0400, Erik Nygren wrote:
> 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.
DANE does not need and must not carry a client-side expected fingerprint
signal:
* DANE adequately signals the expected server identity by sending the
"TLSA base domain" in SNI.
* The server's TLSA records are generally multi-valued (otherwise
breakage-free key rollover becomes impossible). There is no
single "expected certificate fingerprint", and DANE-TA(2) records
only signal the issuing CA.
* The server's public key may not infrequently be the same across
multiple candidate EE certificates, and its digest may not
clearly identify the right certificate to vend to the client.
...
> 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.)
There are surely better ways than client-side public key pinning to deal
with that use case. For that (home) users will need to be able to
practically manage their own roots of trust and name resolution. Either
PHB's Mathematical Mesh or something related could be the way forward.
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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 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 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
Re: [TLS] Representing IP addresses in SNI -- proposed draft
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
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 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:
>> > 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 mailto:erik%2bi...@nygren.org>>,
>>
>> > Rich Salz
>> >
>> >
>> >
>> > 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
Re: [TLS] Representing IP addresses in SNI -- proposed draft
Thanks for the pointer to that draft, it’s very helpful. The security considerations sections touches on my concerns a little bit, but probably needs more detail in this area. Another thing that might help is some sort of extension or signal that indicates that the certificate is intended to be used in this manner. Otherwise we’re adding new and potentially surprising behavior to all the existing IP address certificates out there, whether they want it or not. If the behavior is “opt-in” by all the participants that desire it, that would be safer. Maybe that’s not necessary, still reading and thinking this through. It’s an interesting use case. -Tim From: Erik Nygren Sent: Thursday, July 28, 2022 7:14 PM To: Tim Hollebeek Cc: David Benjamin ; TLS@ietf.org Subject: Re: [TLS] Representing IP addresses in SNI -- proposed draft The use-case that may increase IP certificates is this from ADD's DDR: https://datatracker.ietf.org/doc/html/draft-ietf-add-ddr-08#section-4.2 At a high-level, the client talks insecurely to their configured local DNS resolver with IP address "A" and queries for "_dns.resolver.arpa." That returns a SVCB record that points to another DNS resolver that may have hostname dot.example.com<http://dot.example.com> with IP address "B". As part of the "Verified Discovery" logic, the client connects to dot.example.com<http://dot.example.com> (IP address "B") but then has to verify that the presented TLS certificate contains IP address "A". If they share an IP address this is straight-forward (and a "normal" IP address cert). But if A and B are different IPs then "dot.example.com<http://dot.example.com>" in this case may need a separate IP address "B" (and hostname) for each IP address "A" that might be in-use (with perhaps some efficiencies possible through SAN-packing). Erik On Thu, Jul 28, 2022 at 3:04 PM Tim Hollebeek mailto:tim.holleb...@digicert.com>> wrote: I’m worried about the fact that this means a certificate that was issued for and intended to be used by a particular IP address is now potentially usable on any arbitrary IP address via this behavior. Though I haven’t thought it all the through yet, it seems to me to be likely that there are use cases where this has at least mild unexpected security consequences. Bonus points if you find a way this makes it easier to collect traffic intended for that IP from a different IP. On .in-addr.arpa certificates, I’ve been trying to find out why there are web servers running on those domains since I was at my previous employer over five years ago, and have been periodically asking about them: https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg11410.html If anyone knows why they exist, I’d love to know. Also, if IP certificates are getting more common again, I’d love to hear about those use cases as they’re not on my radar at this time. When I wrote the ballot for validation of IP addresses, it was a royal pain and took a few years because no one was actually interested in them. My impression was that they were slowly going away with time, but I haven’t looked at the numbers recently. -Tim From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Erik Nygren Sent: Wednesday, July 27, 2022 4:59 PM To: David Benjamin mailto:david...@chromium.org>> Cc: TLS@ietf.org<mailto:TLS@ietf.org> Subject: Re: [TLS] Representing IP addresses in SNI -- proposed draft 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<http://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 mailto: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 extensio
Re: [TLS] Representing IP addresses in SNI -- proposed draft
The use-case that may increase IP certificates is this from ADD's DDR: https://datatracker.ietf.org/doc/html/draft-ietf-add-ddr-08#section-4.2 At a high-level, the client talks insecurely to their configured local DNS resolver with IP address "A" and queries for "_dns.resolver.arpa." That returns a SVCB record that points to another DNS resolver that may have hostname dot.example.com with IP address "B". As part of the "Verified Discovery" logic, the client connects to dot.example.com (IP address "B") but then has to verify that the presented TLS certificate contains IP address "A". If they share an IP address this is straight-forward (and a "normal" IP address cert). But if A and B are different IPs then "dot.example.com" in this case may need a separate IP address "B" (and hostname) for each IP address "A" that might be in-use (with perhaps some efficiencies possible through SAN-packing). Erik On Thu, Jul 28, 2022 at 3:04 PM Tim Hollebeek wrote: > I’m worried about the fact that this means a certificate that was issued > for and intended to be used by a particular IP address is now potentially > usable on any arbitrary IP address via this behavior. Though I haven’t > thought it all the through yet, it seems to me to be likely that there are > use cases where this has at least mild unexpected security consequences. > Bonus points if you find a way this makes it easier to collect traffic > intended for that IP from a different IP. > > > > On .in-addr.arpa certificates, I’ve been trying to find out why there are > web servers running on those domains since I was at my previous employer > over five years ago, and have been periodically asking about them: > > > > > https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg11410.html > > > > If anyone knows why they exist, I’d love to know. > > > > Also, if IP certificates are getting more common again, I’d love to hear > about those use cases as they’re not on my radar at this time. When I > wrote the ballot for validation of IP addresses, it was a royal pain and > took a few years because no one was actually interested in them. My > impression was that they were slowly going away with time, but I haven’t > looked at the numbers recently. > > > > -Tim > > > > *From:* TLS *On Behalf Of * Erik Nygren > *Sent:* Wednesday, July 27, 2022 4:59 PM > *To:* David Benjamin > *Cc:* TLS@ietf.org > *Subject:* Re: [TLS] Representing IP addresses in SNI -- proposed draft > > > > 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 > 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 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 fo
Re: [TLS] Representing IP addresses in SNI -- proposed draft
I’m worried about the fact that this means a certificate that was issued for and intended to be used by a particular IP address is now potentially usable on any arbitrary IP address via this behavior. Though I haven’t thought it all the through yet, it seems to me to be likely that there are use cases where this has at least mild unexpected security consequences. Bonus points if you find a way this makes it easier to collect traffic intended for that IP from a different IP. On .in-addr.arpa certificates, I’ve been trying to find out why there are web servers running on those domains since I was at my previous employer over five years ago, and have been periodically asking about them: https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg11410.html If anyone knows why they exist, I’d love to know. Also, if IP certificates are getting more common again, I’d love to hear about those use cases as they’re not on my radar at this time. When I wrote the ballot for validation of IP addresses, it was a royal pain and took a few years because no one was actually interested in them. My impression was that they were slowly going away with time, but I haven’t looked at the numbers recently. -Tim From: TLS On Behalf Of Erik Nygren Sent: Wednesday, July 27, 2022 4:59 PM To: David Benjamin Cc: TLS@ietf.org Subject: Re: [TLS] Representing IP addresses in SNI -- proposed draft 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<http://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 mailto: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 mailto: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
Re: [TLS] Representing IP addresses in SNI -- proposed draft
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 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 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: >> > 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 mailto:erik%2bi...@nygren.org>>, >> >> > Rich Salz >> > >> > >> > >> > 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
Re: [TLS] Representing IP addresses in SNI -- proposed draft
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 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: > > 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 mailto:erik%2bi...@nygren.org>>, > > Rich Salz > > > > > > > > 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
Re: [TLS] Representing IP addresses in SNI -- proposed draft
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: > 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 mailto:erik%2bi...@nygren.org>>, > Rich Salz > > > > 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] Representing IP addresses in SNI -- proposed draft
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: 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 , Rich Salz 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
