[TLS] draft-deprecate-obsolete-kex - Comments from WG Meeting

[Nimrod Aviram]

Hi Everyone,

Thank you for chiming in with comments and suggestions regarding
draft-deprecate-obsolete-kex :-)

I've tried to summarize everyone's comments below, hopefully grouped by
subject.
Apologies in advance if I missed anything (or misspelled names...), please
do reply to this thread :-)

My intent here is only to make sure we have a good record of the comments
made. I hope to follow up soon with a suggested way forward for the draft.

thanks,
Nimrod
===
Scott Fluhrer: We can only check for group structure if it's a safe prime,
and even for a safe prime it's too expensive. Suggest limiting groups to a
safelist.
Mike Ounsworth: Automated scanning tools routinely flag standardized FFDHE
groups.
Daniel Kahn Gillmor and Thom Wiggers: This is because of the Logjam paper
and precomputation. But they missed that the advice to generate your own DH
params was for 1024 bit parameters for sofware that didn't support anything
else.
Daniel Kahn Gillmor: Would be good to discourage non-standard groups, while
acknowledging the original argument for non-standard groups and explaining
why it doesn't motivate non-standard groups today.

Viktor Dukhovni: Postfix is far from the only one with non-standardized,
built-in default groups. Even for Postfix there are several groups,
depending on the version. Would be hard to build a list of widespread
groups.
Ben Kaduk: Can we start a registry for safe, widespread groups?

Martin Thomson: We tried using a safelist (that included only 7919 groups?
- Nimrod) but people use weird groups, and we couldn't turn that on.
David Benjamin: Agree, better to turn off FFDHE entirely.
The deployability issue with 7919 is also documented in
https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo/
https://mailarchive.ietf.org/arch/msg/tls/DzazUXCUZDUpVgBPVHOwatb65dA/

Uri Blumenthal: We should neither recommend or discourage non-standard
groups. Leave it to each operator to decide for themselves, they likely
know what they're doing.
Jonathan Hoyland and Martin Thomson: The pen-testing comment provides a
counterargument.

Uri Blumenthal: The draft is unnecessarily strict, from both deployment and
security points of view. Examples of stuff that should be retained: RSA,
FFDHE. PQ implications: all the NIST PQC winners and finalists are KEMs,
not KA - aka, similar to RSA rather than DH.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Tim Hollebeek]

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 
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 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

Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Erik Nygren]

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 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