[TLS]Re: HTTPS-RR and TLS

[Ilari Liusvaara]

On Tue, May 21, 2024 at 01:27:29AM +0100, Stephen Farrell wrote:
>
> 
> What HTTPS RR parameters do we expect will see regular changes,
> and controlled by whom?
> 
> It seems fairly clear that ECHConfig values will be changed
> often, e.g. hourly, which I think motivates the wkech thing,
> but I'm unclear how often other bits of HTTPS RRs might
> change and who may be in charge of those in real deployments.
> 
> My mental picture is something like:
> 
> what, changes how often, controlled by whom
> ech, maybe hourly, client-facing server admin
> alpn, rarely, client-facing server admin
> tls-supported-groups, rarely, client-facing server admin
> ipXhints, unpredictable, DNS admin?
> 
> Does that look kinda right? Are there other things to
> consider now?

Things get more complicated if server is behind gateway, because some
alpn values are incompatible with such setup (especially h3). Those need
to be filtered out. And another nice-to-have is sanity-checking ech
public name (that it points to the correct machine). Gateways do not
need to care about groups, so tls-supported-groups can be just taken
from server.

Then there is possibility that IPv4 has gateway but IPv6 is direct-
routed. Then HTTPS entires need to be duplicated with potentially
different alpn values (filtered for IPv4, full for IPv6). HTTP/3
requires IPv6 in such setup (as opposed to not working at all with
server entirely behind gateway).




-Ilari

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

[TLS]Re: HTTPS-RR and TLS

[Stephen Farrell]

Hiya,

On 21/05/2024 08:53, Ilari Liusvaara wrote:

Then there is possibility that IPv4 has gateway but IPv6 is direct-
routed. Then HTTPS entires need to be duplicated with potentially
different alpn values (filtered for IPv4, full for IPv6). HTTP/3
requires IPv6 in such setup (as opposed to not working at all with
server entirely behind gateway).


Do we have any info on tests with esp browsers where there
is >1 HTTPS RR published for the same name? Last I checked
(but it was a good while back), browsers didn't handle that
well, though hopefully that's improved since.

Ta,
S.


OpenPGP_0xE4D8E9F997A833DD.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: Adoption Call for draft-davidben-tls-key-share-prediction

[Eric Rescorla]

I agree that it's attractive to be able to hint in the HTTPS RR, but I'm
less sure about addressing the basic insecurity of the DNS channel with the
approach this draft takes. I don't have a complete thought here, but what
if we were to somehow fold the hint into the handshake transcript? I
suppose we can sort this out post-adoption, but I'd like the question to be
on the table.

-Ekr


On Fri, May 3, 2024 at 3:05 PM Joseph Salowey  wrote:

> This is a working group call for adoption
> for draft-davidben-tls-key-share-prediction.  This document was presented
> at IET 118 and has undergone some revision based on feedback since then.
> The current draft is available here:
> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
> Please read the document and indicate if and why you support or do not
> support adoption as a TLS working group item. If you support adoption
> please, state if you will help review and contribute text to the document.
> Please respond to this call by May 20, 2024.
>
> Thanks,
>
> Joe, Deidre, and Sean
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction

[David Benjamin]

Off the cuff, folding it into the transcript sounds tricky, since existing
TLS servers won't know to do it, and, as with any other DNS hints, we need
to accommodate the DNS being out of sync with the server. It'll also be
more difficult to deploy due to needing changes in the TLS stack and
generally require much, much tighter coordination between DNS and TLS. I'd
like for that coordination to be more viable (see my comments on the
.well-known draft), but I don't think we're there yet.

But I'm certainly open to continue discussing it and this problem space!
The original version of the draft actually tried a lot harder to handle the
downgrade story. Rather than mess with the transcript, it defined away all
the negotiation algorithms where this would be a problem and keyed the
NamedGroup codepoints to know when you could be guaranteed of the narrower
server behavior.

My read of the feedback was that people thought this was an unnecessary
complication and that servers doing a key-share-first selection were doing
so intentionally because they believed the options roughly equivalent. So I
took all that out and replaced it with text to that effect.

David


On Tue, May 21, 2024, 08:54 Eric Rescorla  wrote:

> I agree that it's attractive to be able to hint in the HTTPS RR, but I'm
> less sure about addressing the basic insecurity of the DNS channel with the
> approach this draft takes. I don't have a complete thought here, but what
> if we were to somehow fold the hint into the handshake transcript? I
> suppose we can sort this out post-adoption, but I'd like the question to be
> on the table.
>
> -Ekr
>
>
> On Fri, May 3, 2024 at 3:05 PM Joseph Salowey  wrote:
>
>> This is a working group call for adoption
>> for draft-davidben-tls-key-share-prediction.  This document was presented
>> at IET 118 and has undergone some revision based on feedback since then.
>> The current draft is available here:
>> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
>> Please read the document and indicate if and why you support or do not
>> support adoption as a TLS working group item. If you support adoption
>> please, state if you will help review and contribute text to the document.
>> Please respond to this call by May 20, 2024.
>>
>> Thanks,
>>
>> Joe, Deidre, and Sean
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> 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: Adoption Call for draft-davidben-tls-key-share-prediction

