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

I read it and support adoption. I hope, as the WG are processing this, we consider what, if anything, else could be usefully added to HTTPS RRs to make life easier. Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital

Re: [TLS] Opsdir early review of draft-ietf-tls-wkech-04

Thanks Tim, I'll take your review as confirming the others then and will work on addressing those issues next week or two. Cheers, S. On 30/04/2024 17:07, Tim Chown via Datatracker wrote: Reviewer: Tim Chown Review result: Not Ready Hi, I have reviewed this document as an early Operations

Re: [TLS] WG Adoption for TLS Trust Expressions

presented at IETF 118 in November, several participants (including myself, Stephen Farrell and Nicola Tuveri) came to the mic to highlight that this draft's mechanism comes with a serious potential for abuse by governments (meeting minutes <https://notes.ietf.org/notes-ietf-118-tls#TLS-Trus

Re: [TLS] Dnsdir early review of draft-ietf-tls-wkech-04

Hi David, Thanks for taking the time to review this. On 15/04/2024 23:44, David Blacka via Datatracker wrote: Reviewer: David Blacka Review result: Ready with Issues This is an early review, so the actual status simply means that I didn't find anything alarming in this draft. Ta. The

Re: [TLS] I-D on TLS authentication with VC

Hiya, On 05/04/2024 12:54, Achim Kraus wrote: Hi, On that basis, I'd consider this a bad idea that ought not be pursued, and certainly not by the TLS WG. for me this sounds more like an argument for a "recommended (for general use-cases) n". I'd go further - ISTM an argument for a

Re: [TLS] I-D on TLS authentication with VC

Hiya, On 04/04/2024 09:53, Andrea Vesco wrote: I-D: https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/ From figure 2 it looks as if use of this mechanism would have bad privacy properties as the DLT would end up knowing which clients accessed which servers at what times. That's v.

Re: [TLS] Working Group Last Call for SSLKEYLOG File

Hiya, This is basically for the record and not an objection to proceeding. On 02/04/2024 17:34, Sean Turner wrote: This WGLC has concluded. There is consensus to move this document forward. The material change was to add a security consideration about forward secrecy guarantees being

Re: [TLS] Working Group Last Call for ECH

Hiya, On 02/04/2024 15:17, Russ Housley wrote: Joe: The ECH Internet-Draft includes this reference: [ECH-Analysis] "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello", November 2022. I'm guessing that'd be:

Re: [TLS] Artart early review of draft-ietf-tls-wkech-04

Hi Martin, Thanks for the review. (More such are v. welcome esp as ECH is now past WGLC.) On 02/04/2024 00:40, Martin Thomson via Datatracker wrote: Reviewer: Martin Thomson Review result: Not Ready This document describes how an HTTP origin can publish information about its ECH

Re: [TLS] should we say anything about ECH in the face of fragmentation?

Hiya, On 15/03/2024 21:55, Watson Ladd wrote: On Fri, Mar 15, 2024 at 2:23 PM Stephen Farrell wrote: Hiya, I think the outcome here is maybe most likely to do nothing but since the WGLC is ongoing I figured it best to bring it up in case others have better ideas. I got a mail yesterday

[TLS] should we say anything about ECH in the face of fragmentation?

Hiya, I think the outcome here is maybe most likely to do nothing but since the WGLC is ongoing I figured it best to bring it up in case others have better ideas. I got a mail yesterday from someone who had played with the nginx "stream module" setup ECH-split-mode PoC stuff we've done and

Re: [TLS] Working Group Last Call for SSLKEYLOG File

use. Best, Dennis On 12/03/2024 23:07, Eric Rescorla wrote: On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell wrote: I'll argue just a little more then shut up... On 12/03/2024 22:55, Martin Thomson wrote: Sorry also for a late suggestion, but how'd we feel about adding some text like t

Re: [TLS] ML-KEM key agreement for TLS 1.3

