Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Christopher Patton]

It would be great to here from Jonathan (the author) if RFC 7250 is already
sufficient for this use case.

On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi  wrote:

> Please see my earlier comment regarding this draft:
> https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/
>
> In summary: the functionality of this draft is already achievable by
> using the client_certificate_type extension defined in RFC 7250:
> https://datatracker.ietf.org/doc/html/rfc7250 with certificate type
> value = 0:
>
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3
> .
>
> The table in section 4.2 of RFC8446 even mentions that the extension can
> be included in the ClientHello:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby
> ensuring that the server sends a CertificateRequest message in response
> to the ClientHello received.
>
> OpenSSL already implements this extension since it was needed for
> support raw public keys (RPKs).
>
> As stated earlier: if it is indeed the case that the
> client_certificate_type extension is suitable for the use-case, then
> perhaps it is preferable to not have a separate flag. Otherwise, it
> would make the state machine at the server more complicated (for
> example: handling a ClientHello with both the mTLS flag and the
> client_certificate_type extension.
>
> Therefore, like Ekr, I am mildly negative on adopting this document but
> for different reasons.
>
> --Mohit
>
> On 4/3/24 00:52, Sean Turner wrote:
> > At the IETF 119 TLS session there was some interest in the mTLS Flag I-D
> (
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D=0);
> also, see previous list discussions at [0]. This message is to judge
> consensus on whether there is sufficient support to adopt this I-D.  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 16
> April 2024.
> >
> > Thanks,
> > Deirdre, Joe, and Sean
> >
> > [0]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F9e2S95H9YgtHp5HhqdlNqmQP0_w%2F=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681208049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=eEU6ZPJ5cmfqLHQuM3UYXrFKCJuKaaJVc8Ssk5erRjk%3D=0
> > ___
> > TLS mailing list
> > TLS@ietf.org
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681214744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=%2B9CGIKB31GI9RMQG62I1rTnbHaDPfSynvlmwrkPn%2FpQ%3D=0
>
> ___
> 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] Adoption call for TLS Flag - Request mTLS

[Christopher Patton]

I'd like to see this problem solved. There was some discussion about
whether an I-D is needed or all we needed was to register a code point
somewhere. If most agree that an I-D is needed, then let's adopt it. I'm
happy to review.

Chris P.

On Tue, Apr 2, 2024 at 12:22 PM Sean Turner  wrote:

> At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (
> https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see
> previous list discussions at [0]. This message is to judge consensus on
> whether there is sufficient support to adopt this I-D.  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 16
> April 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
> ___
> 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

[Christopher Patton]

I don't believe there were any changes from draft 13 to 18 that would
invalidate security analysis for draft 13:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-esni-13=draft-ietf-tls-esni-18=--html

Chris P.

On Mon, Mar 11, 2024 at 3:12 PM Rob Sayre  wrote:

> On Mon, Mar 11, 2024 at 3:08 PM Rob Sayre  wrote:
>
>> I also believe there was supposed to be some formal proof work done, and
>> I'm not sure that's complete
>>
>
> Ah, I see this was done:
> https://dl.acm.org/doi/abs/10.1145/3548606.3559360
>
> So, I guess the only question is whether this needs to be done again for
> the latest specification.
>
> thanks,
> Rob
>
> ___
> 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

[Christopher Patton]

Hi chairs,

I believe ECH is good to go.

Chris P.

On Mon, Mar 11, 2024 at 3:00 PM Joseph Salowey  wrote:

> This is the working group last call for TLS Encrypted Client Hello [1].
> Please indicate if you think the draft is ready to progress to the IESG and
> send any comments to the list by 31 March 2024.  The comments sent by
> Watson Ladd to the list [2] on 17 February 2024 will be considered last
> call comments.
>
> Thanks,
>
> Joe, Deirdre, and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>
>
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Christopher Patton]

I support adoption.
Chris P.

On Tue, Dec 5, 2023 at 9:34 PM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Christopher Patton]

I support adoption and can review.

Chris P.

On Mon, Nov 6, 2023 at 6:27 PM David Benjamin  wrote:

> I support adoption and am willing to contribute text, but this is perhaps
> not surprising. :-)
>
> On Mon, Nov 6, 2023 at 12:25 PM Joseph Salowey  wrote:
>
>> At the TLS meeting at IETF 118 there was significant support for the
>> draft  Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
>>  (
>> https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/01/)  This
>> call is to confirm this on the list.  Please indicate if you support the
>> adoption of this draft and are willing to review and contribute text.  If
>> you do not support adoption of this draft please indicate why.  This call
>> will close on November 27, 2023.
>>
>> Thanks,
>>
>> Sean, Chris and Joe
>> ___
>> 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] Adoption call for draft-jackson-tls-cert-abridge

[Christopher Patton]

I support adoption and am willing to review. I can also lend a hand to
prototyping.

Chris P.

On Tue, Aug 1, 2023 at 1:13 PM Salz, Rich 
wrote:

> > Based on positive feedback received during IETF 117, this email begins
> an adoption call for "Abridged Compression for WebPKI Certificates"
> (draft-jackson-tls-cert-abridge).
>
> > The datatracker page for this document can be found here:
> https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
>
> I support adoption and am willing to contribute.
>
> ___
> 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] RFC 8446: Reserved HandshakeType variants?

[Christopher Patton]

Thanks for the pointer!

On Thu, Jun 15, 2023 at 4:03 PM Rob Sayre  wrote:

> On Thu, Jun 15, 2023 at 3:58 PM Christopher Patton  40cloudflare@dmarc.ietf.org> wrote:
>
>> Hi TLS,
>>
>> Appendix B.3 defines the `HandshakeType` for each message in the
>> handshake protocol. I'm curious about the history of the RESERVED variants
>> in this list:
>>
>>
> ...
>
>
>>
>> Were these variants from previous TLS versions? Are they there to prevent
>> extensions, or future TLS versions, from reusing these code points?
>>
>
> Hi,
>
> IANA has them:
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xml
>
> Some of them are from old TLS versions, and some are from TLS
> extensions that didn't really take off.
>
> thanks,
> Rob
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] RFC 8446: Reserved HandshakeType variants?

[Christopher Patton]

Hi TLS,

Appendix B.3 defines the `HandshakeType` for each message in the handshake
protocol. I'm curious about the history of the RESERVED variants in this
list:

```
 enum {
  hello_request_RESERVED(0),
  client_hello(1),
  server_hello(2),
  hello_verify_request_RESERVED(3),
  new_session_ticket(4),
  end_of_early_data(5),
  hello_retry_request_RESERVED(6),
  encrypted_extensions(8),
  certificate(11),
  server_key_exchange_RESERVED(12),
  certificate_request(13),
  server_hello_done_RESERVED(14),
  certificate_verify(15),
  client_key_exchange_RESERVED(16),
  finished(20),
  certificate_url_RESERVED(21),
  certificate_status_RESERVED(22),
  supplemental_data_RESERVED(23),
  key_update(24),
  message_hash(254),
  (255)
  } HandshakeType;
```

Were these variants from previous TLS versions? Are they there to prevent
extensions, or future TLS versions, from reusing these code points?

Thanks,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Christopher Patton]

I support this. Adding P256 + Kyber768 seems like a good idea.

Chris P.

On Wed, Mar 29, 2023 at 10:50 AM Christopher Wood 
wrote:

> As discussed during yesterday's meeting, we would like to assess consensus
> for moving draft-ietf-tls-hybrid-design forward with the following strategy
> for allocating codepoints we can use in deployments.
>
> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this
> document through the process towards publication.
> 2. Write a simple -00 draft that specifies the target variant of
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully
> did this for us already [1].) Once this is complete, request a codepoint
> from IANA using the standard procedure.
>
> The intent of this proposal is to get us a codepoint that we can deploy
> today without putting a "draft codepoint" in an eventual RFC.
>
> Please let us know if you support this proposal by April 18, 2023.
> Assuming there is rough consensus, we will move forward with this proposal.
>
> Best,
> Chris, Joe, and Sean
>
> [1]
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
> ___
> 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] ECH not protect SNI

[Christopher Patton]

 Hi Taushu,


What I try to accomplish is to let every website could deploy ECH.
>

I believe everyone can, and they should.

It's true that reverse proxies, like Cloudflare, terminate TLS for a large
number of names and therefore have the potential to provide a higher degree
of privacy. But I don't think it's fair to say that smaller TLS servers
don't benefit from ECH.

As others have said: Ultimately, your anonymity set is no larger than the
set of names for which you have TLS certificates. What ECH allows you to do
is make all traffic to any of those names look the same. All you have to do
is issue a certificate for a special name, the "public_name", that you
would only use in case of ECH rejection.

Yet there are other benefits to ECH that get less attention: Namely,
protection of ALPN and other privacy-sensitive extensions that get
transmitted in the ClientHello. I think of ECH as a way to render more of
the TCP packets unintelligible to an observer. This clearly has a net
benefit.



> And recall why the outer SNI is needed? Only because the browser need to
> confirm the updated ECHConfig offered by the server is valid.
>

> In my opinion, there are different ways to accomplish this feature without
> the outer TLS handshake.
>
> One of them is use DNSSEC. The sever just respond the correct HTTPS RR
> with its responding SIGRR, and the browser could verify them.
> However, this way requires the browser to implement DNSSEC verify process,
> which is not an easy task to make consensus.
>
> Another one is publish another public key by DNS to check the signature of
> the updated ECHConfig offered by server. As this key is only used
> for ECHConfig updating process, there is no need to rotate it very
> frequently. This idea requires the browser to implement one small additional
> signature verification, which is far more simple than the DNSSEC.
>