[A A]

In my opinion, to prevent downgrade attack, server MUST or SHOULD using DNSSEC when announcing DNS record.21.05.2024, 21:48, "David Benjamin" :Off the cuff, folding it into the transcript sounds tricky, since existing TLS servers won't know to do it, and, as with any other DNS hints, we need to accommodate the DNS being out of sync with the server. It'll also be more difficult to deploy due to needing changes in the TLS stack and generally require much, much tighter coordination between DNS and TLS. I'd like for that coordination to be more viable (see my comments on the .well-known draft), but I don't think we're there yet.But I'm certainly open to continue discussing it and this problem space! The original version of the draft actually tried a lot harder to handle the downgrade story. Rather than mess with the transcript, it defined away all the negotiation algorithms where this would be a problem and keyed the NamedGroup codepoints to know when you could be guaranteed of the narrower server behavior.My read of the feedback was that people thought this was an unnecessary complication and that servers doing a key-share-first selection were doing so intentionally because they believed the options roughly equivalent. So I took all that out and replaced it with text to that effect.DavidOn Tue, May 21, 2024, 08:54 Eric Rescorla  wrote:I agree that it's attractive to be able to hint in the HTTPS RR, but I'm less sure about addressing the basic insecurity of the DNS channel with the approach this draft takes. I don't have a complete thought here, but what if we were to somehow fold the hint into the handshake transcript? I suppose we can sort this out post-adoption, but I'd like the question to be on the table.-EkrOn Fri, May 3, 2024 at 3:05 PM Joseph Salowey  wrote:This is a working group call for adoption for draft-davidben-tls-key-share-prediction.  This document was presented at IET 118 and has undergone some revision based on feedback since then.  The current draft is available here: https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.  Please read the document and indicate if and why you support or do not support adoption as a TLS working group item. If you support adoption please, state if you will help review and contribute text to the document.  Please respond to this call by May 20, 2024. Thanks,Joe, Deidre, and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

,___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: Adoption Call for draft-davidben-tls-key-share-prediction

[David Benjamin]

Servers using DNSSEC won't help unless the client only honors the hint over
DNSSEC, and we do not live in a universe where DNSSEC succeeded to the
point that that's remotely viable.

I think that too can be discussed in detail post adoption, but I think such
a change would negate the value of this whole draft.

On Tue, May 21, 2024, 09:56 A A  wrote:

> In my opinion, to prevent downgrade attack, server MUST or SHOULD using
> DNSSEC when announcing DNS record.
>
>
> 21.05.2024, 21:48, "David Benjamin" :
>
> Off the cuff, folding it into the transcript sounds tricky, since existing
> TLS servers won't know to do it, and, as with any other DNS hints, we need
> to accommodate the DNS being out of sync with the server. It'll also be
> more difficult to deploy due to needing changes in the TLS stack and
> generally require much, much tighter coordination between DNS and TLS. I'd
> like for that coordination to be more viable (see my comments on the
> .well-known draft), but I don't think we're there yet.
>
> But I'm certainly open to continue discussing it and this problem space!
> The original version of the draft actually tried a lot harder to handle the
> downgrade story. Rather than mess with the transcript, it defined away all
> the negotiation algorithms where this would be a problem and keyed the
> NamedGroup codepoints to know when you could be guaranteed of the narrower
> server behavior.
>
> My read of the feedback was that people thought this was an unnecessary
> complication and that servers doing a key-share-first selection were doing
> so intentionally because they believed the options roughly equivalent. So I
> took all that out and replaced it with text to that effect.
>
> David
>
>
> On Tue, May 21, 2024, 08:54 Eric Rescorla  wrote:
>
> I agree that it's attractive to be able to hint in the HTTPS RR, but I'm
> less sure about addressing the basic insecurity of the DNS channel with the
> approach this draft takes. I don't have a complete thought here, but what
> if we were to somehow fold the hint into the handshake transcript? I
> suppose we can sort this out post-adoption, but I'd like the question to be
> on the table.
>
> -Ekr
>
>
> On Fri, May 3, 2024 at 3:05 PM Joseph Salowey  wrote:
>
> This is a working group call for adoption
> for draft-davidben-tls-key-share-prediction.  This document was presented
> at IET 118 and has undergone some revision based on feedback since then.
> The current draft is available here:
> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
> Please read the document and indicate if and why you support or do not
> support adoption as a TLS working group item. If you support adoption
> please, state if you will help review and contribute text to the document.
> Please respond to this call by May 20, 2024.
>
> Thanks,
>
> Joe, Deidre, and Sean
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> ___
> 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: [rfc9147] Clarification on DTLS 1.3 CID Retirement and Usage

