Re: [TLS] Working Group Last Call for ECH

[Amir Omidi]

I'd like to understand how the behavior of the latest draft will be under
an adversarial condition.

One of the things that really excited me about ESNI back in the day was
effectively making it near impossible for countries, like my home country
Iran, from being able to effectively censor the web. AFAIK Iran's main
censorship mechanism revolves around looking for ClientHello's and then
sending a TCP reset when that SNI matches a censored domain.

I'm wondering, are we losing that ability from ESNI with this plain text
field? Maybe there can be an understanding in the RFC that the client may
omit, or falsify this plaintext field for a bit of extra adversarial
security in these circumstances?

On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:

>
>
> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena 
> wrote:
>
>> On 3/13/24 14:51, Watson Ladd wrote:
>>
>> > I'm not sure what problem you want us to solve here. In the case of
>> > server offering a single domain, an attacker can determine that
>> > connections to that domain go to the server and cheaply block based on
>> > IP. As a result the threat model is one of distinguishing between
>> > connections to two different inner names.
>>
>> An IP can be cheaply recycled as well, for instance restarting a VPS on
>> a cloud provider. Furthermore, IP based blocking may even be discouraged
>> at a higher level, for the exact reason that IPs can change pretty
>> easily. As an operator, I might be able to migrate my hosting to a new
>> server provider (and hence IP) trivially, but informing my users of a
>> domain change is much harder.
>>
>
> Yes, but the attacker can easily learn these IPs merely by querying
> the DNS. Moreover, they can learn the associated domains by sending
> a CH with no SNI at all and seeing what's in the certificate.
>
>
> > DNS does not propagate atomically with webserver configuration
>> > changes. It's thus necessary to deal with mismatches.
>> While this is true, if there is a configuration mismatch (and hence ECH
>> cannot work), why is the decision made for the server to transparently
>> "downgrade" it to non-ECH, instead of sending some kind of alert that
>> signifies the client to retry without ECH?
>>
>
> Three reasons:
>
> 1. Such an alert would be insecure because an attacker could forge it,
> thus causing the client to send ECH in the clear.
>
> 2. It allows the server to be completely ECH unaware rather than needing
> to special case an ECH alert.
>
> 3. It allows the server to securely provide a new ECHConfig.
>
> -Ekr
>
>
>
>> Regards,
>>
>> Raghu Saxena
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Amir Omidi]

> I don't think it's realistic for a generic client (e.g., a standard
browser) to omit or falsify this field.

Why not? From my understanding the issue that happens in this situation is
that the website becomes less reliable for these TLS clients?

If so, let that be a problem for the client to deal with. All this change
would do is something in security considerations along the lines of "to
make this protocol more censorship resistant, a TLS client MAY choose to
omit, or randomly generate the contents of `public_name`. A TLS Server
SHOULD handle these situations gracefully, and not actively reject the
client".

I do not like the idea of saying "some website can choose to do this". In
practice, very few websites will go down that route.

Are there any concerns if this approach is used?

On Wed, Mar 13, 2024 at 12:03 PM Eric Rescorla  wrote:

>
>
> On Wed, Mar 13, 2024 at 8:49 AM A A  wrote:
>
>> I think we should change outer SNI randomly and periodicity (e.g 1
>> hours), if it change fast enough, censor will need to pay a price to block
>> it,
>>
>
> This won't work because the public_name is part of the recovery mechanism
> for misconfiguration, which means that the server needs to have a valid
> certificate with that identity.
>
> -Ekr
>
>
>>
>> 13.03.2024, 23:40, "Amir Omidi" :
>>
>> I'd like to understand how the behavior of the latest draft will be under
>> an adversarial condition.
>>
>> One of the things that really excited me about ESNI back in the day was
>> effectively making it near impossible for countries, like my home country
>> Iran, from being able to effectively censor the web. AFAIK Iran's main
>> censorship mechanism revolves around looking for ClientHello's and then
>> sending a TCP reset when that SNI matches a censored domain.
>>
>> I'm wondering, are we losing that ability from ESNI with this plain text
>> field? Maybe there can be an understanding in the RFC that the client may
>> omit, or falsify this plaintext field for a bit of extra adversarial
>> security in these circumstances?
>>
>> On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:
>>
>>
>>
>> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena 
>> wrote:
>>
>> On 3/13/24 14:51, Watson Ladd wrote:
>>
>> > I'm not sure what problem you want us to solve here. In the case of
>> > server offering a single domain, an attacker can determine that
>> > connections to that domain go to the server and cheaply block based on
>> > IP. As a result the threat model is one of distinguishing between
>> > connections to two different inner names.
>>
>> An IP can be cheaply recycled as well, for instance restarting a VPS on
>> a cloud provider. Furthermore, IP based blocking may even be discouraged
>> at a higher level, for the exact reason that IPs can change pretty
>> easily. As an operator, I might be able to migrate my hosting to a new
>> server provider (and hence IP) trivially, but informing my users of a
>> domain change is much harder.
>>
>>
>> Yes, but the attacker can easily learn these IPs merely by querying
>> the DNS. Moreover, they can learn the associated domains by sending
>> a CH with no SNI at all and seeing what's in the certificate.
>>
>>
>> > DNS does not propagate atomically with webserver configuration
>> > changes. It's thus necessary to deal with mismatches.
>> While this is true, if there is a configuration mismatch (and hence ECH
>> cannot work), why is the decision made for the server to transparently
>> "downgrade" it to non-ECH, instead of sending some kind of alert that
>> signifies the client to retry without ECH?
>>
>>
>> Three reasons:
>>
>> 1. Such an alert would be insecure because an attacker could forge it,
>> thus causing the client to send ECH in the clear.
>>
>> 2. It allows the server to be completely ECH unaware rather than needing
>> to special case an ECH alert.
>>
>> 3. It allows the server to securely provide a new ECHConfig.
>>
>> -Ekr
>>
>>
>>
>> Regards,
>>
>> Raghu Saxena
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> ,
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS]Re: TLS trust expressions and certificate_authorities

[Amir Omidi]

I’ve had a lot of trouble understanding how the user agent is supposed to
be configured with this. Maybe a browser is going to be able to do it
easily, but how do we envision this working in openssl? Or a programming
language?

If this is implemented by user agents, how do we envision the
fingerprinting impact for this?

My comments aren’t blockers by any means. It’s only me trying to understand
how we imagine this draft working in these various TLS client
implementations.

Amir Omidi (he/them)


On Thu, Jun 13, 2024 at 22:16 Eric Rescorla  wrote:

>
>
> On Wed, Jun 12, 2024 at 5:16 PM Nick Harper  wrote:
>
>> On Wed, Jun 12, 2024 at 3:17 AM Dennis Jackson 
>> wrote:
>>
>>> You can't argue that T.E. contains the functionality of
>>> certificate_authorities as a subset, then conclude that having additional
>>> functionalities makes it less risky. You would need to argue the exact
>>> opposite, that T.E. doesn't contain the bad functionalities of
>>> certificate_authorities. The risk associated with abuse of a feature is not
>>> in any way diluted by tacking on good use cases.
>>>
>> I'm not arguing that TE is a superset of certificate_authorities. I'm
>> arguing that it's an incremental improvement over certificate_authorities.
>> That is to say, certificate_authorities is a way for a relying party to
>> indicate to a subscriber which CAs it trusts, and TE is another way to do
>> the same thing. TE is an incremental improvement because it's solving the
>> same problem but making different tradeoffs. To deploy the
>> certificate_authorities extension, no extra machinery is needed past what's
>> in the certificates, but that comes at a cost of a large number of bytes
>> sent by the relying party. TE optimizes for size, at the cost of additional
>> complexity and machinery involving additional parties.
>>
>> For the abuse scenario, TE makes it no easier than
>> certificate_authorities (the size of advertising the single malicious CA
>> isn't a concern, whereas it is a problem when it's a browser's entire trust
>> store that's advertised), and TE adds additional deployment complexity
>> compared to certificate_authorities, which lessens the risk.
>>
>
> I'm not sure that this analysis is correct. The text in 8446 isn't
> entirely clear, but I think the
> best reading is that that "certificate_authorities" list is supposed to be
> exhaustive:
>
>The "certificate_authorities" extension is used to indicate the
>certificate authorities (CAs) which an endpoint supports and which
>SHOULD be used by the receiving endpoint to guide certificate
>selection.
>
> ...
>
>authorities:  A list of the distinguished names [X501] of acceptable
>   certificate authorities, represented in DER-encoded [X690] format.
>   These distinguished names specify a desired distinguished name for
>   a trust anchor or subordinate CA; thus, this message can be used
>   to describe known trust anchors as well as a desired authorization
>   space.
>
> I don't know how widely implemented this extension is, but I don't think
> it's
> obviously safe to send a subset of the list.
>
> -Ekr
>
>
>> The takeaway here is that the risks associated with the abuse of Trust
>> Expressions also exist with certificate_authorities.
>>>
>>> I wonder what such a trust store manifest would look like... [1] [2].
>>> There's at least one large player out there with a list of CAs ready to go
>>> and all the necessary machinery in place.
>>>
>> Ready to go and do what?!
>>
>> If you're talking about the EU eIDAS QWAC trust list, those CAs were
>> already trusted by browsers before the eIDAS regulations took effect, and
>> eIDAS allows for their distrust and removal. Already, one CA [1] on that
>> list is being distrusted by multiple [2] browsers [3]. Even if the EU has a
>> published list of CAs that they could turn into a trust store manifest,
>> this is a distraction from the point that with TE, abuse requires the
>> cooperation (or compulsion) of more parties than with
>> certificate_authorities.
>>
>> 1: https://eidas.ec.europa.eu/efda/tl-browser/#/screen/tl/AT/5/25
>> 2:
>> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XpknYMPO8dI/m/JBNFg3aVAwAJ
>> 3:
>> https://groups.google.com/a/ccadb.org/g/public/c/wRs-zec8w7k/m/G_9QprJ2AQAJ
>>
>> ___
>> 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: [⚠] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Amir Omidi]

Countries like Iran would probably love if this went through.

This seems like a very dangerous feature that’ll make data collection
significantly easier for rogue states.


On Fri, Aug 2, 2024 at 20:10 Christian Huitema  wrote:

> I agree with Andrei. SSLKEYLOG is an extremely dangerous feature.
> I think the draft should only be adopted if it clearly state that the
> feature MUST NOT be deployed in production software.
>
> Using an environment variable may be a fine way to specify on which file
> copies of keys have to be written, but it is a terrible way to specify
> whether these keys should be. Environment variables can be installed by
> scripts, etc., and I can think of many ways of doing that without user
> awareness.
>
> I think that this functionality should be only compiled into builds that
> are specifically designated as "debug only", and that it should be
> turned on explicitly by some kind of user interaction. But really, I
> support Andrei's statement that there are many less intrusive ways to do
> debugging, such as using QLOG files in the case of QUIC. Enabling key
> export is a kind of nuclear option, and it should be hard to use, by
> design.
>
> -- Christian Huitema
>
>
> On 7/25/2024 11:01 AM, Andrei Popov wrote:
> >   * The ultimate goal is to simplify adoption of ECH for both developers
> > of TLS software and implementers
> >
> > Understood; I do not question the goals of the authors.
> >
> >   * Without a standard approach to troubleshooting every developer has
> > to build an individual set of bespoke troubleshooting tools.
> >
> > The troubleshooting approach used in this I-D is more invasive than it
> > needs to be. Troubleshooting can be accomplished in a number of ways,
> > including logs/traces that do not disclose all TLS-protected data.
> >
> >   * We tried to keep wording in line with the keylogfile draft - for
> > instance in the applicability statement it is worded that "this
> > mechanism MUST NOT be used in a production system".
> >
> > That’s nice, but in practice this does not prevent abuse of the feature.
> > I would rather SSLKEYLOGFILE was documented by the SW vendors who choose
> > to implement it, in a repository outside of the IETF. I understand I’m
> > in the rough on this.
> >
> > Cheers,
> >
> > Andrei
> >
> > *From:*Yaroslav Rosomakho 
> > *Sent:* Thursday, July 25, 2024 10:12 AM
> > *To:* Andrei Popov 
> > *Cc:* TLS List 
> > *Subject:* Re: [⚠️] [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG
> > Extension file for ECH
> >
> >
> >
> > You don't often get email from yrosomakho=40zscaler@dmarc.ietf.org
> > . Learn why this is
> > important 
> >
> >
> >
> > Thank you for the feedback, Andrei.
> >
> > Yes, it is intended to stay on the informational track as an extension
> > to draft-ietf-tls-keylogfile-02. We tried to keep wording in line with
> > the keylogfile draft - for instance in the applicability statement it is
> > worded that "this mechanism MUST NOT be used in a production system".
> > Happy to add stronger wording if that helps.
> >
> > The ultimate goal is to simplify adoption of ECH for both developers of
> > TLS software and implementers. Without a standard approach to
> > troubleshooting every developer has to build an individual set of
> > bespoke troubleshooting tools. Ability to inspect ECH negotiation in off
> > the shelf tools such as Wireshark during development or tests would
> > significantly help adoption.
> >
> > Best Regards,
> >
> > Yaroslav
> >
> > On Thu, Jul 25, 2024 at 9:31 AM Andrei Popov
> >  > > wrote:
> >
> > I do not support adoption, because I believe the IETF should not
> > standardize tools and techniques for decrypting TLS-protected data.
> > It is harder for a TLS implementer to reject requests for
> > IETF-blessed functionality.
> >
> > (As long as this remains on the Informational track, I believe it's
> > somewhat less harmful.)
> >
> > Cheers,
> >
> > Andrei
> >
> > -Original Message-
> > From: Sean Turner mailto:s...@sn3rd.com>>
> > Sent: Thursday, July 25, 2024 9:16 AM
> > To: TLS List mailto:tls@ietf.org>>
> > Subject: [EXTERNAL] [TLS]Adoption call for SSLKEYLOG Extension file
> > for ECH
> >
> > At the IETF 120 TLS session there was interest in adopting the
> > SSLKEYLOG Extension file for ECH I-D
> > (
> https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/ <
> https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/>).
> This message starts a two-weekl call for adoption. If you support adoption
> and are willing to review and contribute text, please send a message to the
> list. If you do not support adoption of this I-D, please send a message to
> the list and indicate why. This call will close on 8 August 2024.
> >
> > Thanks,
> > Sean
> > ___

[TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Amir Omidi]

It doesn’t necessarily need to be malicious. With how much of software
deployment being massive YAML files with tons of environment variables,
mistakenly including this won’t be that difficult.

On Sun, Aug 4, 2024 at 07:00 Ilari Liusvaara 
wrote:

> On Sat, Aug 03, 2024 at 02:38:29PM -0700, Christian Huitema wrote:
> >
> > The security considerations of
> > https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ are pretty
> > clear, but the discussion pointed out that environment variables can be
> > installed without knowledge of most users. More protection is needed.
> > Examples are explicit run time options, such as asking the user to set a
> > special configuration flag to enable the feature, and compile time
> > protections, which would only enable that configuration flag in special
> > versions of the application.
>
> Any attacker that can tamper with environment variables is in position
> to do way way worse things than enabling SSLKEYLOG. Possibly even worse
> than an attacker capable of replacing the whole application with a
> troijan!
>
>
>
>
> -Ilari
>
> ___
> 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