[TLS] Re: ECH Proxy Mode

[Raghu Saxena]

Dear 涛叔,

On 9/10/24 11:00 PM, 涛叔 wrote:
If we can use the ECH-based proxy, we could transfer all these tasks 
to the server side. The only
task that the end user need to do is to setup a custom DoH URL, which 
is personalized to this user
only with auth data in the URL. The proxy list is maintained on the 
server side, and the server works

as both DoH and ECH-based SNI proxy.

Once the DoH has been set, the browser will query A//ECH records 
for one domain. The server
will response "fake" records according to the proxy list. The 
public_name of the fake ECHConfig will

be used to associate to the target domain and for auth.


You make a good point, thanks for clarifying. It is an interesting idea 
that the DoH operator can basically control the proxies which would be 
used per domain effectively. I'm going to give this idea a bit more 
thought, seems interesting.


By the way, you may be interested in this project: 
https://github.com/quininer/nosni-proxy , which has a similar idea, but 
instead to completely strip SNI, and relying on TLS interception. One 
could think of an alternative, basically like the Cloudflare MiTM model 
you mentioned, except self-hosted with certificates manually trusted. 
Then the DoH server would return the IP of this server, which would 
allow an ECH-TLS connection to it, but then performs a separate TLS 
handshake with the real origin server.


It is not as elegant as what you mentioned since now there is a need to 
manually trust certificates, but could still be an approach.


Regards,

Raghu Saxena



OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-ietf-tls-key-share-prediction next steps

[John Mattsson]

"To avoid downgrade attacks, the client MUST continue to send its full 
preferences in the supported_groups extension."

I don't think sending full preferences is a requirement in RFC 8446. As far as 
I can see there is no normative text in RFC 8446 forbidding the client to 
change the "supported_groups" extension based on unauthorized data such as the 
domain name, IP address, etc.

I think RFC 8446 should be update to state:

The client MUST NOT change the content of the "supported_groups" extension 
based on unauthenticated information.



"DNS responses are unauthenticated in many deployments."

I think the draft should describe the two cases "authenticated DNS" and 
"unauthenticated DNS" separately. The security considerations are very 
different.



I think the security considerations are way too optimistic and need major work.

"To avoid downgrade attacks, the client MUST continue to send its full 
preferences in the supported_groups extension."
"it is safe for clients to admit attacker control over the set of named groups 
preferred in key_share, provided supported_groups always reflects the true 
client preference."

This relies on servers ignoring performance and always chosing security. My 
understanding is that there is nothing in RFC 8446 saying that servers should 
behave like this. I think the only reasonable assumption in case of 
unauthenticated DNS is that the weakest group supported by the client will be 
used. This is problematic.

If a server is not doing point validation on P-256 (which we know happens), an 
attacker can find the private key. As TLS key shares unfortunatly are not 
ephemeral (TLS 1.3 allows reuse), an attacker can downgrade a real connection 
from x25519 to P-256 (which is unfortunatly MTI) and then completely compromise 
the connection with the key share private key it got from earlier connections 
with the server.

Cheers,
John

From: David Benjamin 
Date: Tuesday, 10 September 2024 at 23:41
To: 
Subject: [TLS] draft-ietf-tls-key-share-prediction next steps
Hi all,

Now that we're working through the Kyber to ML-KEM transition, TLS 1.3's 
awkwardness around key share prediction is becoming starkly visible. (It is 
difficult for clients to efficiently offer both Kyber and ML-KEM, but a hard 
transition loses PQ coverage for some clients. Kyber was a draft standard, just 
deployed by early adopters, so while not ideal, I think the hard transition is 
not the end of the world. ML-KEM is expected to be durable, so a 
coverage-interrupting transition to FancyNewKEM would be a problem.)