[Kristijan Sedlak]

Thank you for your comments.

Since I hadn't received any feedback, I shifted my focus to other issues and 
needed some time to revisit this topic.

I've realized that CIDs in DTLS 1.3 are loosely defined, and the more I 
investigate, the more I understand that this is actually very beneficial, much 
better than having explicit (redundant) retirement mechanisms (e.g QUIC). With 
a smart approach and sophisticated cryptography, CIDs as currently defined 
could be the optimal framework. I still need to conduct more research, but I 
believe that the specifications as they stand are sufficient. Sometimes, it's 
difficult to imagine the right solution, but overall, I think I now understand 
how to move forward.

Thank you.
Kristijan

> On 16 Apr 2024, at 15:54, Tschofenig, Hannes  
> wrote:
> 
> Hi Kristijan, 
>  
> searching through the mailing list I found this mail. So, sorry for the late 
> response.
>  
> The CID design in DTLS 1.3 has not been focused on multi-homing use cases. It 
> was not a design goal; you have to design on an extension in the style of 
> what is currently happening with QUIC or what was previously done with MOBIKE.
>  
> Ciao
> Hannes
>  
> From: TLS  On Behalf Of Kristijan Sedlak
> Sent: Sunday, December 10, 2023 11:50 AM
> To:  
> Subject: [TLS] [rfc9147] Clarification on DTLS 1.3 CID Retirement and Usage
>  
> Dear IETF TLS Working Group,
> 
> I am reaching out to seek clarification on specific aspects of Connection ID 
> (CID) management in DTLS 1.3, as detailed in RFC 9147.
> 
> The current specification delineates the process for issuing new CIDs via a 
> NewConnectionId message. However, the methodology for retiring old CIDs seems 
> subject to various interpretations.
> 
> Is it correct to assume that an endpoint dictates the number of active CIDs 
> it manages and that CIDs should be utilized in the sequence they are 
> provided? For example, if the initial negotiated CID is 0 and an endpoint 
> subsequently issues NewConnectionId with CIDs 1, 2, and 3, my interpretation 
> is that upon receiving the first datagram from a new path (which is also 
> applicable for an existing path), the records should ideally be tagged with 
> the next CID (1, 2, or 3) rather than CID 0. This approach suggests that upon 
> the reception of a higher CID, lower CIDs should be considered retired and 
> later removed.
> 
> This understanding implies that CIDs in DTLS 1.3 are not designed for 
> multipath operations, and it is anticipated that only one path (one CID) 
> would be active at a given time. Could you please confirm if this 
> interpretation is in alignment with the intended specifications, or offer 
> additional insights into the appropriate management of CIDs in DTLS 1.3? 
> Including such clarification in the RFC would be invaluable in mitigating 
> potential confusion.
> 
> Thank you.
> Kristijan
> 

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

[TLS]Re: HTTPS-RR and TLS

[Ilari Liusvaara]

On Tue, May 07, 2024 at 08:05:05AM -0700, David Benjamin wrote:
> 
> draft-ietf-tls-wkech seems like a good model for this, but it is currently
> written specifically for ECH. What are your thoughts on generalizing that
> document to cover other cases as well?
> https://github.com/sftcd/wkesni/issues/14
> 
> We might also think about the extension model for that document. Does each
> SvcParamKey opt into use with the document, with its own JSON key and text
> describing how to map it, or should we just use the presentation syntax and
> import it all en masse? (I'm not sure. The latter would certainly be less
> work for new SvcParamKeys, but I'm not sure what the implications would be
> of the DNS frontend picking up SvcParamKeys it doesn't understand. Then
> again, we seem to have happily imported basically all the existing keys
> anyway.)

It seems to me that SvcParamKey's can be divided into three groups:


1) Properties of the server that don't affect protocol.

E.g., ech, tls-supported-groups, no-default-alpn

These should be picked by the DNS frontend.


2) Properites related to location of the server.

E.g., port, ipv4hint, ipv6hint

These should not be picked by the DNS frontend, but instead should be
set by the DNS frontend configuration (or at least specify how to set
these).


3) Gateway-special properties

E.g., alpn

These would initially seem to be server properties. However, these can
affect the protocol used (e.g., h2 and h3 are very different), so in
some situations, DNS frontend needs to handle it specially.

One such situation is if the server is gatewayed. In such situation,
the DNS frontend needs to drop all the alpn values not supported in the
gateway (especially h3 needs to be dropped).

Servers can also be gatewayed in IPv4 but direct in IPv6. In that
situation, the DNS fronted needs to duplicate the records, with IPv4
side having filtered alpn values and IPv6 side having all the alpn
values.


There seems to be no guarantees about which category future SvcParamKeys
fall into. While the second group just should not be specified at all,
a new parameter in the third group could cause problems, as not
filtering those correctly can cause breakage.




-Ilari

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

[TLS]Re: WG Adoption for TLS Trust Expressions

[David Benjamin]

(replies inline)