I don't think this doesn't actually make the traffic to your names any more
anonymous. The fact that the public name might share something in common
with one of your names (e.g., "public-facing-name.example.com" vs "
real-name.example.com") doesn't really change anything: I can still look up
the IP address for "real-name.example.com" with a standard DNS query and
learn the exact same information.



> By the way, the current design of ECH is good for hosters like Cloudflare.
> Because they already have the intermediary proxy.
>

ECH was designed for everyone, not just the big players. However, there is
only so much we can do in a client-server protocol like TLS. It might make
sense for you to start thinking beyond a single server.

Something worth exploring: There is an alternative deployment model for ECH
called "Split-Mode", which allows the client-facing server to be
organizationally separated from the backend servers. The client-facing
server would do ECH decryption, then proxy the rest of the handshake to the
appropriate backend. In this setting, the client-facing server would only
terminate TLS for the client-facing server. (See the spec for details.)

In theory, a coalition of "small servers" could set themselves up behind a
client-facing server, whose only job is to handle ECH. This entity need not
be a full-blown reverse proxy.

Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH not protect SNI

[Christopher Patton]

It's also worth noting that the benefit of ECH goes well beyond encrypting
SNI. There are lots of potentially sensitive things that are sent in the
ClientHello, e.g., the ALPN value. There's also an important
future-proofing aspect to this: We might end up with extensions in the
future that inadvertently leak important information in the handshake that
we would be better off encrypting.

Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH draft-13 servers for interop testing

[Christopher Patton]

Thanks, Stephen! For the record, Cloudflare's test server is
crypto.cloudflare.com. Like draft-13.esni.defo.ie:8413, you can trigger HRR
by offering only a P-384 key share in the initial ClientHello.

Best,
Chris P.

On Tue, Sep 14, 2021 at 5:12 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> I've put up a bunch of server instances for ECH draft-13
> interop as described below and at [1].
>
> - OpenSSL s_server: draft-13.esni.defo.ie:8413 using all algs
> - OpenSSL s_server: draft-13.esni.defo.ie:8414 likely forces
>  HRR as it only likes P-384 for TLS
> - lighttpd: draft-13.esni.defo.ie:9413
> - nginx: draft-13.esni.defo.ie:10413
> - apache: draft-13.esni.defo.ie:11413
> - haproxy: draft-13.esni.defo.ie:12413 shared mode
> (haproxy terminates TLS)
> - haproxy: draft-13.esni.defo.ie:12414 split mode
> (haproxy only decrypts ECH)
>
> Those all use the latest branch of my OpenSSL fork [2]. There
> are links to the server source for each at [1]. Each of the
> above have keys (well, the same key:-) published in DNS.
>
> I also think my (of course still radically imperfect:-) code
> interops with boringssl and the test server Cloudflare have
> put up. I've still to try get HRR working in split mode but
> will be working on that shortly, other than that though, the
> spec seems implementable, if complex for my wee brain:-)
>
> Those aren't setup to be resilient as I'd like to see some
> detail if they crash, so in that case, or if stuff just
> doesn't work, mail me and we can figure a way to test stuff.
>
> Cheers,
> S.
>
> [1] https://defo.ie/
> [2] https://github.com/sftcd/openssl/tree/ECH-draft-13a
> ___
> 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] ECH AAD for HRR

[Christopher Patton]

Yup, that was my interpretation as well.

On Wed, Sep 1, 2021 at 10:14 AM David Benjamin 
wrote:

> That's right. The AAD and actual CH should be exactly the same, apart from
> the payload being zeroed in place. You don't need to reserialize the
> structure as a server, or serialize ClientHelloOuter twice as a client.
>
> On Wed, Sep 1, 2021 at 1:01 PM Stephen Farrell 
> wrote:
>
>>
>> (Apologies for the acronym laden subject:-)
>>
>> I'm more or less at the "code complete" stage of
>> implementing draft-13 incl. HRR. (If anyone wants
>> to try interop, for now please contact me, but I
>> should have a server up in a few days.) I'm sure
>> as usual I'll have gotten some details wrong, but
>> I wasn't clear about one thing:
>>
>> - When sending the 2nd CH following HRR, the spec
>> calls for omitting the "enc" field of the ECH
>> extension ("enc" holds the sender's public HPKE
>> value that's re-used from the 1st CH).
>> - The AAD for that ECH encryption is the outer
>> CH with zeros replacing where the ciphertext will
>> go.
>> - I concluded that the sender's ECH public value
>> (the "enc" field) ought not be present in the
>> AAD in that case, as well as being omitted in
>> the ECH value, but it wasn't entirely clear to me
>> from the spec (and it'd work either way).
>>
>> So my question is: did I get that right or not?
>>
>> Thanks in advance,
>> S.
>>
>> ___
>> 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] I-D Action: draft-ietf-tls-esni-13.txt

[Christopher Patton]

On it! Lucky 13!

Chris P.

On Thu, Aug 12, 2021 at 9:42 AM Christopher Wood 
wrote:

> With -13 now out, I'd like to remind folks of the interop and
> implementation wiki pages available here:
>
> - https://github.com/tlswg/draft-ietf-tls-esni/wiki/Interop
> - https://github.com/tlswg/draft-ietf-tls-esni/wiki/Implementations
>
> If you have an implementation, please add it to the list!
>
> Thanks,
> Chris
>
> On Thu, Aug 12, 2021, at 9:32 AM, internet-dra...@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Transport Layer Security WG of the IETF.
> >
> > Title   : TLS Encrypted Client Hello
> > Authors : Eric Rescorla
> >   Kazuho Oku
> >   Nick Sullivan
> >   Christopher A. Wood
> >   Filename: draft-ietf-tls-esni-13.txt
> >   Pages   : 48
> >   Date: 2021-08-12
> >
> > Abstract:
> >This document describes a mechanism in Transport Layer Security (TLS)
> >for encrypting a ClientHello message under a server public key.
> >
> > Discussion Venues
> >
> >This note is to be removed before publishing as an RFC.
> >
> >Source for this draft and an issue tracker can be found at
> >https://github.com/tlswg/draft-ietf-tls-esni
> >(https://github.com/tlswg/draft-ietf-tls-esni).
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-tls-esni-13.html
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-13
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > ___
> > 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] What's it called

[Christopher Patton]

I've heard this called "rekeying". The amount of data that's safe to
authenticate and encrypt is usually called the "safety margin".

Chris P.

On Thu, Jun 24, 2021 at 10:32 AM Salz, Rich  wrote:

> I’m blanking on a term and web searches turn up too much useless info.
>
>
>
> What is it called when we have to start using a new symmetric key because
> we’ve encrypted too much data with the old one?  Key exhaustion fits, but
> probably isn’t it.
>
>
>
>
> ___
> 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] Editorial: chronological order in ECH draft

[Christopher Patton]

+1 to new readers! I think a chronological description would be a good
starting point, though like MT, I suspect there would be rearranging to do
afterwards that would break with a strictly chronological description.

Chris P.

On Wed, Jun 23, 2021 at 4:48 PM Stephen Farrell 
wrote:

>
>
> On 24/06/2021 00:37, Martin Thomson wrote:
> > Whatever you can do to improve the readability of this document would
> > be greatly appreciated.
>
> +1 though I have to admit I've really been mostly looking
> at diffs at this stage - probably some new readers/coders
> are needed,
>
> S.
>
> > It's a complicated design and I always spend
> > far too much time trying to find answers to my questions.  A better
> > structure would be appreciated.
> >
> > I do find that questions aren't always about behaviour.  They are
> > also about protocol elements, and those a scattered piecemeal
> > throughout.  So I would be disappointed if any restructuring were
> > limited to just getting the time sequence straightened out.
> >
> > On Thu, Jun 24, 2021, at 09:04, Carrick Bartle wrote:
> >> Hi all,
> >>
> >> I'm bringing
> >> https://github.com/tlswg/draft-ietf-tls-esni/issues/412 to the list
> >> since it looks like we're (hopefully) getting close to the end game
> >> with ECH.
> >>
> >> The ECH draft is currently organized such that it describes all
> >> client behavior and then all server behavior. Personally, I find
> >> this very confusing to follow, and I'm constantly having to flip
> >> back and forth between sections (which themselves constantly refer
> >> to each other). Does anyone object to my rearranging the content to
> >> be in more of the order in which things occur rather than being
> >> divided into client and server sections? Of course, depending on
> >> how I do it, it could end up being *more* confusing, but I just
> >> wanted to see if people were opposed to it in principle.
> >>
> >> Carrick ___ 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

Re: [TLS] ECH Padding

[Christopher Patton]

I support adopting #443. For the server side, I have a weak preference for
#457 (2) over #313 (3) because it makes it easier to implement a complete
solution. I have not yet assessed how hard it is to implement ... perhaps
it would be best if we all tried it out in our respective stacks and report
back on the complexity?

Chris P.

On Tue, Jun 22, 2021 at 3:56 PM Martin Thomson  wrote:

> So I like #443 as I have said.  It simplifies padding for CHInner a lot.
>
> I also like #457 (option 3).  My initial reaction was not positive, but
> I've come to appreciate the value of it.  I don't like that this has to be
> in the transcript (QUIC doesn't need it by virtue of a design that
> separates protection levels from content type), but as far as solutions go
> it is the easiest to implement.  In other words, it has the fewest awful
> shortcomings - a benchmark that has come to define ECH.
>
> On Wed, Jun 23, 2021, at 07:27, Christopher Patton wrote:
> > Hi all,
> >
> > One of the last design questions for Encrypted ClientHello (ECH) is to
> > decide how to pad encrypted handshake messages so that their length
> > does not leak privacy-sensitive handshake-parameters. The current
> > approach is to insert padding into the record layer as needed. However,
> > the consensus reached in [1] is that computing record-layer padding
> > based on the contents of handshake messages entails implementation
> > complexity that is untenable, particularly for QUIC and DTLS. The
> > alternative that most folks are happy with is to insert padding into
> > the handshake messages themselves, as this prevents details of the
> > handshake logic from bleeding into the record layer code.
> >
> > There are a few PRs for adding handshake-level padding that we could
> > use feedback on.
> >
> > (1) https://github.com/tlswg/draft-ietf-tls-esni/pull/443 Adds
> > padding to EncodedClientHelloInner, the message that is encrypted and
> > stuck into the ECH extension of the ClientHelloOuter. This prevents
> > leakage of sensitive parameters in ClientHelloInner.
> >
> > (2) https://github.com/tlswg/draft-ietf-tls-esni/pull/313 Defines a
> > new extension, which the client sends in ClientHelloInner in order to
> > solicit a response in the backend server's EncryptedExtensions message.
> > The server''s response contains padding it can use to prevent leakage
> > of sensitive parameters in its first flight of handshake messages.
> >
> > (3) https://github.com/tlswg/draft-ietf-tls-esni/pull/457
> > (alternative to (2)) Defines a new handshake message, Padding, which
> > the client and backend server always send just before Finished in case
> > of ECH acceptance. One advantage of this approach over (2) is that the
> > length of the padding can be evaluated after the
> > Certificate/CertificateVerify messages have been chosen, making it
> > possible to account for sensitive parameters in these messages without
> > needing to buffer the whole flight of messages. The downside is that it
> > may add complexity to the state machine of TLS 1.3 implementations.
> >
> > There are some open questions regarding how to compute the padding
> > length, but these should be orthogonal to deciding the mechanism.
> >
> > Thanks on behalf of (some of) the contributors,
> >
> > Chris P.
> > 
> > [1] "Handshake-level vs record-level padding."
> > https://github.com/tlswg/draft-ietf-tls-esni/issues/264
> > ___
> > 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] ECH Padding

[Christopher Patton]

> (1) aka #443 is the way to go here I think. (Such an aptly
> numbered PR has to be accepted I'd say:-) I'm only convinced
> of that because of QUIC, but that seems like enough or a
> rationale.
>
> I'm against (3) - it'd break too much and cost too much.
>
> WRT (2) I'd prefer to drop that extensibility rather than
> try use it because it's there.
>


Just to be clear, (1), (2) and (3) are not alternatives to the same
problem. (1) solves client-side padding, whereas (2) and (3) are
alternatives for solving server-side padding.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] ECH Padding

[Christopher Patton]

Hi all,

One of the last design questions for Encrypted ClientHello (ECH) is to
decide how to pad encrypted handshake messages so that their length does
not leak privacy-sensitive handshake-parameters. The current approach is to
insert padding into the record layer as needed. However, the consensus
reached in [1] is that computing record-layer padding based on the contents
of handshake messages entails implementation complexity that is untenable,
particularly for QUIC and DTLS. The alternative that most folks are happy
with is to insert padding into the handshake messages themselves, as this
prevents details of the handshake logic from bleeding into the record layer
code.

There are a few PRs for adding handshake-level padding that we could use
feedback on.

(1) https://github.com/tlswg/draft-ietf-tls-esni/pull/443 Adds padding
to EncodedClientHelloInner, the message that is encrypted and stuck into
the ECH extension of the ClientHelloOuter. This prevents leakage of
sensitive parameters in ClientHelloInner.

(2) https://github.com/tlswg/draft-ietf-tls-esni/pull/313 Defines a new
extension, which the client sends in ClientHelloInner in order to solicit a
response in the backend server's EncryptedExtensions message. The server''s
response contains padding it can use to prevent leakage of sensitive
parameters in its first flight of handshake messages.

(3) https://github.com/tlswg/draft-ietf-tls-esni/pull/457 (alternative
to (2)) Defines a new handshake message, Padding, which the client and
backend server always send just before Finished in case of ECH acceptance.
One advantage of this approach over (2) is that the length of the padding
can be evaluated after the Certificate/CertificateVerify messages have been
chosen, making it possible to account for sensitive parameters in these
messages without needing to buffer the whole flight of messages. The
downside is that it may add complexity to the state machine of TLS 1.3
implementations.

There are some open questions regarding how to compute the padding length,
but these should be orthogonal to deciding the mechanism.

Thanks on behalf of (some of) the contributors,

Chris P.

[1] "Handshake-level vs record-level padding."
https://github.com/tlswg/draft-ietf-tls-esni/issues/264
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH-10 interop test server

[Christopher Patton]

Hi Rob, today we're currently rolling out an update to crypto.cloudflare.com
that disables support for P-384 and P-521. This should allow you to easily
trigger HRR.

Chris P.

On Mon, Jun 7, 2021 at 9:24 AM Christopher Patton 
wrote:

> Hi Rob, let me look into it.
>
> Chris P.
>
> On Fri, May 28, 2021 at 11:36 AM Rob Sayre  wrote:
>
>> On Mon, Apr 5, 2021 at 10:02 AM Christopher Patton > 40cloudflare@dmarc.ietf.org> wrote:
>>
>>> Hi list, just FYI that Cloudflare's test server is upgrading to
>>> draft-ietf-tls-esni-10 this morning. It should finish rolling out in a few
>>> hours. Note that we've dropped support for draft-ietf-tls-esni-09.
>>>
>>> The endpoint is https://crypto.cloudflare.com. You'll also find our ECH
>>> config in the HTTPS resource record.
>>>
>>
>> I've gotten a Rustls client to interoperate with this server, but I had
>> some trouble triggering HRR, since Rustls always sends a key-exchange group
>> in TLS 1.3. I managed to hack up a ClientHello and handshake with no
>> initial key-exchange group, but perhaps it could be easier.
>>
>> It might be nice to have this server reject secp384r1 and offer X25519 in
>> an HRR, or something like that.
>>
>> thanks,
>> Rob
>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH-10 interop test server

[Christopher Patton]

Hi Rob, let me look into it.

Chris P.

On Fri, May 28, 2021 at 11:36 AM Rob Sayre  wrote:

> On Mon, Apr 5, 2021 at 10:02 AM Christopher Patton  40cloudflare@dmarc.ietf.org> wrote:
>
>> Hi list, just FYI that Cloudflare's test server is upgrading to
>> draft-ietf-tls-esni-10 this morning. It should finish rolling out in a few
>> hours. Note that we've dropped support for draft-ietf-tls-esni-09.
>>
>> The endpoint is https://crypto.cloudflare.com. You'll also find our ECH
>> config in the HTTPS resource record.
>>
>
> I've gotten a Rustls client to interoperate with this server, but I had
> some trouble triggering HRR, since Rustls always sends a key-exchange group
> in TLS 1.3. I managed to hack up a ClientHello and handshake with no
> initial key-exchange group, but perhaps it could be easier.
>
> It might be nice to have this server reject secp384r1 and offer X25519 in
> an HRR, or something like that.
>
> thanks,
> Rob
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Don't Split HelloRetryRequest

[Christopher Patton]

HI Martin, all, I added another alternative, so let me summarize for
everyone the possible paths forward, with links to the corresponding PRs.