We adopted draft-ietf-tls-key-share-prediction in June to address this. There 
hasn't been a whole lot to do on it since. I've cut a new draft, 
draft-ietf-tls-key-share-prediction-01, with some very minor changes that were 
queued up in GitHub. I'd like to sort out next steps and move forward.

Beyond that, there are a couple of minor issues in the issue tracker. I don't 
believe either of these need to block getting a codepoint.
https://github.com/tlswg/tls-key-share-prediction/issues/4 - unless folks think 
otherwise, I plan to just leave this alone and close this
https://github.com/tlswg/tls-key-share-prediction/issues/7 - unless folks think 
otherwise, I plan to just leave this alone and not require the receiver to check

Finally, there's the question of downgrade protection:
https://github.com/tlswg/tls-key-share-prediction/issues/11

For some background if folks have forgotten, the original key share prediction 
draft included a ton of complexity to accommodate existing server behavior that 
would preferentially pick groups out of key_share even if an otherwise more 
preferred group was in supported_groups. Depending on what the server was 
trying to do there, this could be perfectly fine (if the server believes the 
groups are comparable in security) or a downgrade risk (if the server actually 
believed they were in different security classes---PQ vs classical---but 
implemented a key_share-first selection algorithm anyway). Pre-adoption, my 
original draft took the position that it was ambiguous and we cannot safely 
assume the server knew what it was doing. It designed a scheme to clarify the 
semantics going forward and use codepoints to ratchet in whether the server 
implemented the new semantics.
https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html

After WG discussion, I think we broadly concluded the semantics were actually 
already present in RFC 8446, and it was not worth the trouble to second-guess 
the servers here. That led to the much simpler draft, which simply discusses 
why this is OK in security considerations:
https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations

As I wrote that text, I unsurprisingly agree with and am fine with this 
outcome. :-) But there was some chatter about it in the adoption thread (see 
GitHub link), so I filed the issue so we continued 

[TLS] Re: draft-ietf-tls-key-share-prediction next steps

[Ilari Liusvaara]

On Wed, Sep 11, 2024 at 10:13:55AM +0400, Loganaden Velvindron wrote:
> On Wed, 11 Sept 2024 at 01:40, David Benjamin  wrote:
> >
> > Hi all,
> >
> > Now that we're working through the Kyber to ML-KEM transition, TLS
> > 1.3's awkwardness around key share prediction is becoming starkly
> > visible. (It is difficult for clients to efficiently offer both
> > Kyber and ML-KEM, but a hard transition loses PQ coverage for some
> > clients. Kyber was a draft standard, just deployed by early
> > adopters, so while not ideal, I think the hard transition is not
> > the end of the world. ML-KEM is expected to be durable, so a
> > coverage-interrupting transition to FancyNewKEM would be a problem.)
> >
> 
> Can you detail a little bit more in terms of numbers ?
> -Did you discover that handshakes are failing because of the larger
> ClientHello ?
> -Some web clients aren't auto-updating ?

The outright failures because of larger ClientHello are actually web
server issues. However, even ignoring any hard failures, larger
ClientHello can cause performance issues.