On Sun, May 5, 2024 at 6:48 PM Dennis Jackson  wrote:

> Hi David, Devon, Bob,
>
> I feel much of your response talks past the issue that was raised at IETF
> 118.
>
> The question we're evaluating is NOT "If we were in a very unhappy world
> where governments controlled root certificates on client devices and used
> them for mass surveillance, does Trust Expressions make things worse?".
> Although Watson observed that the answer to this is at least 'somewhat',
> I agree such a world is already maxed at 10/10 on the bad worlds to live
> in scale and so it's not by itself a major problem in my view.
>
> The actual concern is: to what extent do Trust Expressions increase the
> probability that we end up in this unhappy world of government CAs used for
> mass surveillance?
>
> The case made earlier in the thread is that it increases the probability
> substantially because it provides an effective on-ramp for new CAs even
> if they exist entirely outside of existing root stores. Websites can
> adopt such a CA without being completely broken and unavailable as they
> would be today. Although I think it's unlikely anyone would independently
> do this, it's easy to see a website choosing to add such a certificate
> (which is harmless by itself) if a government incentivized or required
> it.  Trust Expressions also enables existing CAs to force-push a cert chain
> from a new CA to a website,  without the consent or awareness of the
> website operator, further enabling the proliferation of untrusted (and
> presumably unwanted) CAs.
>
> These features neatly solve the key challenges of deploying a government
> CA, which as discussed at length in the thread, are to achieve enough
> legitimacy through website adoption to have a plausible case for enforcing
> client adoption. The real problem here is that you've (accidentally?)
> built a system that makes it much easier to adopt and deploy any new CA
> regardless of trust, rather than a system that makes it easier to deploy
> & adopt any new *trusted* CA. If you disagree with this assessment, it
> would be great to hear your thoughts on why. Unfortunately, none of the
> arguments in your email come close to addressing this point and the text
> in the draft pretty much tries to lampshade these problems as a feature.
>
Our understanding of your argument is that it will be easier for
governments to force clients to trust a CA if a sufficient number of
websites have deployed certificates from that CA. We just don’t agree with
this assertion and don’t see websites’ deployment as a factor in trust
store inclusion decisions in this scenario.