1. https://github.com/tlswg/draft-ietf-tls-esni/pull/407: HRRInner and
HRROuter (original proposal, deemed too complicated).
2. https://github.com/tlswg/draft-ietf-tls-esni/pull/417: Strengthen
language around HRR-sensitive parameters (might be underspecified).
3. https://github.com/tlswg/draft-ietf-tls-esni/pull/423  Signal ECH
acceptance after HRR (a simpler alternative to #407).

Best,
Chris P.

On Mon, Apr 5, 2021 at 7:29 PM Martin Thomson  wrote:

> I've created a few pull requests that make the changes I propose.  I think
> that the whole suite of related issues are closed as a result.
>
> The main one is here:
> https://github.com/tlswg/draft-ietf-tls-esni/pull/417
> There's a bit of rewriting here, but the change is not that large.  I
> would expect most implementations to be compliant already (it's much more
> work not to be).
>
> The whole set:
> https://github.com/tlswg/draft-ietf-tls-esni/pulls/martinthomson
>
> On Thu, Apr 1, 2021, at 12:57, Martin Thomson wrote:
> > I just reviewed the proposal to split HelloRetryRequest into outer and
> > (encrypted) inner.
> >
> > https://github.com/tlswg/draft-ietf-tls-esni/pull/407/files
> >
> > I'm strongly opposed to taking the change.  It complicates the design
> > greatly and unnecessarily.
> >
> > The existing design has some flaws, but they can be fixed more
> > elegantly than this.
> >
> > (Apologies if this seems a little long.  I'm writing down every
> > possible argument I can think of, because I can't guarantee that I will
> > be coherent at the meeting.)
> >
> > # HelloRetryRequest Has a Narrow Purpose
> >
> > Let's first address the key question of what HelloRetryRequest exists
> > to do.  It exists to ensure that the client and server are able to
> > jointly agree on keys to use for the remainder of the handshake.  This
> > is a very narrow scope.
> >
> > Furthermore, the particulars of key agreement are public.  This is
> > important as we can also say that all hidden servers need to use the
> > same configuration as it relates to cipher suites, key exchange, and
> > related parameters, as the results of negotiation are sent in the clear
> > in the ServerHello.
> >
> > My claim here is that there is no value in protecting any parameter
> > that might change in response to HelloRetryRequest.
> >
> > # Don't Seek Complexity
> >
> > It is entirely possible to imagine scenarios where an inner ClientHello
> > has different preferences from an outer ClientHello.  While in theory
> > we can construct a design that would support that (the pull request
> > does this well enough), to do so only serves to increase complexity.
> > It does not address any real use case or problem that I'm aware of.
> >
> > If we allow for the client to provide different values in inner and
> > outer ClientHello messages, then the current design means that the
> > client is faced with some ambiguity about which of the two messages a
> > HelloRetryRequest applies to.  If we try to create an indicator, then
> > that leaks.
> >
> > We could solve the problem by making the protocol more complex.  Or we
> > could avoid it.
> >
> > This problem is entirely avoidable.
> >
> > # Matching Inner and Outer Values
> >
> > When we get right down to it, there are a very small number of things
> > that truly change in response to HelloRetryRequest.  And all of these
> > changes are to values that do not need confidentiality protection.
> >
> > The draft lists three fields that change: ciphersuites, key_share, and
> > version.  From my perspective, changing cipher suites, supported
> > groups, or versions would be a big mistake.  So what changes is even
> > more limited.  Just the shares in key_share.
> >
> > On this basis, a client that offers cipher suites, groups, versions,
> > and key shares that are identical in both inner and outer ClientHello
> > messages will always receive a HelloRetryRequest that applies equally
> > to both messages.
> >
> > The only adjustment that is acceptable with respect to these fields
> > being identical is the addition of TLS 1.2-only options to the outer
> > ClientHello (or the removal of the same from the inner ClientHello if
> > you prefer it that way around).  This is a fine optimization on the
> > basis that accepting ECH represents a commitment to support TLS 1.3 (or
> > higher).  But it is really just an optimization (the draft makes this
> > mandatory, which is silly).  The client can therefore remove options
> > from the inner ClientHello only if it is impossible to select them with
> > TLS 1.3 or higher.
> >
> > For new extensions, if they define a means of adjustment or correction
> > via HelloRetryRequest (there is currently just one: password_salt,
> > which I haven't examined), then they too need to follow this
> > restriction.   It's not an onerous one.
> >
> > Follow this simple constraint and 

Re: [TLS] ECH-10 interop test server

[Christopher Patton]

Yup, we she it add this. Just so you know, the buck stops with me here :)
I've been meaning to build an ECH status page but haven't gotten around to
it.

On Wed, Apr 7, 2021 at 3:12 PM Rob Sayre  wrote:

>
>
> On Wed, Apr 7, 2021 at 3:09 PM Christopher Patton  40cloudflare@dmarc.ietf.org> wrote:
>
>>
>> (In case it helps someone else...) Is there any way that the
>>> HTTP response content could differ if ECH succeeded or not?
>>> I'm seeing the same 302 response in either case I think but
>>> maybe there's some specific pathname or something that'd
>>> result in different HTTP responses?
>>>
>>
>> That's right, we're just redirecting most HTTP requests to the spec right
>> now.
>>
>
> FWIW, I found this confusing as well. I'd expect a 200 "It worked!"
> response if ECH interoperated.
>
> thanks,
> Rob
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH-10 interop test server

[Christopher Patton]

> (In case it helps someone else...) Is there any way that the
> HTTP response content could differ if ECH succeeded or not?
> I'm seeing the same 302 response in either case I think but
> maybe there's some specific pathname or something that'd
> result in different HTTP responses?
>

That's right, we're just redirecting most HTTP requests to the spec right
now.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] ECH-10 interop test server

[Christopher Patton]

Hi list, just FYI that Cloudflare's test server is upgrading to
draft-ietf-tls-esni-10 this morning. It should finish rolling out in a few
hours. Note that we've dropped support for draft-ietf-tls-esni-09.

The endpoint is https://crypto.cloudflare.com. You'll also find our ECH
config in the HTTPS resource record.

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Don't Split HelloRetryRequest

[Christopher Patton]

One way HRR is used is in case the client's and server's cipher suite
> preferences don't intersect. This feature is an essential part of TLS, as
> there's no a priori reason why the client and server will initially
> advertise overlapping preferences. (They usually do, hence the claim that
> HRR is rare.) I don't think aborting the handshake instead of HRR is an
> acceptable solution, as this would mean there are deployments with which
> TLS couldn't be used.
>

Slight refinement: David B. pointed out to me that "cipher suite
preference" isn't quite the right term here. The client provides key shares
in its CH that it guesses the server can use; if it's wrong, then the
server replies with HRR. A more accurate statement would be that "HRR is
essential for ensuring the client sends a key share the server supports."
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Don't Split HelloRetryRequest

[Christopher Patton]

> But let me ask a question meanwhile - how often does HRR
> actually happen and could we not just let ECH fail in a
> bunch of situations that would otherwise require all this
> new complexity?
>

One way HRR is used is in case the client's and server's cipher suite
preferences don't intersect. This feature is an essential part of TLS, as
there's no a priori reason why the client and server will initially
advertise overlapping preferences. (They usually do, hence the claim that
HRR is rare.) I don't think aborting the handshake instead of HRR is an
acceptable solution, as this would mean there are deployments with which
TLS couldn't be used.

Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Don't Split HelloRetryRequest

[Christopher Patton]

Hi Martin, would you mind working out a PR? I think being able to compare
407 to a concrete alternative would be helpful. Just so that we're on the
same page, here's a quick summary of the issues that 407 is designed to
solve. (These may or may not be problems in your view, and I don't claim
this list is exhaustive.)
- 233: No acceptance signal until after HRR, so the procedure for computing
CH2 is underspecified. This can be avoided by advertising the same
preferences in CHI/CHO, but the spec doesn't require this.
- 373: To fix 3233, can we put an acceptance signal in HRR.random? Probably
not, since HRR.random has a value specified in RFC8446.
- 358: RFC8446 allows the value of an extension in CH2 to differ from CH1
only if the extension appears in HRR.
- 333: "Split mode" is broken, since the client doesn't know who the cookie
is for.

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Solving HRR woes in ECH

[Christopher Patton]

I really like this idea, but I don't see it as a solution to ECH's HRR
woes. NIck's idea boils down to providing a recipe for how to construct the
CHOuter, but AFAICT, there's nothing in the TLS or HTTPS-RR specs that
requires the client to follow this recipe. We would still need a way of
reconciling differences in preferences between CHInner and CHOuter.

I think we should pursue using HTTPS-RR this way independently of ECH. It's
not just useful for ECH, after all. All connections would benefit from
knowing the server's preferences in advance of the ClientHello.

Chris P.