The most relevant of the issues is tldr.fail (https://tldr.fail/),
where web server ends up unable to deal with TCP-level fragmentation
of ClientHello. Even one PQ key (1216 bytes) fills vast manjority of
TCP fragment (and other stuff in ClientHello can easily push it over,
as upper limit is around 1430-1460 bytes). There is no way to fit two
PQ keys.

Then some web servers have ClientHello buffer limits. However, these
limits are almost invariably high enough that one could fit two PQ
keys. IIRC, some research years back came to conclusion that the
maximum tolerable key size is about 3.3kB, which is almost enough for
three PQ keys.

Then there are a lot of web servers that are unable to deal with TLS-
level fragmentation of ClientHello. However, this is not really
relevant, given that the limit is 16kB, which is easily enough for
10 PQ keys and more than enough to definitely cause performance issues
with TCP.


And it is possible for web server to offer both, so even with hard
client transition both old and new clients get PQ coverage.




-Ilari

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ECH Proxy Mode

[涛叔]

Dear Raghu,

The MiTM solution may works for self-host, because the user controls both the 
browser and
the proxy node. However, it is not acceptable for public proxy, because the 
middle node
could see all the plain traffic between the user and the target, which is a far 
more serious
problem than the leak of SNI.

The only obstacle of my envisioned ECH-based SNI proxy is that the server side 
accept confirmation
must be placed in the SH.random field, which will be further used to generate 
the master secret.
As a result, the middle proxy node can't respond this confirmation on  behalf 
of the backed server.

The ECH-based SNI proxy is just a possible by-product of ECH. It's not a big 
problem if we
can not implement such proxy. However, my real concern is the deployment rate 
of the current draft.

The current design requires both the client and backend server to be modified 
to be ECH-aware.

For solo web site, as the administrator has the full control and there is no 
inter node, they may
upgrade quickly.

But there are far too many sites using some proxy service, for example, 
Cloudflare, AWS ALB, etc.
For stability consideration, service provider like AWS does not upgrade their 
infrastructure very quickly.
If web site use AWS LB as their TLS terminal edge server, it may cost too long 
time to deploy ECH.

Apart from technical issues, deploy ECH does almost no benefit to this 
business. I doubt if they are
interested in ECH.

On the other hand, let's recall the origin of the server side confirmation.

According to the original discussion 
https://github.com/tlswg/draft-ietf-tls-esni/issues/274

> In the current spec, the server provides no indication of whether the inner 
> or outer ClientHello (CH) was used. This means the client must do trial 
> decryption to make this determination, which creates complexity and 
> potentially raises security concerns. 

It seems that the main consideration of the accept_confirmation is just to 
simplify the client side logic.
This simplification may cause a slow deployment of ECH. I am wondering if it 
really make sense.

The ECH is very complicated itself. The purpose of such an complicated protocol 
is to
protect the privacy of the Internet, so we should in favor of the easy 
deployment instead of
of the simplified implementation. If the simplification is the first 
consideration, the ECH should not
be considered at all.

> On Sep 11, 2024, at 15:16, Raghu Saxena  wrote:
> 
> By the way, you may be interested in this project: 
> https://github.com/quininer/nosni-proxy , which has a similar idea, but 
> instead to completely strip SNI, and relying on TLS interception. One could 
> think of an alternative, basically like the Cloudflare MiTM model you 
> mentioned, except self-hosted with certificates manually trusted. Then the 
> DoH server would return the IP of this server, which would allow an ECH-TLS 
> connection to it, but then performs a separate TLS handshake with the real 
> origin server.
> 
> It is not as elegant as what you mentioned since now there is a need to 
> manually trust certificates, but could still be an approach.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ECH Proxy Mode

[A A]

- all I don't think need to use random, we can use Session ID, which is deprecated since TLS 1.3. Random is used to derive master key, AFAIK.  11.09.2024, 17:29, "涛叔" :Dear Raghu, The MiTM solution may works for self-host, because the user controls both the browser andthe proxy node. However, it is not acceptable for public proxy, because the middle nodecould see all the plain traffic between the user and the target, which is a far more seriousproblem than the leak of SNI. The only obstacle of my envisioned ECH-based SNI proxy is that the server side accept confirmationmust be placed in the SH.random field, which will be further used to generate the master secret.As a result, the middle proxy node can't respond this confirmation on  behalf of the backed server. The ECH-based SNI proxy is just a possible by-product of ECH. It's not a big problem if wecan not implement such proxy. However, my real concern is the deployment rate of the current draft. The current design requires both the client and backend server to be modified to be ECH-aware. For solo web site, as the administrator has the full control and there is no inter node, they mayupgrade quickly. But there are far too many sites using some proxy service, for example, Cloudflare, AWS ALB, etc.For stability consideration, service provider like AWS does not upgrade their infrastructure very quickly.If web site use AWS LB as their TLS terminal edge server, it may cost too long time to deploy ECH. Apart from technical issues, deploy ECH does almost no benefit to this business. I doubt if they areinterested in ECH. On the other hand, let's recall the origin of the server side confirmation. According to the original discussion https://github.com/tlswg/draft-ietf-tls-esni/issues/274 > In the current spec, the server provides no indication of whether the inner or outer ClientHello (CH) was used. This means the client must do trial decryption to make this determination, which creates complexity and potentially raises security concerns.  It seems that the main consideration of the accept_confirmation is just to simplify the client side logic.This simplification may cause a slow deployment of ECH. I am wondering if it really make sense. The ECH is very complicated itself. The purpose of such an complicated protocol is toprotect the privacy of the Internet, so we should in favor of the easy deployment instead ofof the simplified implementation. If the simplification is the first consideration, the ECH should notbe considered at all. On Sep 11, 2024, at 15:16, Raghu Saxena  wrote: By the way, you may be interested in this project: https://github.com/quininer/nosni-proxy , which has a similar idea, but instead to completely strip SNI, and relying on TLS interception. One could think of an alternative, basically like the Cloudflare MiTM model you mentioned, except self-hosted with certificates manually trusted. Then the DoH server would return the IP of this server, which would allow an ECH-TLS connection to it, but then performs a separate TLS handshake with the real origin server.It is not as elegant as what you mentioned since now there is a need to manually trust certificates, but could still be an approach.,___TLS mailing list -- tls@ietf.orgTo unsubscribe send an email to tls-le...@ietf.org___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ECH Proxy Mode

[涛叔]

According to https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3

A client which receives a legacy_session_id_echo field that does not match what
it sent in the ClientHello MUST abort the handshake with an "illegal_parameter" 
alert.

So we can't use the legacy_session_id_echo of SH.

> On Sep 11, 2024, at 17:35, A A  wrote:
> 
> I don't think need to use random, we can use Session ID, which is deprecated 
> since TLS 1.3. Random is used to derive master key, AFAIK.
> 

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ECH Proxy Mode

[A A]

How about early data? I think it's big enough to carry an inner Client/Server Hello. 11.09.2024, 17:45, "涛叔" :According to https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3 A client which receives a legacy_session_id_echo field that does not match whatit sent in the ClientHello MUST abort the handshake with an "illegal_parameter" alert. So we can't use the legacy_session_id_echo of SH. On Sep 11, 2024, at 17:35, A A  wrote: I don't think need to use random, we can use Session ID, which is deprecated since TLS 1.3. Random is used to derive master key, AFAIK.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

[Richard Barnes]

+1 to Sean here, it would be easier to evaluate this with a document in
hand.  And in particular, a list of ways that people find mTLS is failing
in practice.

I am generally skeptical of this idea, at least as a TLS WG item.  In pure
TLS terms, there is no such thing as "one-way TLS" or "mutually
authenticated TLS" -- every TLS handshake supports both modes, and every
TLS handshake could be mutually-authenticated until the server declines to
send a CertificateRequest or the client declines to provide a Certificate
in response.

In other words, I disagree with Olle's and John's assertion that there's no
definition for mTLS.  There is: "TLS where the server sends a
CertificateRequest and the client sends a Certificate"  Any TLS handshake
where that happens is mutually authenticated.

An RFC defining "mTLS" that adds a bunch of extra requirements on top of
the above will just deepen the confusion.  "In this scheme, we use mTLS
between these two machines" ... "Oho, but you don't color the bits yellow
and configure the PKI like RFC  says you need to do for True mTLS".

If there's anything to be done here, it's recommendations for configuring
TLS stacks to be compatible, probably largely focused on PKI
considerations.  Informational, not Proposed Standard; UTA, not TLS.  And
even then, we need a lot more precision on the problems to be solved.

--Richard

On Tue, Sep 10, 2024 at 11:21 AM Sean Turner  wrote:

> Mark,
>
> Hi! I’d suggest writing the I-D [1] and then we (the royal we here) can
> figure out where it goes; could be ALLDISPATCH then TLS or UTA depending on
> ALLDISPATCH outcome.  Additionally, discussing at the ALLDISPATCH session
> would get much a wider audience, which I think would help in general.
>
> spt
>
> [1] Submission deadline for IETF 121 is 21 October.
>
> > On Sep 9, 2024, at 14:42, Mark Robinson  wrote:
> >
> > I've been doing a lot of work lately to support organizations that do
> mTLS between each other. The problem I've found is that there is a huge
> amount of ignorance on TLS in general and mTLS in particular.
> >
> > Would it be appropriate to write an RFC on how to make
> cross-organization mTLS work reliably and at scale? Would this
> group/mailing list be the right people to work with to make that happen?
> >
> > Mark
> > ___
> > TLS mailing list -- tls@ietf.org
> > To unsubscribe send an email to tls-le...@ietf.org
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

[Joseph Salowey]

There is also discussion of "mTLS" in the WIMSE working group as it relates
to workload identity.  There are some things that are unique to that
environment, but in general it is not too much different from other use
cases.

Joe

On Wed, Sep 11, 2024 at 7:24 AM Richard Barnes  wrote:

> +1 to Sean here, it would be easier to evaluate this with a document in
> hand.  And in particular, a list of ways that people find mTLS is failing
> in practice.
>
> I am generally skeptical of this idea, at least as a TLS WG item.  In pure
> TLS terms, there is no such thing as "one-way TLS" or "mutually
> authenticated TLS" -- every TLS handshake supports both modes, and every
> TLS handshake could be mutually-authenticated until the server declines to
> send a CertificateRequest or the client declines to provide a Certificate
> in response.
>
> In other words, I disagree with Olle's and John's assertion that there's
> no definition for mTLS.  There is: "TLS where the server sends a
> CertificateRequest and the client sends a Certificate"  Any TLS handshake
> where that happens is mutually authenticated.
>
> An RFC defining "mTLS" that adds a bunch of extra requirements on top of
> the above will just deepen the confusion.  "In this scheme, we use mTLS
> between these two machines" ... "Oho, but you don't color the bits yellow
> and configure the PKI like RFC  says you need to do for True mTLS".
>
> If there's anything to be done here, it's recommendations for configuring
> TLS stacks to be compatible, probably largely focused on PKI
> considerations.  Informational, not Proposed Standard; UTA, not TLS.  And
> even then, we need a lot more precision on the problems to be solved.
>
> --Richard
>
> On Tue, Sep 10, 2024 at 11:21 AM Sean Turner  wrote:
>
>> Mark,
>>
>> Hi! I’d suggest writing the I-D [1] and then we (the royal we here) can
>> figure out where it goes; could be ALLDISPATCH then TLS or UTA depending on
>> ALLDISPATCH outcome.  Additionally, discussing at the ALLDISPATCH session
>> would get much a wider audience, which I think would help in general.
>>
>> spt
>>
>> [1] Submission deadline for IETF 121 is 21 October.
>>
>> > On Sep 9, 2024, at 14:42, Mark Robinson  wrote:
>> >
>> > I've been doing a lot of work lately to support organizations that do
>> mTLS between each other. The problem I've found is that there is a huge
>> amount of ignorance on TLS in general and mTLS in particular.
>> >
>> > Would it be appropriate to write an RFC on how to make
>> cross-organization mTLS work reliably and at scale? Would this
>> group/mailing list be the right people to work with to make that happen?
>> >
>> > Mark
>> > ___
>> > TLS mailing list -- tls@ietf.org
>> > To unsubscribe send an email to tls-le...@ietf.org
>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-ietf-tls-key-share-prediction next steps

[David Benjamin]

On Wed, Sep 11, 2024 at 3:58 AM Ilari Liusvaara 
wrote:

> On Wed, Sep 11, 2024 at 10:13:55AM +0400, Loganaden Velvindron wrote:
> > On Wed, 11 Sept 2024 at 01:40, David Benjamin 
> wrote:
> > >
> > > Hi all,
> > >
> > > Now that we're working through the Kyber to ML-KEM transition, TLS
> > > 1.3's awkwardness around key share prediction is becoming starkly
> > > visible. (It is difficult for clients to efficiently offer both
> > > Kyber and ML-KEM, but a hard transition loses PQ coverage for some
> > > clients. Kyber was a draft standard, just deployed by early
> > > adopters, so while not ideal, I think the hard transition is not
> > > the end of the world. ML-KEM is expected to be durable, so a
> > > coverage-interrupting transition to FancyNewKEM would be a problem.)
> > >
> >
> > Can you detail a little bit more in terms of numbers ?
> > -Did you discover that handshakes are failing because of the larger
> > ClientHello ?
> > -Some web clients aren't auto-updating ?
>
> The outright failures because of larger ClientHello are actually web
> server issues. However, even ignoring any hard failures, larger
> ClientHello can cause performance issues.
>
> The most relevant of the issues is tldr.fail (https://tldr.fail/),
> where web server ends up unable to deal with TCP-level fragmentation
> of ClientHello. Even one PQ key (1216 bytes) fills vast manjority of
> TCP fragment (and other stuff in ClientHello can easily push it over,
> as upper limit is around 1430-1460 bytes). There is no way to fit two
> PQ keys.
>
> Then some web servers have ClientHello buffer limits. However, these
> limits are almost invariably high enough that one could fit two PQ
> keys. IIRC, some research years back came to conclusion that the
> maximum tolerable key size is about 3.3kB, which is almost enough for
> three PQ keys.
>
> Then there are a lot of web servers that are unable to deal with TLS-
> level fragmentation of ClientHello. However, this is not really
> relevant, given that the limit is 16kB, which is easily enough for
> 10 PQ keys and more than enough to definitely cause performance issues
> with TCP.
>

Yup. Even adding one PQ key was a noticeable size cost (we still haven't
shipped Kyber/ML-KEM to mobile Chrome because the performance regression
was more prominent) so, yeah, we definitely do not want to send two PQ keys
in the initial ClientHello. Sending them in supported_groups is cheap, but
as those options take a RTT hit, they're not really practical. Hence all
the key-share-prediction work. (For some more background, so the earlier WG
discussions around this draft, before it was adopted.)


> And it is possible for web server to offer both, so even with hard
> client transition both old and new clients get PQ coverage.
>

Yup, although that transition strategy requires that *every* PQ server move
before *any* client moves, if your goal is to never interrupt coverage.
That's not really a viable transition strategy in the long run, once PQ
becomes widely deployed.

David
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: I-D Action: draft-ietf-tls-deprecate-obsolete-kex-05.txt

[Christian Buchgraber]

I found spelling errors in the last draft version and fixed them in this pull 
request: https://github.com/tlswg/draft-deprecate-obsolete-kex/pull/18

I also added wildcard cipher suite references in the security considerations 
chapter for better understanding. TLS_DH_* was already referenced in that 
chapter.

Cheers,
Chris
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-ietf-tls-key-share-prediction next steps

[David Benjamin]

Thanks for the comments! Responses inline.

On Wed, Sep 11, 2024 at 3:39 AM John Mattsson 
wrote:

> "To avoid downgrade attacks, the client MUST continue to send its full
> preferences in the supported_groups extension."
>
>
>
> I don't think sending full preferences is a requirement in RFC 8446. As
> far as I can see there is no normative text in RFC 8446 forbidding the
> client to change the "supported_groups" extension based on unauthorized
> data such as the domain name, IP address, etc.
>

There is also no normative text in RFC 8446 forbidding the client from
changing the cipher suites or any other parameter based on such data.
Rather, RFC 8446 simply gives the semantics of the fields, and implementers
can then fill in those fields based on those documented semantics:

>When sent by the client, the "supported_groups" extension indicates
>   the named groups which the client supports for key exchange, ordered
>   from most preferred to least preferred.

That text is exactly the requirement you mention. The "supported_groups"
extension does not indicate the named groups which the client thinks is
most likely or anything like that. It indicates the ones the client
supports.


> I think RFC 8446 should be update to state:
>
>
>
> The client MUST NOT change the content of the "supported_groups" extension
> based on unauthenticated information.
>

It doesn't make a whole lot of sense to specifically call out
supported_groups when this is how every parameter works. Rather, I think
what would be more appropriate is a discussion about how TLS's downgrade
protection is relative to the ClientHello and that attacks with influence
on the ClientHello can influence the selection accordingly. This includes
key_share. Rather, the reason it's OK for key_share is that key_shares
semantics make this tolerable, as Security Considerations discusses.


> "DNS responses are unauthenticated in many deployments."
>
>
>
> I think the draft should describe the two cases "authenticated DNS" and 
> "unauthenticated
> DNS" separately. The security considerations are very different.
>

The original version of the draft separated them. This was removed based on
WG feedback. I think that feedback was correct.

DNS authentication is not the same as TLS authentication. Then you need to
reason about the kind of DNS-level authentication and how it compares to
the (usually X.509-based) authentication that you've configured in TLS, and
whether one is substitutable for the other. All that is unnecessary here.
In the simpler model, we've simply defined away the problem, which means
that we're not expending any particular effort to accommodate
unauthenticated DNS. If it works for unauthenticated DNS, it will also work
for authenticated DNS, and we do not need this more complex analysis.


> I think the security considerations are way too optimistic and need major
> work.
>
>
>
> "To avoid downgrade attacks, the client MUST continue to send its full
> preferences in the supported_groups extension."
>
> "it is safe for clients to admit attacker control over the set of named
> groups preferred in key_share, provided supported_groups always reflects
> the true client preference."
>
>
>
> This relies on servers ignoring performance and always chosing security.
> My understanding is that there is nothing in RFC 8446 saying that servers
> should behave like this. I think the only reasonable assumption in case of
> unauthenticated DNS is that the weakest group supported by the client will
> be used. This is problematic.
>

This relies on servers correctly implementing its desired policy, based on
the documented semantics of the ClientHello, as specified in RFC 8446.

If the server believes that all supported named groups are of comparable
security class (quite defensible if it only implements ECDH key shares!),
the server could reasonably prioritize HRR avoidance. If the server
believes some named groups (e.g. PQ) are in a different category from
others (e.g. ECDH), RFC 8446's text implies the server must consider those
categories before HRR avoidance.

You are right that this exercises an assumption on the server that wasn't
previously as well-exercised. Like I said in the email, the earliest
versions of the draft tried to avoid exercising this and took a much more
conservative position, at the expense of considerable complexity in the
draft. Is that the version you would prefer?

I'm OK with either option, but WG discussion prior to adoption seemed to
clearly prefer this version. I also prefer this version, but not very
strongly, so if the WG has changed its mind wants to go back to the other
one, or if there is another proposal to solve this, that's fine by me! I
started this thread purely because the draft has sat for a while now
without another proposal coming up, so it's about time we progress the
topic.


> If a server is not doing point validation on P-256 (which we know happens),
> an attacker can find the private key. As TLS key shares 

[TLS] Early codepoint allocation for tls_flags

[David Benjamin]

Hi all,

It was suggested that sending this more broadly might be helpful. I'm
looking to implement draft-ietf-tls-cross-sni-resumption, which depends
on draft-ietf-tls-tlsflags. Both WG drafts in the data tracker appear to be
in "Waiting for Implementation" state. Looking back in the list, it seems
they both completed WGLC in August 2021

However, they are not currently implementable because we do not have a
codepoint for tls_flags, so we have a bit of a deadlock. I think we should
break this deadlock, and get an early codepoint allocation, so we can
progress those drafts.

Looks like this previously came up in February 2022, so I guess it slipped
through. :-)
https://mailarchive.ietf.org/arch/msg/tls/jLn0oGfae1sAFtLadYcMHW4nfcQ/

David
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

[Viktor Dukhovni]

On Wed, Sep 11, 2024 at 10:24:06AM -0400, Richard Barnes wrote:

> In other words, I disagree with Olle's and John's assertion that there's no
> definition for mTLS.  There is: "TLS where the server sends a
> CertificateRequest and the client sends a Certificate"  Any TLS handshake
> where that happens is mutually authenticated.
> 
> An RFC defining "mTLS" that adds a bunch of extra requirements on top of
> the above will just deepen the confusion.  "In this scheme, we use mTLS
> between these two machines" ... "Oho, but you don't color the bits yellow
> and configure the PKI like RFC  says you need to do for True mTLS".

Though one might reasonably argue that any post handshake authentication
scheme that performs channel binding is also "mTLS", and is often
preferable (sometimes in multiple ways).  Sadly most post-handshake
authentication approaches do not perform channel binding.

-- 
Viktor.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Early codepoint allocation for tls_flags

[Watson Ladd]

To the extent it matters I support allocation so we can roll things
out and publish. TLS flags in particular has a lot depending on it.



-- 
Astra mortemque praestare gradatim

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

[Andrei Popov]

I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes 
confusion where customers ask whether "mTLS" is a different protocol or a 
specific TLS implementation? However, it can be argued that this unfortunate 
term has already taken root. 

A UTA document discussing challenges of using TLS with client authentication 
might be helpful, depending on the quality of the document.

Cheers,

Andrei

-Original Message-
From: Viktor Dukhovni  
Sent: Wednesday, September 11, 2024 10:37 AM
To: tls@ietf.org
Subject: [EXTERNAL] [TLS] Re: Is there any interest in an RFC on how to do 
cross-organization mTLS?

On Wed, Sep 11, 2024 at 10:24:06AM -0400, Richard Barnes wrote:

> In other words, I disagree with Olle's and John's assertion that 
> there's no definition for mTLS.  There is: "TLS where the server sends 
> a CertificateRequest and the client sends a Certificate"  Any TLS 
> handshake where that happens is mutually authenticated.
> 
> An RFC defining "mTLS" that adds a bunch of extra requirements on top 
> of the above will just deepen the confusion.  "In this scheme, we use 
> mTLS between these two machines" ... "Oho, but you don't color the 
> bits yellow and configure the PKI like RFC  says you need to do for True 
> mTLS".

Though one might reasonably argue that any post handshake authentication scheme 
that performs channel binding is also "mTLS", and is often preferable 
(sometimes in multiple ways).  Sadly most post-handshake authentication 
approaches do not perform channel binding.

-- 
Viktor.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

[Peter Gutmann]

Andrei Popov  writes:

>I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes
>confusion where customers ask whether "mTLS" is a different protocol or a
>specific TLS implementation? However, it can be argued that this unfortunate
>term has already taken root.

+1, Richard pretty much said everything I have concerns about but saved me a
lot of typing.  mTLS *is* TLS, there's no need to give it a special name for
marketing(?) purposes.

Having said that, I'd have no problems with a "TLS Profile for xxx", which is
what it really seems to be.

(And I'll add an obligatory comment that what (m)TLS does isn't mutual
authentication, it's unidirectional authentication in both directions, but
that boat has long since sailed.  If you wanted to have actual mTLS it'd have
to use PSK).

Peter.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org