> The other side of this risk evaluation is assessing how effectively Trust
> Expressions solves real problems.
>
> Despite a lot of discussion, I've only seen one compelling unsolved
> problem which Trust Expressions is claimed to be able to solve. That is
> the difficulty large sites have supporting very old clients with
> out-of-date root stores (as described by Kyle). This leads to sites using
> complex & brittle TLS fingerprinting to decide which certificate chain to
> send or to sites using very particular CAs designed to maximize
> compatibility (e.g. Cloudflare's recent change).
>
> However, it's unclear how Trust Expressions solves either fingerprinting
> or the new trusted root ubiquity challenge. To solve the former, we're
> relying on the adoption of Trust Expressions by device manufacturers who
> historically have not been keen to adopt new TLS extensions. For the
> latter, Trust Expressions doesn't seem to solve anything. Sites / CDNs are
> still forced to either have a business arrangement with a single suitably
> ubiquitous root or to conclude multiple such arrangements (which come with
> considerable baggage) with both new and ubiquitous roots - in return for no
> concrete benefit. If we had Trust Expressions deployed today, how would
> life be better for LE / Cloudflare or other impacted parties?
>
It isn’t necessary for older device manufacturers to adopt Trust
Expressions. Rather, Trust Expressions would be adopted by modern clients,
allowing them to improve user security without being held back by older
clients that don’t update. Servers may still need to navigate intersections
and fingerprinting for older clients, but this will be unconstrained by
modern ones. It will also become simpler, with fingerprinting less
prevalent, as older clients fall out of the ecosystem.


> I won't detail them here, but it seems like there are simpler and more
> effective alternatives that would address the underlying problem, e.g.
> through root stores encouraging cross-signing or offering cross-signing
> services themselves and using existing techniques to avoid any impact at
> the TLS layer.
>
> I'm struggling to see it being an even partially effective solution for any
> of the other proposed use cases. To pick an example you've repeatedly
> highlighted, can you clarify how Trust Expressions will speed the
> tran

[TLS]Re: WG Adoption for TLS Trust Expressions

[David Benjamin]

Hi Richard. Thanks for the comments! Replies inline.

On Mon, May 6, 2024 at 10:23 AM Richard Barnes  wrote:

> Hi all,
>
> Coming in late here.  Appreciate the discussion so far.  FWIW, here's how
> I'm thinking through this:
>
> I would frame the basic problem here as follows, since I think the use
> cases presented are all basically corollaries: Root store fragmentation
> makes it hard for server operators to make sure they can authenticate to
> all of the clients they want to connect with.  Note that the pain is
> non-zero regardless of technology.  The more clients have differing
> requirements, the more work servers are going to have to do to support them
> all.
>
> Pain = (Amount of fragmentation) * (Pain per fragmentation)
>
> The question at issue here is how trust expressions affect the inputs to
> this equation.
>
> Shifting from a single-certificate to a multi-certificate world shifts the
> pain, from "How do I pick the most widely accepted cert?" to "How do I make
> sure I have the right selection of certificates?"  I probably agree that
> this is a net reduction in pain for a given level of fragementation.
>

I think we’re broadly in agreement here. Fragmentation exists today, both
between different root programs and between versions of a given client and
there is a significant amount of pain involved for affected server
operators with no option but to find a new ubiquitously-trusted CA and
reissue.

We’re particularly concerned about this server operator pain because it
translates to security risks for billions of users. If root program actions
cause server operator pain, there is significant pressure against those
actions. The end result of this is that root store changes happen
infrequently, with the ultimate cost being that user security cannot
benefit from PKI improvements.

It’s worth noting that, for a given set of target clients, picking the most
widely accepted certificate is not merely painful but potentially
infeasible. Picking a larger selection of certificates allows the server
operator to meet their needs. There is still some cost to selecting from
too many certificates, but trust expressions greatly relieves the pressures
that, again, ultimately are paid by user security.

We also anticipate many of those costs can be mitigated by instead imposing
smaller costs on CAs, who already have existing relationships with root
programs. Indeed, CAs already make decisions about supported clients, by
deciding which cross-signs and intermediates to include and which to
retire. Trust expressions makes these decisions more explicit.


> I probably also agree with Dennis, though, that reducing the pain at a
> given level of fragmentation will increase the temptation to more
> fragmentation.  The country-level stuff is there, but even some of the
> putative use cases look like more fragmentation -- more algorithms,
> changing root store policies more frequently.  Playing the combinatorics
> out here, how many certs is a server going to have to maintain?
>

To some degree, yes, we want to increase fragmentation *when it is
necessary to benefit user security*. Fragmentation is an inherent
consequence of root program changes, and root programs often need changes
to meet user security (and, with post-quantum, performance) needs, but the
costs today are prohibitive to the point that root programs cannot
effectively meet those needs.

Of course, unnecessary fragmentation is undesirable. Trust expressions
fixes the prohibitive costs but, as you allude to, there are still costs.
We don’t want servers to need to maintain unboundedly many certificates.
However, note that these same costs are pressure against excessive,
unnecessary fragmentation.

It’s hard to say exact numbers at this stage. We can only learn with
deployment experience, hence our desire to progress toward adoption and
experimentation.


> As an aside here, speaking as someone who used to run a root program, I'm
> not sure that reducing the barriers to adding new CAs to a root program is
> a net benefit.  Obviously we don't want things to ossify, but it seems like
> experience has shown that small, niche CAs cause more trouble in terms of
> compliance checking and misissuance than the benefit that they bring in
> terms of diversity.
>

This is an important point; most modern root programs including Chrome

and Mozilla  are trending
towards increased requirements on CAs to become trusted, including greater
agility among trust anchors. This agility reduces the risk of powerful,
long-lived keys and allows for faster adoption of security improvements,
but poses additional pain on subscribers who can only deploy one
certificate to meet the needs of a set of clients that are changing faster
than ever before.

We do not expect that to change. Trust expressions *do not remove any
barriers from including a CA in

[TLS]Re: WG Adoption for TLS Trust Expressions

[Nick Harper]

On Mon, May 20, 2024 at 7:26 AM Dennis Jackson  wrote:

> Compared to the alternatives, Trust Expressions seems to solve the
> problems less effectively and introduce much greater risks. If you really
> feel the opposite is true, I would strongly encourage you to:
> b) Make a good faith attempt to engage with the concerns raised about the
> risks. Think through how a party with different goals to your own could
> exploit the negotiation offered by Trust Expressions for their own
> purposes. If your goal was instead to enable surveillance and domestic
> control of the web for your government, how would widespread support for
> Trust Expressions help you?
>

If an attacker's goal is to surveil the web (i.e. get the plaintext of
selected HTTPS connections), they can MitM the connection, log the traffic
keys for the connection, or have one of the parties (client or server) with
access to the plaintext send me the plaintext. Only the first option, a
machine-in-the-middle attack, involves the Web PKI - the rest can be done
regardless of the certificate chain served by the server or verified by the
client.

In a world without Trust Expressions, the surveillor performing a MitM
attack needs to get the client to trust the certificate chain presented by
the MitM. It could do this by asking the user to add its root to their
browser's trust store (e.g. like Kazakhstan does), or by coercing the
browser vendor to add the surveillance root to the browser's trust store.
In this world, it doesn't matter what certification authority the server
being MitMed is using.

In a world with Trust Expressions, the above scenario is still possible and
it is unchanged by the presence of Trust Expressions: The client still has
added the surveillance root to its trust store, the MitM is still
generating or using a cert issued by the surveillance root, and the server
being MitMed can serve whichever of its certificate chains to its end of
the MitM. (Presumably the MitM either doesn't advertise Trust Expressions
in the ClientHello it sends to the server, or it advertises the same one
sent by the client so as to keep a low profile of being detected by the
server.)

Trust Expressions appears to open up a new attack vector that involves
coercing clients to trust a new root, and also coercing servers to support
using a cert issued by that root (when connected to by a client that trusts
that root, and using another cert chain on other connections). This
scenario requires the attacker to coerce a superset of the parties involved
in the previous scenario, and includes an additional step that is
unnecessary. Coercing the server to use a different cert chain (only when
the client trusts it) does nothing to facilitate the attacker from getting
the plaintext of a connection from that server. The attacker still needs to
MitM that connection with an attacker controlled leaf certificate because
it doesn't know the private key of the certificate used by the server.

The technical attack of surveilling a connection looks the same regardless
of whether Trust Expressions exists: The surveillor coerces clients into
trusting its surveillance root, and creates certs issued from that root to
MitM connections. Trust Expressions might make it more palatable for this
attacker to coerce servers to use a cert issued by their surveillance root
(when trusted by clients, and another cert for other clients), but doing so
is unrelated to connection surveillance and is separable.

A government using Trust Expressions for domestic control of the Web is a
very broad and vague topic. The only two examples of end goals for domestic
control of the Web that I can think of right now are for surveillance and
censorship. Surveillance was discussed above and Trust Expressions provides
no additional benefit for surveillance over the status quo. For censorship
(that does not involve viewing the plaintext of connections - that requires
surveillance), there's a broader space to explore. Today, countries can
censor sites by DNS hijacking, IP address blocking, and SNI inspection, to
name a few technologies. Those options remain unaffected by Trust
Expressions. A government might try to convince/coerce websites that
operate within its jurisdiction to use a certificate chain issued by a
government CA when clients within the government jurisdiction connect.
Then, somehow, the government technically enforces this requirement, and if
a site serves objectionable content, the government revokes the site's cert
(or opts not to renew it). I'll assume that this technical enforcement is
only for domestic connections, where the government has hypothetical
control over both endpoints. Enforcing that all ClientHellos have a trust
expression for a root store that includes the government CA is insufficient
(and implausibly impractical, e.g. people visiting from other countries).
The enforcement can't look at the cert used per-connection and block if the
cert isn't issued by the government CA, as that's

[TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction

[Eric Rescorla]

These are all fair points, and it's possible we don't need to do anything
with the transcript.

I don't think we need to resolve this before adoption, I just wanted to
make sure that I said something now to make sure people weren't surprised
later.

-Ekr


On Tue, May 21, 2024 at 6:46 AM David Benjamin 
wrote:

> Off the cuff, folding it into the transcript sounds tricky, since existing
> TLS servers won't know to do it, and, as with any other DNS hints, we need
> to accommodate the DNS being out of sync with the server. It'll also be
> more difficult to deploy due to needing changes in the TLS stack and
> generally require much, much tighter coordination between DNS and TLS. I'd
> like for that coordination to be more viable (see my comments on the
> .well-known draft), but I don't think we're there yet.
>
> But I'm certainly open to continue discussing it and this problem space!
> The original version of the draft actually tried a lot harder to handle the
> downgrade story. Rather than mess with the transcript, it defined away all
> the negotiation algorithms where this would be a problem and keyed the
> NamedGroup codepoints to know when you could be guaranteed of the narrower
> server behavior.
>
> My read of the feedback was that people thought this was an unnecessary
> complication and that servers doing a key-share-first selection were doing
> so intentionally because they believed the options roughly equivalent. So I
> took all that out and replaced it with text to that effect.
>
> David
>
>
> On Tue, May 21, 2024, 08:54 Eric Rescorla  wrote:
>
>> I agree that it's attractive to be able to hint in the HTTPS RR, but I'm
>> less sure about addressing the basic insecurity of the DNS channel with the
>> approach this draft takes. I don't have a complete thought here, but what
>> if we were to somehow fold the hint into the handshake transcript? I
>> suppose we can sort this out post-adoption, but I'd like the question to be
>> on the table.
>>
>> -Ekr
>>
>>
>> On Fri, May 3, 2024 at 3:05 PM Joseph Salowey  wrote:
>>
>>> This is a working group call for adoption
>>> for draft-davidben-tls-key-share-prediction.  This document was presented
>>> at IET 118 and has undergone some revision based on feedback since then.
>>> The current draft is available here:
>>> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
>>> Please read the document and indicate if and why you support or do not
>>> support adoption as a TLS working group item. If you support adoption
>>> please, state if you will help review and contribute text to the document.
>>> Please respond to this call by May 20, 2024.
>>>
>>> Thanks,
>>>
>>> Joe, Deidre, and Sean
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> ___
>> 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: WG Adoption for TLS Trust Expressions

[Stephen Farrell]

Hiya,

A slightly meta comment:

On 21/05/2024 19:05, Nick Harper wrote:



From a process perspective, considering how a technology could be abused is

important and should be addressed to a reasonable level in the RFC. I don't
see a need for this to be fully fleshed out with every possible abuse
considered and discussed in an individual Internet-Draft.


Considering abuse-cases is something we've historically done
very badly, if at all, and is IMO something we really need to
do much better at. I think the history of the Internet over
the last decade or two provides ample evidence of that.

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.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: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

Hi Nick,

On 21/05/2024 19:05, Nick Harper wrote:

[...]

Perhaps there are additional ways to use Trust Expressions to censor 
the web that are more practical and more useful than the existing 
techniques that I didn't consider. There are most certainly other 
forms of domestic control of the Web that I didn't consider. From my 
analysis, if I were a government looking to enable surveillance and 
domestic control of the Web, I don't see Trust Expressions as 
something that unlocks new options or makes existing techniques 
easier/more reliable. It is at most something to keep in mind as 
technology evolves. Maybe I'm not very imaginative, and you've 
imagined much more interesting ways a government might surveil the web 
or attempt to control it using Trust Expressions.


This thread is now 40+ messages deep and I guess you might have not seen 
much of the previous discussion. I actually agree with much of your 
analysis, but it focused on the wrong question, as I wrote earlier in 
this thread:


The question we're evaluating is NOT "If we were in a very unhappy 
world where governments controlled root certificates on client devices 
and used them for mass surveillance, does Trust Expressions make 
things worse?" Although Watson observed that the answer to this is at 
least 'somewhat', I agree such a world is already maxed at 10/10 on 
the bad worlds to live in scale and so it's not by itself a major 
problem in my view.


The actual concern is: to what extent do Trust Expressions increase 
the probability that we end up in this unhappy world of government CAs 
used for mass surveillance?


On 21/05/2024 19:05, Nick Harper wrote:


I'd be interested to hear details on what those are.

Messages [1,2,3,4] of this thread lay out these details at length.

Besides these concerns which are unaddressed so far, much of the recent 
discussion has focused on establishing what problem(s) Trust Expressions 
actually solves and how effective a solution it actually is.


Looking forward to your thoughts on either or both aspects.

Best,
Dennis

[1] https://mailarchive.ietf.org/arch/msg/tls/LaUJRHnEJds2Yfc-t-wgzkajXec/

[2] https://mailarchive.ietf.org/arch/msg/tls/zwPvDn9PkD5x9Yw1qul0QV4LoD8/

[3] https://mailarchive.ietf.org/arch/msg/tls/9AyqlbxiG7BUYP0UD37253MeK6s/

[4] https://mailarchive.ietf.org/arch/msg/tls/fxM4zkSn0b8zOs59xlH6uy8P7cE/



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

[TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction

[Joseph Salowey]

There is consensus to adopt this draft as a working group item.  I'll work
with the authors to migrate to the official repository and submit an
updated draft.

On Tue, May 21, 2024 at 11:23 AM Eric Rescorla  wrote:

> These are all fair points, and it's possible we don't need to do anything
> with the transcript.
>
> I don't think we need to resolve this before adoption, I just wanted to
> make sure that I said something now to make sure people weren't surprised
> later.
>
> -Ekr
>
>
> On Tue, May 21, 2024 at 6:46 AM David Benjamin 
> wrote:
>
>> Off the cuff, folding it into the transcript sounds tricky, since
>> existing TLS servers won't know to do it, and, as with any other DNS hints,
>> we need to accommodate the DNS being out of sync with the server. It'll
>> also be more difficult to deploy due to needing changes in the TLS stack
>> and generally require much, much tighter coordination between DNS and TLS.
>> I'd like for that coordination to be more viable (see my comments on the
>> .well-known draft), but I don't think we're there yet.
>>
>> But I'm certainly open to continue discussing it and this problem space!
>> The original version of the draft actually tried a lot harder to handle the
>> downgrade story. Rather than mess with the transcript, it defined away all
>> the negotiation algorithms where this would be a problem and keyed the
>> NamedGroup codepoints to know when you could be guaranteed of the narrower
>> server behavior.
>>
>> My read of the feedback was that people thought this was an unnecessary
>> complication and that servers doing a key-share-first selection were doing
>> so intentionally because they believed the options roughly equivalent. So I
>> took all that out and replaced it with text to that effect.
>>
>> David
>>
>>
>> On Tue, May 21, 2024, 08:54 Eric Rescorla  wrote:
>>
>>> I agree that it's attractive to be able to hint in the HTTPS RR, but I'm
>>> less sure about addressing the basic insecurity of the DNS channel with the
>>> approach this draft takes. I don't have a complete thought here, but what
>>> if we were to somehow fold the hint into the handshake transcript? I
>>> suppose we can sort this out post-adoption, but I'd like the question to be
>>> on the table.
>>>
>>> -Ekr
>>>
>>>
>>> On Fri, May 3, 2024 at 3:05 PM Joseph Salowey  wrote:
>>>
 This is a working group call for adoption
 for draft-davidben-tls-key-share-prediction.  This document was presented
 at IET 118 and has undergone some revision based on feedback since then.
 The current draft is available here:
 https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
 Please read the document and indicate if and why you support or do not
 support adoption as a TLS working group item. If you support adoption
 please, state if you will help review and contribute text to the document.
 Please respond to this call by May 20, 2024.

 Thanks,

 Joe, Deidre, and Sean
 ___
 TLS mailing list
 TLS@ietf.org
 https://www.ietf.org/mailman/listinfo/tls

>>> ___
>>> 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]The TLS WG has placed draft-davidben-tls-trust-expr in state "Candidate for WG Adoption"

[IETF Secretariat]

The TLS WG has placed draft-davidben-tls-trust-expr in state
Candidate for WG Adoption (entered by Joseph Salowey)

The document is available at
https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/


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

[TLS]Re: WG Adoption for TLS Trust Expressions

[Nick Harper]

On Tue, May 21, 2024 at 3:00 PM Dennis Jackson  wrote:

> This thread is now 40+ messages deep and I guess you might have not seen
> much of the previous discussion. I actually agree with much of your
> analysis, but it focused on the wrong question, as I wrote earlier in this
> thread:
>
> The question we're evaluating is NOT "If we were in a very unhappy world
> where governments controlled root certificates on client devices and used
> them for mass surveillance, does Trust Expressions make things worse?"
> Although Watson observed that the answer to this is at least 'somewhat', I
> agree such a world is already maxed at 10/10 on the bad worlds to live in
> scale and so it's not by itself a major problem in my view.
>
> I don't see Watson saying that in any of his messages [5] [6] [7]. Message
[7] does mention an intermediate cross-signed by a government CA, but my
understanding of Watson's argument is that Trust Expressions doesn't do
anything to enable that since the "chain" of certificates sent by a TLS
server is really just a grab bag for the client to use when it does path
building. Specifically, in today's world, a CA could send to ACME clients a
leaf cert with intermediates and cross-signs so that the root of the path
could be either that CA or a government CA, and when that server sends that
bag of intermediates to a client to verify, the client will build one of
those two paths, depending on what's in the client's trust store.

>
> The actual concern is: to what extent do Trust Expressions increase the
> probability that we end up in this unhappy world of government CAs used for
> mass surveillance?
>
> This is a good question to ask, and I see you attempted to address it in
message [4]. You argue that Trust Expressions provides an "on-ramp" for
deploying a government CA to reach a certain level of legitimacy or
adoption. I don't see the connection between that and mass surveillance,
nor do I see you make a claim that Trust Expressions does increase this
probability. In [1] you describe this "on-ramp", which has step 1 being to
ship support for trust negotiation (which could be more accurately
described as a trust store advertisement mechanism), and step 2 as the
following:

>  * A large country or federation pushes for recognition of their
>domestic trust regime as a distinct trust store which browsers must
>advertise. Browsers agree because the relevant market is too big to
>leave.

I see two ways this happens: The first is that the recognition of the
domestic trust regime is done in a way that does not circumvent root store
policy. By this, I mean that the CAs in this domestic trust regime must
meet all audit and other policy requirements of the browser's root store,
and a brower root store can remove trust in a CA from that set if it
violates the root store requirements (in the same way that root stores
currently operate to distrust a CA when it is no longer trustworthy). In
this case, I see no negative effect on security for users or the websites
they are connecting to. From a technical perspective, this looks the same
regardless of whether the Web PKI ecosystem supports a trust store
advertisement mechanism. I see no change in the probability of ending up in
the "unhappy world" in this way.

The second way this could happen is that the government compels a browser
to add a CA to their root store regardless of whether it complies with root
store policy, implicitly stating that this CA will misissue certificates.
The browser's choice is to comply or leave the market. Until this new CA is
in a trust store advertised by clients, there's no incentive for server
operators to get a certificate issued by that CA, as there are no clients
for it to present that cert to. Thus, server adoption is no factor in the
government's pressure to compel a browser to add their CA, and I see the
same probability of this being successful as in the current state of the
world without Trust Expressions.

There is potentially a hybrid approach, where the government first asks
nicely that browsers add CA G to their root stores (where root stores are
welcome to remove G if it violates policy). At some later point in time,
the government tells browsers that since now G is already in their root
stores, they're not allowed to remove it, and at some point later G starts
mis-issuing certificates to perform surveillance or do other bad things.
This switcheroo looks the same in today's world as it does in a world with
a trust store advertisement mechanism. In a world without trust
expressions, the government gets G added to all major browser root stores,
then starts doing bad things with G when it's rolled out to enough
browsers. Doing bad things with G requires no server adoption. In a world
without trust store advertisements, the government can still
compel/coerce/encourage site operators to use a cert issued by G, by using
the mechanism that Watson described and is repeated above that requires no
changes to ho