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 intende
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 po
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
wo
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 s
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
> resist
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.
_
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 prop
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
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 re
>
> 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 implem
uldn’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
> *Subj
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 whethe
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 con
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
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/cloudfl
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
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
SS, 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,
> > 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 stud
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://gith
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 la
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 comput
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., an
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
impleme
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 cas
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 in
> 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 sp
> 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 t
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
C
lo 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 defa
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 l
> 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. Th
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 i
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
> (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
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
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/dr
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-tl
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.
>
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
> (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 extens
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
+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
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 whe
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-t
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 ClientHelloOute
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
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 inadver
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'
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 alloc
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_reque
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
>> handshak
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
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
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
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 M
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&url2=draft-ietf-tls-esni-18&difftype=--html
Chris P.
On Mon, Mar 11, 2024 at 3:12 PM Rob Sayre wrote:
> On Mon, Mar 1
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
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 summa
This looks good to me, modulo Rich's points and one more minor thing.
"Use of ECH yields an anonymity set of cardinality equal to the number of
ECH-enabled server domains supported by a given client-facing server" (
https://www.ietf.org/id/draft-ietf-tls-svcb-ech-02.html#section-5.1-2).
This is on
I support adoption.
Chris P.
On Thu, Jul 25, 2024 at 9:17 AM Sean Turner wrote:
> At the IETF 120 TLS session there was interest in adopting the SSLKEYLOG
> Extension file for ECH I-D (
> https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/).
> This message starts a two-weekl cal
HI Devi,
This decision was made in large part due to the (arguably too conservative)
analysis in this paper: https://eprint.iacr.org/2018/634
Here is the issue where it was discussed:
https://github.com/tlswg/tls13-spec/issues/1145
I don't know why the AD was empty ... I'd also be very interested
Changes to Section 5.1 look good to me!
On Tue, Aug 20, 2024 at 10:00 AM Salz, Rich wrote:
>
> I read the document [1]. I think it's ready for WGLC. I suggest one
> change. I find the use of "bootstrapping" in the title misleading. I
> suggest "Enabling TLS Encrypted ClientHello via DNS Servic
I vote for Option 1: Let's see if/how this changes existing proofs before
we move to standards track. From a quick look, it doesn't seem like
implementing this extension should cause anyone trouble, but we might as
well be sure.
Chris P.
On Mon, Aug 26, 2024 at 3:46 PM Stephen Farrell
wrote:
> So is it possible to transfer the accept_confirmation in some plain text
> extensions
> like Key Share, or other dedicated extension?
>
Just a historical note here: the acceptance signal was designed this way so
that the client has an explicit signal of whether the server used the inner
ClientHe
Looks good to me. Consider removing the Acknowledgements section, as it's
not really used.
Chris P.
On Wed, Dec 4, 2024 at 2:48 AM Bas Westerbaan wrote:
> Nit: second paragraph of section 3 starts with "While the industry is
> waiting for NIST to finish standardization". That's not true anymore
I support adoption of [1].
Making trust anchor negotiation an in-band mechanism is a pretty big shift
for TLS. I think it's a good sign that we've taken so much time to get to
an adoption call: it means we're treating the shift with the seriousness it
deserves.
I think we should work on the probl
I support adoption.
Chris P.
On Wed, Feb 26, 2025 at 10:31 AM Sean Turner wrote:
> At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key
> Agreement for TLSv1.3”; see [0] and [1]. We also had some discussion in an
> information gathering thread; see [2]. We would like to now determi
You might be interested in the draft being discussed here (I believe this
is on the agenda for next week as well):
https://mailarchive.ietf.org/arch/msg/tls/dT5e5F1yWtFbs0dpESsWO-Cg0AM/
There's also this draft, which could be used to probe servers for ECH
support: https://datatracker.ietf.org/doc/
Hi Nick,
I'd go for option 1. The server is opting into this mechanism, so it seems
reasonable to force it to ignore the outer SNI if ECH accepts. I agree with
Stephen that we shouldn't hold up publication for this change (Option 2),
however I think the extension mechanism of ECH is appropriate fo
I've read the draft and support doing this. However, I wanted to +1
Martin's suggestion of restricting this to 2-move PAKEs (1 round trip) if
possible, and if so, defining a new key_share rather than a new extension
that disables key_share. It seems like this would be a much simpler design.
Chris
Hi EKR,
> I agree we shouldn't *disable* key_share, but it seems like the right
> answer here is to instead combine the PAKE output with the existing key
> establishment.
>
I probably just missed this in the discussion, but what would be the
advantage of combining PAKE with the existing key exch
Hi all, unfortunately I wasn't able to attend the meeting this week, but I
had a chance to catch up on youtube (
https://www.youtube.com/watch?v=bQ-Bz60AppI). I wanted to add one more
point to the ECH discussion that might be helpful for moving this topic
forward.
There were three presentations ab
73 matches
Mail list logo