On Fri, Mar 26, 2021 at 8:10 AM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 26/03/2021 13:44, Ben Schwartz wrote:
> > This seems like a reasonable suggestion to me, so long as the value is
> > purely a "hint", as you seem to be proposing.  I would suggest
> structuring
> > it as an ECHConfig extension.  This would avoid the need for multiple
> > points of integration between TLS and DNS, support the use of HRR hints
> in
> > other ECH use cases that don't involve DNS, and help to exercise the
> > ECHConfig extension mechanism.
>
> (I'm not stating an opinion on the PR yet but...) If there
> is to be some new data included in SVCB/HTTPS RR values then
> that ought be structured bearing in mind who produces which
> bits of data. An ECHConfig is a binary blob mostly produced
> by the client-facing server, whereas TLS parameters for the
> backend server are not produced at the same place. Including
> the latter as an ECHConfig.extension is not therefore a good
> design IMO. Justifying those (IMO:-) unnecessary ECHConfig
> extensions is also not a goal.
>
> Information about the backend's TLS preferences, if published
> in the DNS, ought be outside the ech value in HTTPS RRs. If
> we wanted to publish information about the client-facing
> server's TLS preferences in the backend's zone file, then
> that could be put into the ECHConfig all right. (It's a pity
> that we didn't split out the ECHConfigs from different
> client-facing servers in SVCB/HTTPS to make all that easier
> isn't it?)
>
> Cheers,
> S.
>
> >
> > On Thu, Mar 25, 2021 at 9:28 PM Nick Sullivan  > 40cloudflare@dmarc.ietf.org> wrote:
> >
> >> Hi Chris,
> >>
> >> HRR in ECH does seem challenging. This may be tangential to the PR you
> >> linked, but there may be a way to reduce the likelihood of HRR by moving
> >> even more of the handshake negotiation into DNS. The HTTPS RR is already
> >> used for some types of negotiation (ALPN and ECH key), so why can't it
> be
> >> extended further to advertise to the client what the server is willing
> to
> >> support for cryptographic negotiations?
> >>
> >> For example, the HTTPS record could additionally contain the server's
> >> supported supported_groups and cipher_suites. With this information, a
> >> client could know which key_share extensions a server is likely to
> accept
> >> and adjust its clienthello accordingly. A client who typically sends two
> >> key_shares (P256 and x25519) for maximal compatibility could then reduce
> >> the size of its client hello (no need to send redundant key_shares) or
> even
> >> prevent an HRR flow altogether in the case that the default key_shares
> or
> >> cipher_suites are not supported by the server.
> >>
> >> This tweak wouldn't remove the need for HRR completely -- it could be
> >> necessary when changing server configuration, for example -- but it
> could
> >> remove the need for HRR in the common case.
> >>
> >> Nick
> >>
> >> On Thu, Mar 25, 2021 at 8:05 PM Christopher Patton  >> 40cloudflare@dmarc.ietf.org> wrote:
> >>
> >>> Hi all,
> >>>
> >>> One of the open issues for ECH is how it interacts with
> HelloRetryRequest
> >>> (HRR). The central difficulty is that a client may advertise different
> >>> preferences for HRR-sensitive parameters in the ClientHelloInner and
> >>> ClientHelloOuter. And because the HRR path has no explicit signal of
> which
> >>> ClientHello was used, the client may not be able to know how to
> respond.
> >>> The following PR solves this problem by adding to HRR an explicit
> signal of
> >>> which ClientHello was used:
> >>> https://github.com/tlswg/draft-ietf-tls-esni/pull/407
> >>>
> >>> The design was originally proposed by David Benjamin in the issue
> >>> referenced by the PR. Along the way, It also solves a handful 

[TLS] Solving HRR woes in ECH

[Christopher Patton]

Hi all,

One of the open issues for ECH is how it interacts with HelloRetryRequest
(HRR). The central difficulty is that a client may advertise different
preferences for HRR-sensitive parameters in the ClientHelloInner and
ClientHelloOuter. And because the HRR path has no explicit signal of which
ClientHello was used, the client may not be able to know how to respond.
The following PR solves this problem by adding to HRR an explicit signal of
which ClientHello was used:
https://github.com/tlswg/draft-ietf-tls-esni/pull/407

The design was originally proposed by David Benjamin in the issue
referenced by the PR. Along the way, It also solves a handful of other HRR
issues that have been identified.

One consequence of this particular solution is that real ECH usage "sticks
out" if the server responds with an HRR. In particular, signaling which
ClientHello was used also signals whether ECH was accepted. However, the
solution is designed to mitigate "don't stick out" attacks that attempt to
trigger the HRR codepath by fiddling with bits on the wire. The
distinguisher only arises when HRR happens organically.

Feedback is appreciated!

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?

[Christopher Patton]

> I think the right thing here would be to analyse that attack
> again and re-evaluate which of the two answers now seems
> best. For me, the github issue discussion didn't leave
> behind enough information to do that. (Or I need to stare
> at it some more maybe:-)
>

If we constrain the model so that the "don't stick out" attacker is
passive, then PR#287 (https://github.com/tlswg/draft-ietf-tls-esni/pull/287
suffices). The attack described at the top of PR#353 (
https://github.com/tlswg/draft-ietf-tls-esni/pull/353) is what led everyone
to agree that the acceptance confirmation needed to be derived from the
secret shared by the client and backend server. It's an active "don't stick
out" attack. Basically, the attacker replies to the client's CH with a
bogus SH; and by observing the client's reply, it can learn whether the
client sent real or GREASE ECH. There are a number of variants of this
basic attack, some of which can be pulled off without actually tipping off
most clients.

If we intend to thwart active "don't stick out" distinguishers, then PR#353
seems necessary to me. The key difference between PR#287 and PR#353 is
that, in the latter, the secret used to derive the acceptance signal is
authenticated. This isn't true in the former. I don't think trying to find
a middle ground between PR#353 and PR#287 will be fruitful, unless we can
hack in backend-server authentication by some means other than the
handshake signature.

Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?

[Christopher Patton]

> I forget, did we need to bind it to the actual handshake secret, or was
> the transcript and ClientHelloInner.random sufficient? That would avoid the
> circular processing dependency.
>

As I recall, it was decided to bind the acceptance signal to the handshake
signal in order to mitigate some specific, active, "don't-stick-out"
attacks.

Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Moving the ECH interop target

[Christopher Patton]

Hey Stephen, I'd imagine the CF server will stay at ECH-10 through IETF 110.

Best,
Chris P.

On Wed, Feb 24, 2021 at 1:13 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 24/02/2021 18:07, Christopher Wood wrote:
> > The WG previously decided to make draft-ietf-tls-esni-09 the official
> target for interop. The diff between this version and the current editor's
> copy of the draft is below:
> >
> >
> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-tls-esni.txt=https://tlswg.github.io/draft-ietf-tls-esni/draft-ietf-tls-esni.txt
> >
> > Given the size of the diff, and the recent update to HPKE to prepare it
> for IRSG review, I'd like to propose that we cut -10 (when the datatracker
> opens) and use that as the new interop target. This will resolve the moving
> HPKE target going forward and let that part of the protocol stabilize.
> >
> > What do other implementers think?
>
> That's generally ok, but from my POV it would be
> better to give it another week or two before we
> do that, e.g. maybe just after IETF-110 or so.
>
> Reason is I've nearly but not quite got -09
> interop between (currently mega-hacked;-) OpenSSL
> code and the NSS client, and then hopefully
> the CF server and would prefer have that done
> before we start moving the target again.
>
> OTOH, if the CF -09 server were to remain
> available for a bit, then I'd be fine with
> this change at any time.
>
> Cheers,
> S.
>
>
> >
> > Thanks,
> > Chris (no hat)
> >
> > ___
> > 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] [ECH] Reverting the config ID change

[Christopher Patton]

Hi Chris, all,


On the heels of this change, here's another PR that I'd folks to weigh in
> on:
>
>https://github.com/tlswg/draft-ietf-tls-esni/pull/381
>
> Thanks,
> Chris
>

I support this change as-is. It seems to me that a 1-byte config_id
provides enough flexibility to support any use case we have envisioned thus
far. I suggest we pull the trigger on it.

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH -09 interop

[Christopher Patton]

Hi Rob, all,

Cloudflare is now running an ECH test server here:
https://crypto.cloudflare.com

We're running draft-ietf-tls-esni-09. The HTTPS resource record containing
the current ECH config is available in DNS.

Please let me know if you observe any bugs or otherwise have issues. Our Go
implementation can be found here:
https://github.com/cloudflare/go/tree/cf/src/crypto/tls

Thanks! And for those in the US, happy inauguration day!
- Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-esni-09.txt

[Christopher Patton]

Hi Stephen,

ECH-09 is meant to use HPKE-07, as declared in the body:
https://www.ietf.org/archive/id/draft-ietf-tls-esni-09.html#name-encrypted-clienthello-confi

Although it looks the draft didn't get updated in the references somehow:

[I-D.irtf-cfrg-hpke] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", Work in Progress, Internet-Draft,
draft-irtf-cfrg-hpke-06, 23 October 2020, <
http://www.ietf.org/internet-drafts/draft-irtf-cfrg-hpke-06.txt
>.

Also, +1 for targeting ECH-09 for interop!

Chris P.

On Wed, Dec 16, 2020 at 8:13 AM Stephen Farrell 
wrote:

>
> Hiya,
>
> I'd like it were this version to be aiming to be for
> interop. But it refers to hpke-06 when hpke-07 was
> published ~90 minutess before this.
>
> So, if we do want interop for this, I guess it'd be
> best to push out -10 before the holidays with a ref
> to hpke-07? Or to just declare that the interop target
> is esni-09 with hpke-07? Or, are we not aiming for
> interop still?
>
> S.
>
> On 16/12/2020 16:02, internet-dra...@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Transport Layer Security WG of the IETF.
> >
> >  Title   : TLS Encrypted Client Hello
> >  Authors : Eric Rescorla
> >Kazuho Oku
> >Nick Sullivan
> >Christopher A. Wood
> >   Filename: draft-ietf-tls-esni-09.txt
> >   Pages   : 40
> >   Date: 2020-12-16
> >
> > Abstract:
> > This document describes a mechanism in Transport Layer Security (TLS)
> > for encrypting a ClientHello message under a server public key.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-tls-esni-09.html
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-09
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > ___
> > 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] ECH: Reuse HPKE context across HRR

[Christopher Patton]

Hi list,

In case the server sends a HelloRetryRequest (HRR) the client generates a
fresh ECH extension, including generating a fresh HPKE context and
corresponding encapsulated key. The following PR changes the spec so that
the HPKE context generated for the first ECH extension is reused to compute
the second:
https://github.com/tlswg/draft-ietf-tls-esni/pull/352

This design has at least two advantages:

   1. Currently the spec requires the HPKE context to export a PSK, which
   in turn is used to generate the second HPKE context. This means that the
   client (resp. the server) has to implement both SetupS() (resp. SetupR())
   and SetupPSKS() (resp. SetupPSKR()). Advancing the HPKE sequence number
   before encrypting the second ClientHelloInner appears to serve the same
   purpose as the PSK (see {{flow-hrr-hijack}}.) The advantage of the new
   design is that the client (resp. the server) doesn't have to implement
   SetupPSKS() (resp. SetupPSKR()).
   2. Instead of two decapsulation operations --- one for the first CH and
   another for the second --- the server does just one decapsulation. Not only
   is this slightly more economical, it avoids edge cases that arise when
   decapsulation is offloaded to an RPC server. This allows us to simplify the
   server-side HRR logic considerably.

We're wondering if anyone can think of any disadvantages to this design.
Feedback on the PR is greatly appreciated!

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Outstanding issues for ECH

[Christopher Patton]

Hiya list,

[Re-sending this email with a subject. Apologies for the spam!]

Chris Wood plans to publish the next draft of the ECH extension by the end
of the week (or early next week). As such, I wanted to give you all a brief
run-down on the open issues, some of which won't be resolved until a later
draft. The numbers below refer to GitHub issues:
https://github.com/tlswg/draft-ietf-tls-esni/issues

We would like to resolve the following before -08:

#323: Replace "inner_digest" mechanism with authentication of
ClientHelloOuter. In case of ECH acceptance, the only part of the
ClientHelloInner that is authenticated are the outer extensions
incorporated into the ClientHelloInner. David Benjamin contributed a PR
that sets the associated data for AEAD encryption to the ClientHelloOuter
(sans the ECH extension). This was previously not possible because of PSK
binders in the ClientHelloOuter. This is no longer an issue, however, since
we decided at Interim 2 to disallow session resumption in the
ClientHelloOuter. PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/336

#325: The server shouldn't change its mind about ECH usage after HRR, since
switching from ClientHelloInner to ClientHelloOuter (or vice versa) could
trigger yet another HRR.
https://github.com/tlswg/draft-ietf-tls-esni/pull/339

There remain at least two problem areas, which won't be resolved until
after -08.

#233, #333: Our experience with implementing ECH has shown that HRR
behavior still needs to be fleshed out. First,  the client needs to ensure
that HRR-sensitive parameters match in the ClientHelloInner /
ClientHelloOuter. While it's fairly straightforward to get this right,
there are tons of ways in which implementations can get this right. We
would like to provide guidance on this (#233), but saying which parameters
are "HRR-sensitive" and which aren't is not straightforward. Chris Wood has
a PR for this, but we don't yet have consensus on it. Second, the server
needs to ensure that ECH usage doesn't change across the HRR. This is
straightforward for stateful-HRR servers (#325), but we have not yet
specified how stateless-HRR servers should do this. In fact, it's uncertain
how stateless-HRR would work in Split Mode at all (#333). PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/316

#264: Replace record-level padding with handshake-level padding in order to
resolve API-mismatch issues for QUIC. There's a PR for this, but we don't
yet have consensus on it. PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/313

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] (no subject)

[Christopher Patton]

Hiya list,

Chris Wood plans to publish the next draft of the ECH extension by the end
of the week (or early next week). As such, I wanted to give you all a brief
run-down on the open issues, some of which won't be resolved until a later
draft. The numbers below refer to GitHub issues:
https://github.com/tlswg/draft-ietf-tls-esni/issues

We would like to resolve the following before -08:

#323: Replace "inner_digest" mechanism with authentication of
ClientHelloOuter. In case of ECH acceptance, the only part of the
ClientHelloInner that is authenticated are the outer extensions
incorporated into the ClientHelloInner. David Benjamin contributed a PR
that sets the associated data for AEAD encryption to the ClientHelloOuter
(sans the ECH extension). This was previously not possible because of PSK
binders in the ClientHelloOuter. This is no longer an issue, however, since
we decided at Interim 2 to disallow session resumption in the
ClientHelloOuter. PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/336

#325: The server shouldn't change its mind about ECH usage after HRR, since
switching from ClientHelloInner to ClientHelloOuter (or vice versa) could
trigger yet another HRR.
https://github.com/tlswg/draft-ietf-tls-esni/pull/339

There remain at least two problem areas, which won't be resolved until
after -08.

#233, #333: Our experience with implementing ECH has shown that HRR
behavior still needs to be fleshed out. First,  the client needs to ensure
that HRR-sensitive parameters match in the ClientHelloInner /
ClientHelloOuter. While it's fairly straightforward to get this right,
there are tons of ways in which implementations can get this right. We
would like to provide guidance on this (#233), but saying which parameters
are "HRR-sensitive" and which aren't is not straightforward. Chris Wood has
a PR for this, but we don't yet have consensus on it. Second, the server
needs to ensure that ECH usage doesn't change across the HRR. This is
straightforward for stateful-HRR servers (#325), but we have not yet
specified how stateless-HRR servers should do this. In fact, it's uncertain
how stateless-HRR would work in Split Mode at all (#333). PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/316

#264: Replace record-level padding with handshake-level padding in order to
resolve API-mismatch issues for QUIC. There's a PR for this, but we don't
yet have consensus on it. PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/313

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 ECC Private Key Compromise? (was Re: Un-deprecating everything TLS 1.2)

[Christopher Patton]

> > Please just tell me why I'm wrong and I'll feel
> > better since we won't have to malign another cute
> > furry animal.
>

I've told you already why I believe you're wrong here. At this point, it
won't do much good to continue posting about this list on the list. My
suggestion to you is to study the problem offline, and If you find an
attack and can demonstrate the works, then bring it back to the list. It
would also be helpful to look at implementations in order to understand how
others have interpreted the HRR code path. I bet this would clear up many
of your questions.

Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Un-deprecating everything TLS 1.2

[Christopher Patton]

I agree that the HRR code path is hard to reason about, but I don't really
see an attack here. Is it your contention that the HRR code path leads to
an attack not accounted for by existing proofs?

I don't think this is likely. One way to think about this problem is as
follows [1]. Given an attacker that exploits the HRR code path, can you
efficiently construct an attacker that exploits a version of the protocol
without the HRR code path implemented? If the answer is "yes", and if we
assume the protocol is secure *without* the HRR code path implemented (as
asserted by a proof of security, say), it must be case that the protocol is
also secure *with* the HRR code path implemented.

Although I haven't studied this problem specifically ---  Dowling et al.
appear to address this problem, if only implicitly --- my intuition is that
the answer is "yes". The reason, loosely, is that the HRR code path doesn't
appear to depend on any ephemeral or long-term secret key material used by
the server for the core handshake. In particular, it doesn't depend on the
server's key share or signing key. This means that the adversary can
"simulate" any computation involving the HRR code path in its head, without
interacting with a real server. This observation ought to yield the
reduction I described above. Perhaps the spec is vague here, but if you
study any one of the high quality implementations that exist (openSSL,
boringSSL, NSS, Go's crypto/tls just to name a few), it won't be hard to
convince yourself that the HRR code path doesn't depend on secrets used in
the core handshake.


Chris P.

[1] https://eprint.iacr.org/2020/573

On Mon, Oct 5, 2020 at 2:47 PM Michael D'Errico  wrote:

> On 10/5/20 10:21, Christopher Patton wrote:
> > A couple pointers for getting started:
>
> Thank you for providing these links!  I'm going through
> the first one now and will note that it does not even
> mention the HelloRetryRequest message.  So while I am
> confident there has been quite a bit of study of a
> ClientHello -> ServerHello handshake, there may not
> have been much study of ClientHello1 -> HelloRetryRequest
> -> ClientHello2 -> ServerHello handshakes.
>
> I'm especially concerned about the fact that a "stateless"
> server does not even remember what the ClientHello1 or
> HelloRetryRequest messages were when it receives the
> second ClientHello.  Load-balanced data centers seem to
> do this based on some of the discussion I've had this
> week.
>
> The protocol handles the missing ClientHello1 message by
> replacing it with hash-of-ClientHello1, but then you're
> supposed to rely on the client to tell you this value in
> its ClientHello2.  Even if nothing funny is happening,
> how is the (stateless) server supposed to put the
> HelloRetryRequest message in the Transcript-Hash?  Where
> does it get this value from if it's not also somehow in
> the "cookie" (which is how the client reminds the server
> of hash-of-ClientHello1)?
>
> And how would you put the HelloRetryRequest message into
> the cookie extension when the cookie itself is a part of
> the HelloRetryRequest?
>
> Just trying to imagine the code I'd have to write to do
> this correctly makes my head spin:
>
>0)  [disable "TCP Fast Open" so I don't do lots of
>processing without knowing there's a routable
>address associated with the client]
>
>1)  receive ClientHello1
>
>2)  generate HelloRetryRequest message without cookie
>
>3)  package ClientHello1 and HelloRetryRequest-minus-
>cookie into a data structure, encrypt + MAC to
>create a cookie
>
>4)  insert the cookie into the HelloRetryRequest,
>remembering to update the length of the extensions
>
>5)  send HelloRetryRequest (with cookie) to client
>
>6)  erase all memory of what just happened!!!
>
>7)  receive ClientHello2
>
>8)  ensure it has a cookie extension (well I should
>at least remember the fact that I already sent a
>HelloRetryRequest and not be completely stateless,
>right?  Otherwise the client may be able to send
>many ClientHelloN's without a cookie)
>
>9)  check MAC on the cookie and if it's valid, decrypt
>it to determine the contents of ClientHello1 and
>the HelloRetryRequest (without cookie) messages
>
>10) MAKE SURE ClientHello2 is valid according to what
>was received in ClientHello1 (RFC 8446 has a list
>of things a client is allowed to do; I would want
>to check all of them, so a hash of ClientHello1
>is inadequate in my opinion).  This seems to be a
>necessary thing to do even for stateful servers.
>
>11) Recreate the actua

Re: [TLS] Un-deprecating everything TLS 1.2

[Christopher Patton]

A couple pointers for getting started:

   1. Check out Dowling et al.'s recent analysis. Published a month or so
   ago, it's the most recent proof of security of the full handshake (also
   includes PSK modes): https://eprint.iacr.org/2020/1044
   2. Check out Paterson and van der Merwe's survey of the body of papers
   that helped to shape TLS 1.3. It also overviews the myriad attacks against
   TLS 1.2 and below that catalyzed a more proactive design approach for 1.3:
   https://link.springer.com/chapter/10.1007/978-3-319-49100-4_7

If you're unable to download the second (2.), the same paper appears in a
slightly different form in van der Merwe's PhD thesis.

No analysis is perfect, but so far, 1.3 appears to be far superior to
1.0-1.2.

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ESNI/ECH: minor progress, much githubbery

[Christopher Patton]

Sweet! Please let me know if you find any bugs on my end.  Feel free to
chime in on the PR.

Chris P.

On Tue, Sep 29, 2020 at 11:00 AM Rob Sayre  wrote:

>
>
> On Tue, Sep 29, 2020 at 7:50 AM Christopher Patton 
> wrote:
>
>> Hi Rob,
>>
>>
>>> Are there OpenSSL / NSS / etc implementations others can work from?
>>> Probably the best way to lock this in and ship is to write the code.
>>>
>>
>> There are three implementations I'm aware of, all works in progress:
>>
>>1. Cloudflare's prototype (written by me):
>>https://github.com/cloudflare/go/pull/30
>>2. boringSSL:
>>https://bugs.chromium.org/p/boringssl/issues/detail?id=275
>>3. NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=1654332
>>
>> The first (1.) is nearly complete and undergoing review.
>>
>
> Great. I will work to get Rustls interoperating with it. The current
> code[1] only implements draft -02.
>
> thanks,
> Rob
>
> [1] https://github.com/ctz/rustls/pull/318
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ESNI/ECH: minor progress, much githubbery

[Christopher Patton]

Hi Rob,


> Are there OpenSSL / NSS / etc implementations others can work from?
> Probably the best way to lock this in and ship is to write the code.
>

There are three implementations I'm aware of, all works in progress:

   1. Cloudflare's prototype (written by me):
   https://github.com/cloudflare/go/pull/30
   2. boringSSL: https://bugs.chromium.org/p/boringssl/issues/detail?id=275
   3. NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=1654332

The first (1.) is nearly complete and undergoing review.

Best,
Chris P

On Mon, Sep 28, 2020 at 7:58 PM Rob Sayre  wrote:

> On Mon, Sep 28, 2020 at 12:55 PM Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>>
>> Hiya,
>>
>> Today I read over the diff between the latest ESNI/ECH
>> version and draft-07. [1] I have the following comments:
>>
>> 1. The volume of discussion on github is a deterrent. (*)
>>
>
> I agree the churn has seemed surprisingly heavy. The changes look
> well-meaning, but I don't really see a plan.
>
> Are there OpenSSL / NSS / etc implementations others can work from?
> Probably the best way to lock this in and ship is to write the code.
>
> thanks,
> Rob
>
> ___
> 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] Sabotage?

[Christopher Patton]

Hi Mike,

TLS 1.3 represents the best intentions of a huge number of contributors.
Compared to earlier versions of TLS, 1.3 received much more scrutiny, from
academics and industry folks alike. It's much more secure than earlier
versions of the protocol as a result of this process. For more on this, I'd
invite you to listen to Thyla van der Merwe's talk at Real World Crypto
2018: https://www.youtube.com/watch?v=t4caEr9hh98. The process isn't
perfect ... there may be bugs that lurk in TLS today, and bugs are likely
to arise as the protocol evolves. But the process hasn't been "hijacked".

Would you care to elaborate on your concerns around tracking of users?

Best,
Chris P.

On Sat, Sep 12, 2020 at 2:05 PM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hi Mike,
>
> This is a pretty big topic that’s been explored quite a bit.  The long
> term impact of these changes could be very positive.  I just published a
> book on the topic of embracing E2E among other topics after exploring the
> impact on operators in RFC8404.  In other words, both directions were
> explored to reach a possible way forward with increased security and how to
> get the control/visibility in order to embrace these changes.
>
> I’m happy to talk more, but fear the length of a thread on this list and
> may not keep up with it given my current workload.
>
> Best regards,
> Kathleen
>
> Sent from my mobile device
>
> > On Sep 12, 2020, at 11:07 AM, Michael D'Errico 
> wrote:
> >
> > Hi,
> >
> > I get a weird feeling that the internet is being hijacked and soon it
> will be impossible to reverse course.  I have not followed the development
> of TLS 1.3 but it seems very different from TLS 1.2. Also TLS 1.2 is very
> different from TLS 1.0/1.1 (which are being deprecated).  QUIC looked good
> at a glance, but it seems to rely on TLS to share key material, and also
> I'm more than a bit concerned about its capability to track users.
> >
> > Then there's Zoom video conferencing, where everybody working from home
> or in virtual school has an audio and video feed streaming to their
> servers.  Github is owned by Microsoft with some dire consequences.  Lots
> of large companies trying to be everything to everyone, and it turns out
> they're cruel.
> >
> > Anyone?
> >
> > Mike
> >
> > ___
> > 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] TLS ECH, how much can the hint stick out?

[Christopher Patton]

I agree with Christian. The reason to use the ServerHello.random trick is
to make real ECH connections look like connections in which the client
sends a dummy ECH extension to a non-ECH server. In particular, this design
pattern is needed for property (1).

Property (2) is achievable if the ECH configuration is secret, i.e., if the
server is deployed in such a way that it does not reveal it speaks ECH
unless the client offers the right configuration. In particular, the server
need not publish the ECH config, either via DNS or the ECH retry logic.
This won't be feasible for the vast majority of deployments.

As I said above, I think ECH should support use cases for which keeping the
configuration secret is feasible. The trial decryption mechanism might
provide this already, but overall the trial HMAC approach is a much better
design. It would be useful if someone from QUICville could chime in on how
painful it would be to implement. (It doesn't seem that bad for vanilla
TLS.)

Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS ECH, how much can the hint stick out?

[Christopher Patton]

Hi Christian,

No, I don't think the server can detect ECH usage by doing that. The
> client will complete the exchange as if connected to the server. The
> client's response would pretty much the same as if the server's response
> had not been modified, and the MITM will not be able to test whether
> this is ECH or not. If it could, ECH would be seriously broken.
>

I think we should be careful with the word "broken" ... here we're talking
about "don't stick out", which is a deployment consideration only. The main
security goal is confidentiality of the ClientHelloInner.


> But there may be some attack plausible by playing with the ciphersuite,
> or maybe the TLS version extension. I don't think so, but I can't prove
> it either way. One solution would be to incorporate more elements in the
> hash. Another would be to serialize the whole server hello, with a
> proforma random, and add to the hint hash the server hello bytes that
> follow the "random" part.
>