Hiya, On 14/03/2024 01:41, Deirdre Connolly wrote: Oh and one more consideration: hybrid brings complexity, and presenting the pure-PQ solutions and their strictly lesser complexity (at the tradeoff of maybe taking more risk against newer schemes no matter how good we feel about their

Re: [TLS] Working Group Last Call for SSLKEYLOG File

I'll argue just a little more then shut up... On 12/03/2024 22:55, Martin Thomson wrote: Sorry also for a late suggestion, but how'd we feel about adding some text like this to 1.1? "An implementation, esp. a server, emitting a log file such as this in a production environment where the

Re: [TLS] Working Group Last Call for SSLKEYLOG File

On 12/03/2024 22:06, Eric Rescorla wrote: I don't think we should make statements about regulatory requirements in this kind of specification. That's not our lane. I'd weakly disagree about making statements such as suggested, while agreeing with "not out lane." I don't think the text I

Re: [TLS] Working Group Last Call for SSLKEYLOG File

Hiya, On 12/03/2024 14:57, Sean Turner wrote: This is the working group last call for the SSLKEYLOGFILE Format for TLS Internet-Draft [1]. Please indicate if you think the I-D is ready to progress to the IESG and send any comments to the list by 31 March 2024. This is not my fav thing, but I

Re: [TLS] Working Group Last Call for ECH

d the time to do that. Cheers, S. thanks, Rob On Mon, Mar 11, 2024 at 6:12 PM Stephen Farrell wrote: On 12/03/2024 00:49, Rob Sayre wrote: On Mon, Mar 11, 2024 at 5:21 PM Christopher Patton < cpat...@cloudflare.com> wrote: I don't believe there were any changes from draft 13

Re: [TLS] Working Group Last Call for ECH

On 12/03/2024 00:49, Rob Sayre wrote: On Mon, Mar 11, 2024 at 5:21 PM Christopher Patton wrote: I don't believe there were any changes from draft 13 to 18 that would invalidate security analysis for draft 13:

Re: [TLS] Working Group Last Call for ECH

Hiya, On 11/03/2024 22:08, Rob Sayre wrote: I think it is ready and can live with the current draft. Same here. The protocol's well baked. The text good enough. I've written code to implement it, done the interop with others, deployed test services and done PoC integrations of my openssl ECH

Re: [TLS] Status of draft-ietf-tls-esni

On 17/02/2024 18:56, Eric Rescorla wrote: I should be able to spin a WGLC-ready version of ECH before the draft deadline. Good stuff, thanks. I'll plan to review the proposed changes with a strong bias for not asking for more:-) Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description:

Re: [TLS] Input on ECH specification

Hiya, Would have to read the other bits but this jumped out... On 07/02/2024 22:06, Elardus Erasmus wrote: Make it clear that if an ECH extension is absent from the server_hello, it qualifies as an ECH disabling signal. When ECH is in real use, most SH messages won't contain an ECH extension

Re: [TLS] Late holiday gifts

On 18/01/2024 17:46, Salz, Rich wrote: Per last IETF meeting [1] I thought ECH was going to go to WGLC. Were we waiting for a new draft? Something else? Looking a bit like we're an errata-only mailing list last while:-) Processing those is of course worthy (probably) but so is finishing

Re: [TLS] ECH: Changes to IANA consideration section

Hiya, On 19/12/2023 16:42, Stephen Farrell wrote: On 19/12/2023 16:34, Sean Turner wrote: FYI the assignments have been made. Great. Can I ask what's the plan for WGLC? Be great if that could be started before the holidays:-) Good that the IANA registrations are done. Can I ask when

Re: [TLS] 0RTT freshness test does not work well when delays are in minutes

Hiya, Interesting question... On 11/01/2024 00:07, Christian Huitema wrote: I am wondering what the proper fix should be. I don't know the answer (or if there's one answer) but suspect that it may be better to first explore various scenarios (as you've kinda kicked off with forwarding to

Re: [TLS] ECH: Changes to IANA consideration section

g/rfc8447bis/pull/49 On Nov 29, 2023, at 16:09, Stephen Farrell wrote: Hiya, On 27/11/2023 14:35, Sean Turner wrote: Bumping this up in case anybody missed it. 'case it helps, I'm fine with the original mail you sent and any of "n/a" or "CH" being used rather than &quo

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Hiya, On 13/12/2023 13:18, Bas Westerbaan wrote: Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's deployable, and whether its performance is acceptable, is something we should figure out.) I guess we're just interpreting "as-is" differently. What I meant by "as-is" was

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

future PQ version of ECH can't be done yet, and figuring out how a PQ-version of ECH would work and not involve too-large a CH is another day's work. Cheers, S. Russ On Dec 6, 2023, at 4:21 PM, Stephen Farrell wrote: Hiya, On 06/12/2023 21:06, Russ Housley wrote: Stephen: Maybe. ECH

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

, Stephen Farrell wrote: Hiya, (3) The privacy considerations already talk about Appendix E.6 of [RFC8446]. I am please to add a pointer to ECH, but I do not think that ECH use should not be mandated. While I'm a fan of ECH, does it actually do the trick here? If the adversary has a CRQC then we'd

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Hiya, (3) The privacy considerations already talk about Appendix E.6 of [RFC8446]. I am please to add a pointer to ECH, but I do not think that ECH use should not be mandated. While I'm a fan of ECH, does it actually do the trick here? If the adversary has a CRQC then we'd need an updated

Re: [TLS] ECH: Changes to IANA consideration section

, S. spt [0] PRs: https://github.com/tlswg/rfc8447bis/pull/48 https://github.com/tlswg/rfc8447bis/pull/49 On Nov 29, 2023, at 16:09, Stephen Farrell wrote: Hiya, On 27/11/2023 14:35, Sean Turner wrote: Bumping this up in case anybody missed it. 'case it helps, I'm fine with the original m

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

On 06/12/2023 05:33, 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

Re: [TLS] ECH: Changes to IANA consideration section

Hiya, On 27/11/2023 14:35, Sean Turner wrote: Bumping this up in case anybody missed it. 'case it helps, I'm fine with the original mail you sent and any of "n/a" or "CH" being used rather than "-". If it helps, I've a very minuscule hint of a preference for "CH" so you can count me as

Re: [TLS] ECH: What changed?

Hiya, On 15/11/2023 02:09, Raghu Saxena wrote: Interesting how the browsers have already rolled it out, but no major website (afaik) has. Even Cloudflare had to rollback their beta due to some issues[0]. Are there any websites (not test ones like defo.ie) that actually support ECH? defo.ie

Re: [TLS] SVCB codepoint for ECH

On 21/09/2023 16:01, Salz, Rich wrote: https://github.com/tlswg/draft-ietf-tls-esni/pull/553 Looks good to me.

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

Hiya, On 19/09/2023 01:45, Sean Turner wrote: Hi! After discussions with the authors of draft-ietf-tls-esni, Joe and I would like to determine whether there is consensus to request two early code point assignments; see RFC 7120. One is for the encrypted_client_hello extension and one is for

Re: [TLS] ECH-HRR Design Team output

Hiya, Wasn't sure which email to reply to, but this one'll do... Until very recently I was of the opinion that ECH split-mode when one hits HRR with our current design was significantly problematic. The main reason was that supporting that scenario with haproxy seemed like it'd require

Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge

Hiya, I saw the presentation and scanned the draft and support adoption on the basis that this could be useful before any certificates using PQC algorithms are in play so the target of an experimental RFC is fine, even moreso as I could imagine details/codepoints changing over time as new

Re: [TLS] tls@ietf117

Will probably turn up anyway in the draft status section but last time a couple of people said they hoped to be able to report on ECH experimentation in roughly this timeframe, so be great if someone could pull together a short slot with that info (if it's ready). Cheers, S. On 17/07/2023

Re: [TLS] NIST Draft comments period: Addressing Visibility Challenges with TLS 1.3

ch hybrid stuff to standardise for TLS in the not too distant future. Where the above text is more or less copy pasted from the LSs to ETSI. Cheers, John On 2023-05-17, 20:43, "Stephen Farrell" wrote: Hiya, On 17/05/2023 18:49, John Mattsson wrote: Hi, Should IETF / SEC / TLS sen

Re: [TLS] NIST Draft comments period: Addressing Visibility Challenges with TLS 1.3

Hiya, On 17/05/2023 18:49, John Mattsson wrote: Hi, Should IETF / SEC / TLS send an LS to NIST as was done with ESTI-TC-CYBER? Yes. Other relevant bodies defining ways to weaken the hard-won security of IETF protocols really ought always be (nicely) told they're doing a bad thing. I sent

Re: [TLS] FW: New Version Notification for draft-rsalz-tls-tls12-frozen-00.txt

Hiya, On 17/05/2023 15:11, Salz, Rich wrote: This is the "TLS 1.2 is frozen" draft promised in Yokohama. I am pleased to have Nimrod as co-author. We think this is ready for adoption :) I'd be supportive of adoption. I think the draft could do with a clearer statement to the effect that

Re: [TLS] I-D Action: draft-ietf-tls-wkech-02.txt

Security (TLS) WG of the IETF. Title : A well-known URI for publishing ECHConfigList values. Authors : Stephen Farrell Rich Salz Benjamin Schwartz Filename: draft-ietf-tls-wkech-02.txt Pages : 8 Date

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

Hiya, On 05/04/2023 02:47, Sean Turner wrote: A post IETF 116 bump to make sure folks get their reviews in. If you look at the diffs from RFC 8446 you can see not that much has changed. We will also take “I read it and it looks good” response. I looked at the diff between 8446bis-07 and 8446

Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech

On 28/03/2023 05:57, Salz, Rich wrote: At TLS@IETF116, the sense of the room was that there was WG support to adopt draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus in the room. Please indicate whether you do or do not support adoption of this I-D by 2359UTC on 18 April

Re: [TLS] Merkle Tree Certificates

Hiya, I had a read and think this is a great topic for discussion. A few points: - I think we'd benefit from trying to think through the dynamics of this, e.g. how many of each entity might we see and how'd that differ from the current web PKI and possibly affect the web? (It's fine that that

Re: [TLS] New Version Notification for draft-ietf-tls-esni-15.txt

Hiya, On 07/01/2023 15:46, John Mattsson wrote: My current understanding is that draft-ietf-tls-esni should require that the server MUST NOT reuse a key shares. Unless I miss something I suggest adding that and one or two of the above figures to the draft. An alternative solution would be to

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

I'm ok with adoption so long as we include sufficient caveats along the way (and then add more caveats just in case:-) If there were some technical means to ensure that this was less likely to be abused, I'd like it more. (Could we e.g. require inclusion of a TLS extension that has a 100kB

Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

Hiya, This is a "just wondering" type email... On 26/10/2022 23:32, Martin Thomson wrote: harder part: getting people interested in deploying a fix. If ECH+PQ-hybrid turns out to be problematic (size-wise) and PQ-hybrid by itself increases occurrences of HRR, and if ECH is generally

Re: [TLS] Published RFC 8446bis -05

Hiya, On 25/10/2022 03:27, Eric Rescorla wrote: On Mon, Oct 24, 2022 at 7:17 PM Rob Sayre wrote: Is removing HRR on the table? No, I don't think so. It performs an important function. Is there any public info as to how often HRR happens? (Sorry if that's well known, but it's not well

Re: [TLS] Securely disabling ECH

Hiya, On 21/10/2022 00:44, Rob Sayre wrote: I think the WG might want to consider how it spends its time. The ECH draft has been adopted as a work item. In case it’s not obvious, this one is going to be deployed prior to its document status. The above seems correct and apposite. There’s

Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs

On 18/10/2022 16:36, Ben Schwartz wrote: On the topic of smaller hosts: not every IETF specification is equally useful to everyone, and this is fine. ECH provides more benefit when applied to large hosts, but it doesn't_reduce_ privacy for anyone, so it is safe to deploy on essentially any

Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs

I agree with what Ben said, but in particular this: On 13/10/2022 15:35, Ben Schwartz wrote: I do think we have a lot to learn about the operational challenges of deploying ECH, but our discussion about that should be driven by technical reports from deployments, not speculation about

Re: [TLS] ECH not protect SNI

Hiya, On 24/08/2022 16:36, 涛叔 wrote: I can't agree with you. FWIW, I agree with ekr. I don't think the scheme you outlined works, nor would it be a good basis for changes to ECH. (Sorry;-) As I said before, there may be some guidance we can offer web server deployers in such cases but I

Re: [TLS] ECH not protect SNI

Hiya, On 24/08/2022 09:34, 涛叔 wrote: I am not saying ECH isn't going to work at all. Even most sites need to be deployed behind cloud services, it not means we could design a standard to make it as a requirement. So let me try see if I understand by trying to re-phrase your concern: the

Re: [TLS] ECH not protect SNI

Hiya, On 24/08/2022 02:26, 涛叔 wrote: Hi, Stephen, I actually has some trouble to understand your point. Yes, perhaps we're not understanding one another and it might help if you could describe what you think is the win here? What would you like to see? On Aug 24, 2022, at 08:58, Stephen

Re: [TLS] ECH not protect SNI

Hiya, On 24/08/2022 01:11, 涛叔 wrote: What if there is no small hoster? If a person just buy a VPS to deploy a HTTPS server, what should he do to deploy ECH? Factually, many people do deploy a web server hosted as a VPS by a small hoster, so could benefit from ECH, to some extent. I know in

Re: [TLS] ECH not protect SNI

Hiya, On 24/08/2022 00:39, 涛叔 wrote: It may be right for a common cloud platform, but what about indie server? Every site who need ECH have to deploy an addition outer domain to*protect* the inner one. But these indie servers can not share a common outer domain, so the have to use some

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

On 19/08/2022 15:05, Salz, Rich wrote: If it's a framework, and the framework seems to work for known algorithms, then let's just publish the framework and add specifics later. I didn't conclude that the framework works so I'd be against publishing now. (I do still need to respond to the

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

Hiya, On 07/08/2022 21:58, Scott Fluhrer (sfluhrer) wrote: Hence, what we are proposing is no less secure than what we are currently doing now. Well, except there'll be a whole pile of new code, which is a fine way to be less secure. Now for key establishment that's not too bad perhaps,

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

On 06/08/2022 17:47, Phillip Hallam-Baker wrote: Are you proposing pure Kyber or a hybrid though? I've not heard anyone suggest securing an IETF protocol only via PQC algs. It'd be incredibly dim to make that suggestion IMO, esp now that two of the 3rd round entries have been busted. So I'm

Re: [TLS] PQC key exchange sizes

On 26/07/2022 13:15, Thom Wiggers wrote: Hi all, In yesterday’s working group meeting we had a bit of a discussion of the impact of the sizes of post-quantum key exchange on TLS and related protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide deck (unlike the signature

Re: [TLS] Call for adoption of draft-farrell-tls-wkesni

Hi Ben, On 08/06/2022 20:35, Ben Schwartz wrote: I am supportive of this effort, but I am not convinced that the proposed mechanism is right. That's fair. FWIW, I do agree the issues you identify below warrant discussion (my preference of course is to do that after WG adoption:-) In ECH,

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

Hiya, Just on this one point: On 02/05/2022 10:58, Ilari Liusvaara wrote: Furthermore the extension involved (key_share) REALLY SHOULD NOT differ between inner and outer hello. I kinda agree, but the ECH spec allows 'em to differ. In any case, the main point here is that this compression

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

Hiya, On 30/04/2022 10:05, Ilari Liusvaara wrote: On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote: Hiya, On 27/04/2022 16:27, Christopher Wood wrote: This email commences a two week WGLC for draft-ietf-tls-hybrid-design, located here: https://datatracker.ietf.org/doc

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

Hiya, On 27/04/2022 16:27, Christopher Wood wrote: This email commences a two week WGLC for draft-ietf-tls-hybrid-design, located here: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ As I guess I've said before, I think progressing this draft now, even with this

Re: [TLS] draft-farrell-tls-pemesni-02 status

Hiya, On 17/03/2022 20:57, Joseph Salowey wrote: While we are all supportive of ECH, we are not sure that the PEM file format for ECH I-D (draft-farrell-tls-pemesni-02) is within scope of the TLS WG. Hmm. Gotta say I don't agree as a commonly supported format like this (should this garner

[TLS] .well-known URL for ECH

Hiya, As discussed at IETF-112, I've done the ESNI -> ECH substitutions for this draft. [1] I've implemented this for some of my test servers so it "works" for a micro-scale setup like mine, but of course if something like this is useful for others, I'd be happy to change it to suit. Happy to

[TLS] ECH: fuzzy DNS data

Hiya, Recently I've been doing a bit of testing of the effects of retrieving dodgy or possibly unexpected ECH-related data from DNS. I've setup a repo with a few of those and am publishing 'em in DNS (one randomly selected every 30 minutes). That's explained at [1]. It might be useful for

[TLS] updated PEM file format draft for ECH key pairs

Hiya, As discussed at IETF112, I've updated the PEM file format draft for ECH. [1] Happy to take comments via mail or via that github thing:-) As and when the chairs think it's a good time to consider adoption, or incorporation into the ECH draft, or sending this somewhere else, I guess we can

Re: [TLS] ECH - handling retry config with different public name?

outer1 is likely not a great outcome. On Sat, Nov 6, 2021, at 02:20, David Benjamin wrote: That's my inclination as well. It's an odd thing for a server to do, but it seems fine to just retry with the new config without much fuss? On Fri, Nov 5, 2021 at 10:18 AM Stephen Farrell wrote: Hiya, Bit

[TLS] ECH - handling retry config with different public name?

Hiya, Bit of a corner case I'm not sure about. Apologies if this has come up before. The scenario: - inner SNI is inner.example - ECHConfig from inner.example's DNS has outer.example as public_name - client authenticates with ClientHelloOuter and the ServerHello contains retry_configs

Re: [TLS] NIST on addressing visibility challenges with TLS 1.3

(I've no problem if the chairs want to shut this down as we have gone over this ground a number of times - OTOH it is I think important to not let such things pass by as if they were fine, since they are not fine.) Ruslan is correct wrt the EU stuff IMO. Other than that, I don't consider it

Re: [TLS] NIST on addressing visibility challenges with TLS 1.3

Hiya, On 28/09/2021 17:53, Salz, Rich wrote: This will be of interest to some on this list. Quoting: “The NCCoE at NIST recognizes the challenges associated with compliance, operations, and security when enterprises employ encrypted protocols, in particular Transport Layer Security (TLS) 1.3,

[TLS] ECH draft-13 servers for interop testing

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:

Re: [TLS] ECH AAD for HRR

Earlier, I said: On 01/09/2021 18:00, Stephen Farrell wrote: I should have a server up in a few days I now have an ``openssl s_server`` that thinks it speaks draft-13 running on draft-13.esni.defo.ie on port 8413 with the relevant ECHConfig published in DNS etc. It'll probably crash

Re: [TLS] ECH AAD for HRR

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 wa

[TLS] ECH AAD for HRR

(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

Re: [TLS] GREASE ECH repeated value after HRR

enforces this. https://github.com/tlswg/draft-ietf-tls-esni/issues/358 David On Tue, Aug 17, 2021 at 4:03 PM Stephen Farrell wrote: Hiya, (I'm just getting around to playing with draft-13 ECH and HRR and have a question...) In 6.2 talking about GREASEd ECH, the draft says: If sending

[TLS] GREASE ECH repeated value after HRR

Hiya, (I'm just getting around to playing with draft-13 ECH and HRR and have a question...) In 6.2 talking about GREASEd ECH, the draft says: If sending a second ClientHello in response to a HelloRetryRequest, the client copies the entire "encrypted_client_hello" extension from the

Re: [TLS] esni-draft-13 suggestion

Hiya, On 09/08/2021 19:07, Christopher Wood wrote: On Thu, Aug 5, 2021, at 10:30 AM, Salz, Rich wrote: As you are an experienced reviewer, I really appreciate all your commentary, and I think an experienced, not-author, view is very useful! +1 -- thanks, Stephen! Most of the PRs have been

Re: [TLS] esni-draft-13 suggestion

/draft-ietf-tls-esni/pulls On 03/08/2021 21:58, Christopher Wood wrote: On Tue, Aug 3, 2021, at 1:51 PM, Stephen Farrell wrote: On 03/08/2021 21:44, Christopher Wood wrote: Of course! We're happy to park the next version until the end of the week (or longer), if that would yield more reviews

Re: [TLS] esni-draft-13 suggestion

On 03/08/2021 21:44, Christopher Wood wrote: Of course! We're happy to park the next version until the end of the week (or longer), if that would yield more reviews. Please send any editorial comments you have here on the list or as PRs against the draft, and we'll work to try and incorporate

[TLS] esni-draft-13 suggestion

Hiya, I see a bunch of activity in github that may be the precursor to pushing out draft-13, which would be great. One (ignorable) suggestion - as we're aiming for this draft to be the basis for ongoing experiments, just before pushing the publish button, it might be no harm to give people a

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

Hiya, On 19/07/2021 22:43, David Benjamin wrote: No. I'm saying there is a need for text around resumption and privacy, whether or not we publish this draft. There is a copy of the text to address it in both documents. The text applies equally well to both, thus I am satisfied with how this

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

Hiya, On 19/07/2021 22:13, David Benjamin wrote: I don't think that's an accurate characterization of what's going on. I at least care about both optimization and privacy. Sure. We just disagree, I've no doubt you care about those. We should apply optimizations only where they do not

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

Hiya, On 19/07/2021 17:50, David Benjamin wrote: Do you have other text in mind? There doesn't seem to be any other possible answer here, since there is only one decision to make in resumption. There is a 3rd option: don't standardise the flag. That'd be my preference, but as I said maybe

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

Hiya, On 19/07/2021 17:35, David Benjamin wrote: We need to*both* not add new tracking vectors*and* mitigate the existing ones. Doing either one on its own is not useful. That means if the existing mitigation for the existing vector applies just as well to this new feature, we have not added

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

Hiya, On 19/07/2021 17:17, David Benjamin wrote: I'll add that, in the context of cross-domain tracking on the web, this draft is a red herring. Remember that web pages have subresources. That means looking at the destination domain isn't useful because two different pages can embed a common

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

Hiya, On 19/07/2021 16:21, Ryan Sleevi wrote: On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell wrote: I don't find the reference to [FETCH] explains how that problem can be mitigated by browsers. (IIRC, adding that was the result of earlier discussion of this point?) I'm not sure I'm

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

On 19/07/2021 15:16, Salz, Rich wrote: I support publication. I don't, though I may be in the rough. We did discuss this a bit earlier but from my POV this adds a new vector for cross-domain tracking and we ought be removing those, not adding them. I don't find the reference to [FETCH]

Re: [TLS] ECH and resumption - what to put in SNI?

So I guess we're landing on "if the client got a ticket via a session that successfully used ECH, it MUST send a fresh ECH when using that ticket"? That's ok I guess, but maybe some more detail is needed... On 25/06/2021 17:01, David Benjamin wrote: 1. Either this layer knows how to set up

[TLS] ECH and resumption - what to put in SNI?

Hiya, If a client established a session to foo.example.com using ECH with a public_name of example.com, what ought the client put in the SNI when resuming? Ignoring ECH, 8446 seems to imply one ought put in foo.example.com [1] but that'd defeat the purpose of ECH. If one omits SNI, that would

Re: [TLS] Editorial: chronological order in ECH draft

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

Re: [TLS] ECH Padding

On 22/06/2021 22:57, Christopher Patton wrote: 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. Apologies. (Though I put part of the blame on excessive githubbery

Re: [TLS] ECH Padding

(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

Re: [TLS] Use-case for non-AEAD ciphers in network monitoring

Hiya, On 17/05/2021 21:33, Darin Pettis wrote: TLS 1.3 did a great job regarding safety of data on the Internet. For the next version, let’s focus on how to best meet this used case I think we had this discussion a few years ago. There is no sensible boundary at which TLS can apply different

Re: [TLS] [Uta] Recommending ALPN (was Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11 ...)

Hiya, I like the text below as a starter. I'd suggest it also include something to take into account the ECH issue mentioned on the dpriv list [1] S [1] https://mailarchive.ietf.org/arch/msg/dns-privacy/3xL59_1P0ZHOUEYsDJ1Q22ZZVvo/ On 30/04/2021 07:46, Martin Thomson wrote: On Fri, Apr

Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

On 29/04/2021 19:28, Salz, Rich wrote: To make it obvious (I thought it was): I agree, and think we need to make that fact more widely known. I think I agree but seems like ECH may add a subtlety - maybe what we need to promote is the idea that new protocols should define new ALPN strings,

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

Hiya, To answer Chris' initial question: I can't currently think of a real use-case where the client would need to authenticate an IP address for a client-facing server in the event that ECH decryption has been tried and failed. And, I very much sympathise with Martin's goal of simplifying if

Re: [TLS] ECH-10 interop test server

Hiya, On 05/04/2021 18:07, Stephen Farrell wrote: Hiya, On 05/04/2021 18:01, Christopher Patton 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

  1   2   3   4   5   >