The latter seems to be the lowest cost in terms of implementation
complexity. Nevertheless, I continue to believe that its cost outweighs the
benefit of this mechanism. To summarize my reasons:

   1. The class of active attacks it addresses is quite narrow, and we have
   no reason to believe that it poses a deployment risk to ECH. (It certainly
   doesn't invalidate the main security goal.)
   2. We know of much simpler active attacks for distinguishing real ECH
   from cover ECH, which means the intended threat model isn't fully addressed.
   3. Any future mechanism that rigorously addresses the intended threat
   model will replace what we specify today. It seems like good hygiene to
   keep the thing we'll be replacing as simple as possible.

The current proposal (https://github.com/tlswg/draft-ietf-tls-esni/pull/287)
doesn't stick out much to passive attackers, and it even mitigates
(accidental) replay attacks. This ought to be enough to begin experimenting
with deployment. We won't know what the real-world deployment risks are
until we do.

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS ECH, how much can the hint stick out?

[Christopher Patton]

Hi Mike,

I've since updated the proposal to address the replay attack, but not
Christian's MITM attack:
https://github.com/tlswg/draft-ietf-tls-esni/pull/287

A quick question about Chrisitian's suggestion of using the "key_shares" to
derive the hint. I believe a slightly stronger variant of the MITM attack
beats this mitigation: suppose the server replays not only the original
hint, but also the original "key_shares" shares extension. It won't be able
to decrypt the client's response, but can't the attacker still detect ECH
usage?

Best,
Chris P.


On Thu, Sep 10, 2020 at 11:52 AM Mike Bishop  wrote:

> This is primarily an active attack, but not purely so.  Clearly the MITM
> is an active attacker, but there are situations in QUIC (and DTLS, I
> presume) where a ClientHello gets retransmitted.  Depending on server
> infrastructure, the client might get two different responses.  This isn’t
> limited to cases where the observer/attacker is the one performing the
> replay.
>
>
>
> So I think we need to decide whether it’s a goal that, given that
> relatively narrow situation, the observer shouldn’t be able to identify ECH
> acceptance by comparing two ServerHellos that both respond to the same
> ClientHello.
>
>
>
> *From:* TLS  *On Behalf Of *Christopher Patton
> *Sent:* Tuesday, September 8, 2020 2:23 PM
> *To:* Christian Huitema 
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] TLS ECH, how much can the hint stick out?
>
>
>
> Hi Christian, Hi list,
>
>
>
> The "don't stick out" property is a steganographic security goal: we want
> the "real" protocol, i.e. TLS with ECH acceptance, to be indistinguishable
> from the "cover" protocol, i.e., the handshake pattern in which the client
> sends a "dummy" ECH extension that is ignored or rejected by the server.
> This is a property that TLS was never designed to have, but it seems that
> we need some degree of it in order to deploy ECH. The fundamental question
> that Christian raises is what is the right threat model for this property.
>
>
>
> The "status quo" threat model considers a distinguisher that is strictly
> passive---it does not interfere with a handshake or probe the server---and
> that does not know the ECH configuration. This seems (to me, at least)
> sufficient to account for middleboxes that might ossify on the ECH
> extension. It also seems achievable, both by the ECH as it is and for the
> proposed change.
>
>
>
> The distinguishing attacks described by Christian are much stronger, in
> the sense that they involve an active attacker. I don't believe there is
> any way of implementing ECH---either as it is or with the proposed
> change---that defeats active attacks in general. In particular---and as
> Christian points out---an active attacker can probe the server to learn the
> ECH configuration (via the ECH retry logic), which it can use to easily
> distinguish the real protocol from the cover protocol. This works
> regardless of whether the change is adopted.
>
>
>
> In my view, achieving don't-stick-out-security against active attackers
> requires us to revisit the design of ECH altogether. The main difficulty is
> that client-facing servers publish the ECH configuration in a way that's
> easily accessible to an active attacker. Keeping the configuration secret
> may provide a way to achieve security, and some deployments might opt to do
> this; but the vast majority won't. We might consider adding support for
> this deployment scenario, but this can (and should, I think) wait for a
> later draft.
>
>
>
> That said, it is worth considering mitigations against known attacks, in
> particualr (1). I think the suggestion for mitigating (2) adds too much
> complexity, and if it doesn't fully address the intended threat model (I
> don't think it does), then we'll likely need to replace it in the future. I
> think it's better to keep things simple until we fully address the intended
> threat model.
>
>
>
> Best,
>
> Chris P.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS ECH, how much can the hint stick out?

[Christopher Patton]

>
> If we can establish how difficult it would be to hash the server keyshare
> into the hint in various implementations, I think we'll have our answer.  I
> suspect it is difficult enough to create a problem for someone, but I'm not
> a TLS implementer.
>

One data point: In the standard Go implementation, the ServerHello.random
is computed well before the "key_shares" extension is serialized [1].
Changing this would be somewhat invasive, but perhaps not prohibitively
so.

Best,
Chris P.

[1]
https://github.com/golang/go/blob/master/src/crypto/tls/handshake_server_tls13.go#L83
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS ECH, how much can the hint stick out?

[Christopher Patton]

Hi Christian, Hi list,

The "don't stick out" property is a steganographic security goal: we want
the "real" protocol, i.e. TLS with ECH acceptance, to be indistinguishable
from the "cover" protocol, i.e., the handshake pattern in which the client
sends a "dummy" ECH extension that is ignored or rejected by the server.
This is a property that TLS was never designed to have, but it seems that
we need some degree of it in order to deploy ECH. The fundamental question
that Christian raises is what is the right threat model for this property.

The "status quo" threat model considers a distinguisher that is strictly
passive---it does not interfere with a handshake or probe the server---and
that does not know the ECH configuration. This seems (to me, at least)
sufficient to account for middleboxes that might ossify on the ECH
extension. It also seems achievable, both by the ECH as it is and for the
proposed change.

The distinguishing attacks described by Christian are much stronger, in the
sense that they involve an active attacker. I don't believe there is any
way of implementing ECH---either as it is or with the proposed
change---that defeats active attacks in general. In particular---and as
Christian points out---an active attacker can probe the server to learn the
ECH configuration (via the ECH retry logic), which it can use to easily
distinguish the real protocol from the cover protocol. This works
regardless of whether the change is adopted.

In my view, achieving don't-stick-out-security against active attackers
requires us to revisit the design of ECH altogether. The main difficulty is
that client-facing servers publish the ECH configuration in a way that's
easily accessible to an active attacker. Keeping the configuration secret
may provide a way to achieve security, and some deployments might opt to do
this; but the vast majority won't. We might consider adding support for
this deployment scenario, but this can (and should, I think) wait for a
later draft.

That said, it is worth considering mitigations against known attacks, in
particualr (1). I think the suggestion for mitigating (2) adds too much
complexity, and if it doesn't fully address the intended threat model (I
don't think it does), then we'll likely need to replace it in the future. I
think it's better to keep things simple until we fully address the intended
threat model.

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for draft-rescorla-tls-rfc8446-bis

[Christopher Patton]

I support adoption.

On Wed, Sep 2, 2020 at 6:17 PM Richard Barnes  wrote:

> I agree that this is a worthwhile effort for the WG.
>
> On Wed, Sep 2, 2020 at 16:05 Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Sep 2, 2020 at 12:52 PM David Schinazi 
>> wrote:
>>
>>> I support adoption and am willing to help review.
>>>
>>> In case anyone else finds it helpful, here's a diff from RFC 8446:
>>>
>>> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=rfc8446=draft-rescorla-tls-rfc8446-bis-00
>>>
>>
>> Thanks. I attempted to backport all the substantive changes made in RPC
>> processing. However, there are a number of places (tables, line breaks,
>> etc.) where the formatter behaved differently. In addition, some of the
>> references are different because of differences between
>> kramdown2629/xml2rfc's automatic reference processing and how the RPC does
>> things. If you find changes you believe are material, please send PRs.
>>
>> -Ekr
>>
>> David
>>>
>>> On Wed, Sep 2, 2020 at 10:02 AM Ben Smyth  wrote:
>>>
 I support adoption and I am willing to help work on this. (Eric has
 already incorporated many of my suggestions, many thanks for that.)


 ___


 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites

[Christopher Patton]

I worked out this suggestion into a PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/276

Please have a look!
Chris P.

On Mon, Aug 17, 2020 at 4:28 PM Martin Thomson  wrote:

>
>
> On Tue, Aug 18, 2020, at 09:04, Christopher Patton wrote:
> > Just to be clear, you're proposing something like this? Referring to
> > the KDF API called for in draft-irtf-cfrg-hpke-05:
> >
> > config_digest = Expand(PRK=Extract("some_salt", "some_label",
> > IKM=config), "some_info", 16)
> > It's maybe more hashing than necessary, but I'd be good with this.
>
> Something like that yeah.  And yes, that's a lot of hashing.  But that's a
> lower-order concern.  Maybe if we try to find a KDF that doesn't cost so
> much to operate we won't feel so bad about this.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites

[Christopher Patton]

Just to be clear, you're proposing something like this? Referring to the
KDF API called for in draft-irtf-cfrg-hpke-05:

config_digest = Expand(PRK=Extract("some_salt", "some_label", IKM=config),
"some_info", 16)
It's maybe more hashing than necessary, but I'd be good with this.

Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites

[Christopher Patton]

Hi Martin,


> Or maybe just running the HPKE KDF with a fixed input.

Do you mean something like this? Let `config_digest = KDF.extract("some
salt", "some label", config)`, where `config` is the ECH configuration?

Unless I've missed something critical, you don't need any sort of preimage
> resistance for this, it's only for identification purposes.
>
The manner in which `config_digest` is computed could be significant to
"don't stick out", depending on how you define this property. For example,
one requirement for the hash function might be that it is one-way.

Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] ECH usage indication: alternatives to trial decryption?

[Christopher Patton]

Hi list,

In the current ECH specification (draft-ietf-tls-esni-07), 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 implementation complexity and potentially
raises security concerns. I was hoping to get your thoughts on a couple
alternatives, which strike different balances between implementation
complexity and other design considerations for ECH. Follow along here:

https://github.com/tlswg/draft-ietf-tls-esni/issues/274

Thanks,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Open issues for draft-ietf-tls-esni

[Christopher Patton]

Hi list,

Some of you might have noticed a barrage of issues filed recently against
draft-ietf-tls-esni on GitHub. These are all relatively minor, but
resolving some of them may require changes for the next draft, so I wanted
to summarize them here. These were flagged while Chris Wood and I were
working through some editorial changes.

Links to the issues are given below, including a brief description. We'd
welcome any feedback you might have on these.

Thanks,
Chris P.


https://github.com/tlswg/draft-ietf-tls-esni/issues/261: The spec assumes
that HPKE uses an HKDF cipher suite.

https://github.com/tlswg/draft-ietf-tls-esni/issues/262: Possible bug in
"outer_extensions" extension logic.

https://github.com/tlswg/draft-ietf-tls-esni/issues/263: Role of the hash
in "outer_extensions" is unclear.

https://github.com/tlswg/draft-ietf-tls-esni/issues/265: Question about
"outer_extensions" usage guidance.

https://github.com/tlswg/draft-ietf-tls-esni/issues/266: Security
considerations around SNI leakage.

https://github.com/tlswg/draft-ietf-tls-esni/issues/267: "ech_accept" is
undefined.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 Document Update

[Christopher Patton]

Hi Ekr, this is great! I just wanted to suggest that, instead of obscuring
the word "master", we add a (foot)note to the text explaining its
persistence in the spec and give some historical context.

Best,
Chris P.

On Tue, Aug 11, 2020 at 9:11 AM Eric Rescorla  wrote:

> Hi folks,
>
> I've just posted draft-rescorla-tls-rfc8446-bis-00.
>
> This document does two things:
>
> 1. It rolls up all the various errata that have been filed for
>RFC 8446. Some of these have created some reader confusion
>and so hopefully this will help.
>
> 2. It renames the "master" secrets to "main" secrets in service
>of more inclusive language [0]
>
>
> My intention here is not to make technical changes but just to produce
> a document that's easier to work with.  If there are other pieces of
> text that you think need to be fixed, now would be a good time to flag
> them.  I am working on this document at
> https://github.com/ekr/tls13-spec
>
> Thanks to David Benjamin for suggesting this and talking over the
> mechanics.
>
> -Ekr
>
> [0] Note that I was not totally unable to remove "master" because the
> key schedule labels include it. However, I have removed it from the
> text and I think we should probably change the labels to hex to
> obscure it.
>
>
>
>
> ___
> 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] Fwd: [tlswg/draft-ietf-tls-esni] Fix superfluous padding edge cases. (#258)

[Christopher Patton]

HI all,

Am I alone in being concerned that the efficiency of github
> for some is leading to others with different workflows
> being left out of discussion?
>

This is probably my fault, I apologize. I've been working with Chris Wood
on editorial changes to the draft. These are intended to be purely
presentational-- I figured it was OK to proceed off-list, since we haven't
changed the spec at all. Does anyone object to us proceeding?

Thanks,
Chris Patton
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls