Re: [TLS] ban more old crap

On 23/07/15 16:43, Dave Garrett wrote: > We should just get more serious about banning old crap entirely to > make dangerous misconfiguration impossible for TLS 1.3+ > implementations. > > Right now, the restrictions section prohibits: RC4, SSL2/3, & > EXPORT/NULL entirely (via min bits) and has

Re: [TLS] ban more old crap

(no hats and al that) On 25/07/15 06:46, Viktor Dukhovni wrote: > I hope, that by ~2017, RC4 will no longer be required either, and > we'll be able to disable RC4 in Postfix at that time. Seems to me that should be a reasonable match for expecting to see TLS1.3 getting deployed in lots of parts

Re: [TLS] padding

On 25/08/15 00:22, Tom Ritter wrote: > it would be _amazing_ if browser vendors enabled > browser extension authors to choose the padding strategy for > individual origins. Then we can crowdsource the effort. Excellent idea! S. ___ TLS mailing list

Re: [TLS] RC4 cipher with NNTP (RFC 4642)

Hiya, On 04/09/15 01:58, Sean Turner wrote: > Also, I wouldn’t get too wrapped around the updates header because > the meaning has changed over time. At some points it has been used > to point implementers at other related RFCs, but what I think the > IESG has settled onto now (Stephen correct m

Re: [TLS] RC4 cipher with NNTP (RFC 4642)

15 12:57, Stephen Farrell wrote: > > Hiya, > > On 04/09/15 01:58, Sean Turner wrote: >> Also, I wouldn’t get too wrapped around the updates header because >> the meaning has changed over time. At some points it has been used >> to point implementers at other related

Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)

On 16/09/15 09:19, Peter Gutmann wrote: > Jeffrey Walton writes: > >> Somewhat off-topic, why does TLS not produce a few profiles. One can be >> "Opportunistic TLS Profile" with a compatible security posture and include >> ADH. Another can be a "Standard TLS Profile" and include things like exp

Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)

On 16/09/15 12:18, Peter Gutmann wrote: > Stephen Farrell writes: > >> We have BCP195 [1] that aims for the "general" case (for up to TLS1.2) and a >> draft [2] (current in IESG evaluation) for the embedded case. Are those the >> kind of thing you're aft

Re: [TLS] TLS 1.3 - Support for compression to be removed

On 22/09/15 17:23, Tony Arcieri wrote: > But an unsafe feature shouldn't be kept in > TLS just because some protocols want to do unsafe things and are too lazy > to implement their own compression. Compression does have issues clearly, but it's not correct to describe people wanting TLS to compr

Re: [TLS] TLS 1.3 - Support for compression to be removed

On 22/09/15 19:32, Yoav Nir wrote: > >> On Sep 22, 2015, at 8:35 PM, Stephen Farrell >> wrote: >> >> >> >> On 22/09/15 17:23, Tony Arcieri wrote: >>> But an unsafe feature shouldn't be kept in >>> TLS just because some protocols wa

[TLS] TRON workshop

Hiya, First, thanks all for all your ongoing work on TLS1.3. I'm sure we're all aware that this is important stuff that needs to be, and is being, done carefully with due attention to security analysis. Early in the process we had some brief discussion of pausing towards the end of the work to g

Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK

On 31/10/15 13:55, Eric Rescorla wrote: > > Thanks again for your contribution here. It's really important to have > this kind of analysis, especially at this stage before the design is > completely > hardened. +many, Thanks, S. ___ TLS mailing list

[TLS] TRON submission in 2 weeks...

Just a reminder that the TRON workshop [1] initial submission date is December 1st. Please get your good submissions in! (Or hassle folks you know who should be submitting:-) Thanks, S. [1] https://www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-call-papers ___

[TLS] AD review of /draft-ietf-tls-cached-info-20

Hiya, I've requested IETF LC for this one. (Sorry for being slow getting to it.) Please treat my comments below along with any other last call comments. - You probably thought about this but I forget the argument. Wouldn't it have been better to include the cached info that is not sent within th

Re: [TLS] Early code point assignments for 25519/448 curves

Hiya, On 23/11/15 14:21, Sean Turner wrote: > All, > > We’ve received an early code point assignment for the following 4 Is the word "request" missing above? Either that or I'm forgetting more than I suspected:-) > (four) elliptic curve points that will go in the "Supported Groups" > Registry:

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 02/12/15 15:38, Jacob Appelbaum wrote: >> > It’s quite >> > useful in hotspot/public wifi environments where making policy decisions >> > based on hostname is more than sufficient, and explicit user configuration >> > of proxy settings is a non-starter. > That is an attack in my book and publi

Re: [TLS] [Editorial Errata Reported] RFC7568 (4561)

On 08/12/15 04:05, Martin Thomson wrote: > On 8 December 2015 at 14:49, RFC Errata System > wrote: >> TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly, >> TLS 1.2 was drafted in 2006, but not published until 2008. > > > The date on the documents are indeed wrong. >

Re: [TLS] Data volume limits

Hi Watson, On 16/12/15 03:36, Watson Ladd wrote: > The problem is that once you stack enough of those negligible > probabilities together, you end up with something big. Push up to > 2^{63} bytes, and the collision probability is 1/4 or 1/2 (I didn't > recompute it just now). The collision prob

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT)

On 17/12/15 14:58, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-tls-cached-info-20: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this >

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

A few notes on this: - Calling for the IETF to do something isn't how it works. People who want thing X to be done need to write the draft and then see if it gets support. I suspect an md5-die-die-die draft would get quite a bit of support but... - The points Victor made about long-term stored d

[TLS] Fwd: New Non-WG Mailing List: Lurk -- Limited Use of Remote Keys

We discussed this topic briefly at IETF94 and in more detail at the Marnew workshop. There seemed to be at least enough interest for a list so... Cheers, S. PS: I'd say best to wait 'till next Wednesday or so to start list discussion so that folks have time to join the list. Forwarded

Re: [TLS] I-D Action: draft-ietf-tls-cached-info-22.txt

Hi all, I plan to send the approval message for this tomorrow but wanted to just check one thing first. In his IESG review [1] Barry Leiba suggested reserving the value zero in the registry created by section 8.2, which makes sense I think as otherwise people will just be puzzled about what to do

Re: [TLS] [Unbearable] Early code point assignment requests for "Transport Layer Security (TLS) Extensions" registry

Hi All, (Adding the TLS wg list, just in case.) I think this is fine and IANA should allocate a codepoint as requested. Cheers, S. On 02/02/16 23:50, John Bradley wrote: > > The Tokbind WG would like to ask for an early allocation of an IANA > code point for the "TLS Extension for Token Bindi

Re: [TLS] 0.5 RTT

On 23/02/16 22:37, Hugo Krawczyk wrote: > > (In particular, if these semantics may be based on stuff that happens > outside TLS, as Karthik and Watson were pointing out, then maybe we really > put a "Surgeon General" warning on 0.5 data of equal size to that of 0-RTT.) That, and/or also do a si

Re: [TLS] TRON notes?

On 23/02/16 23:29, =JeffH wrote: > is anyone writing up some notes from TRON > > to share here on the list? > > especially wrt the "What do we know and where are we going?" topic :) > > inqu

Re: [TLS] 0.5 RTT

On Tue Feb 23 19:28:12 2016 GMT-0800, Watson Ladd wrote: > On Tue, Feb 23, 2016 at 5:49 PM, Stephen Farrell > wrote: > > > > > > On 23/02/16 22:37, Hugo Krawczyk wrote: > >> > >> (In particular, if these semantics may be based on stuff that happens &g

Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05

Hi, It's now six and a bit months later. It's true those have been very distracting months for us all but when are we hoping to progress this draft? S On 12/05/2020 10:59, Stephen Farrell wrote: > > Hi, > > It's now four and a bit months later. It's true th

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

I oppose adoption. While there could be some minor benefit in documenting the uses and abuses seen when mitm'ing tls, I doubt that the effort to ensure a balanced document is at all worthwhile. The current draft is too far from what it'd need to be to be adopted. Send to ISE. S. On 23/07/2020 0

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Hi Rich, On 27/07/2020 13:37, Salz, Rich wrote: > Not adopting this seems to be ignoring reality. That depends on the "this" though. This "this" seems to me to be very much ok with mitm'ing, while doing a little bit to recognise the downsides of mitm'ing. I'm not objecting to attempts to descri

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

On 28/07/2020 00:48, Eric Wang (ejwang) wrote: > We felt the lack of a > baseline bcp is going to hurt the security posture of TLS rather than > driving the intermediary away. That makes no sense to me. Adopting this draft will require eliminating all such gibberish and instead finding text tha

Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact

IMO this document is absolutely not ready to become an RFC. It basically ignores the purpose of TLS which is to prevent exactly the MITM attacks being espoused here (IMO). In ignoring that, it ignores all of the bad consequences of such MITM attacks. As evidence: "To proxy a TLS session, a TLS P

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Hiya, On 29/07/2020 23:46, Eric Wang (ejwang) wrote: > It was the motivation of this draft to help reduce/prevent > non-compliance, as mentioned earlier. TLS MITM products, by design, do not comply with the TLS protocol, which is a 2 party protocol. There is *only* non-compliance in this space.

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Hiya, On 30/07/2020 00:56, Eric Rescorla wrote: > What text in TLS do you believe terminating proxies (in either direction) > do not conform to? I gtend to start with the abstract: "TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesd

[TLS] Fwd: [tlswg/draft-ietf-tls-esni] Fix superfluous padding edge cases. (#258)

I count 32 messages like this, relating to the ESNI draft, as github discussion, in the last 24 hours. Some of those do not need to be reflected to the TLS WG list, but I suspect others do, and before discussion resolves into an unchangeable outcome on github. Note: when I say "suspect" I don't

Re: [TLS] Fwd: [tlswg/draft-ietf-tls-esni] Fix superfluous padding edge cases. (#258)

Hi, On 11/08/2020 20:33, Christopher Patton wrote: > This is probably my fault, I apologize. No need! It looks like a lot of the editorial/lint stuff wouldn't need to be brought to the list but that one looked like it might. And since Chris says they're gonna mail the list anyway, that'll be fin

Re: [TLS] Fwd: [tlswg/draft-ietf-tls-esni] Fix superfluous padding edge cases. (#258)

On 11/08/2020 21:44, Eric Rescorla wrote: > On Tue, Aug 11, 2020 at 1:24 PM Stephen Farrell > wrote: > >> On 11/08/2020 20:37, Eric Rescorla wrote: >>> I note that draft-ietf-git-github explicitly permits discussion on the >>> issues, >> >> Well,

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

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 can't keep up with that and coding at the same time so (being busy elsewhere) paused my coding work in the hope that t

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

ing on the latest version. S [1] https://github.com/sftcd/openssl/tree/master/esnistuff > > 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 Ste

Re: [TLS] TLS WG GitHub interaction

On 22/10/2020 04:31, Martin Thomson wrote: > On this point, I regard the ECH work as being effectively a > self-selected design team. I have been unable to keep tracking the > work and lack the context to engage on the topics that do come back > to the list for discussion. +many - I don't know i

[TLS] ECH & HPKE versions as an example of too much githubbery

Hiya, The latest ECH draft from Oct 16 says "ECH uses draft-05 of HPKE for public key encryption." The latest HPKE draft (-06) from Oct 23 has a few minor incompatible changes (for good but relatively trivial reasons). So for interop ECH apparently requires use of an outdated I-D, despite the

Re: [TLS] ECH test server

On 27/10/2020 18:37, Chris Box (BT) wrote: Hi, I would like to test an ECH-enabled client, but am struggling to find a public test server with a published ECHconfig in its HTTPS record. Do any yet exist? I've looked in all these places, but none are mentioned: https://github.com/tlswg/draft-

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

avoided. Cheers, S. PS: I neglected to say in my earlier mail that hpke-05 has an interop bug that we discovered when I was verifying the test vectors a few months ago. It's not the right basis to pick if we want esni-08 to be used for interop really. But more to the point, nor is a moving tar

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

Hiya, On 27/10/2020 23:06, Eric Rescorla wrote: On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell wrote: Hiya, On 27/10/2020 22:28, Mark Nottingham wrote: Stephen, I don't think what you're complaining about can be attributed to GitHub. Tools are just tools, how they're

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

On 27/10/2020 23:27, Eric Rescorla wrote: In fact, it*is* the IETF process, or rather one permitted IETF process, since RFC 8874. I don't believe the current case matches my recollection of that, but I've not checked in detail. The lack of list discussion certainly smells wrong to me. If

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

-02-202009031000/ [1] https://datatracker.ietf.org/doc/minutes-interim-2020-tls-03-202009210800/ On Oct 27, 2020, at 16:31, Stephen Farrell wrote: Hiya, The latest ECH draft from Oct 16 says "ECH uses draft-05 of HPKE for public key encryption." The latest HPKE draft (-06)

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

Hiya, On 10/11/2020 03:44, Joseph Salowey wrote: Based on interest and support expressed at IETF 108, this email starts the call for adoption of draft-vvv-tls-cross-sni-resumption. The draft can be found here: https://tools.ietf.org/html/draft-vvv-tls-cross-sni-resumption-00 This adopti

Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hiya, On 10/11/2020 10:21, tom petch wrote: I am confused about the treatment here of DTLS. The Abstract seems clear about the proposed action for TLS but then the second paragraph has " This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC6347)" Mmmm, really? Sorry, I don't

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

On 10/11/2020 11:30, tom petch wrote: Perhaps a second look at the algorithm to work out why these got missed to get a fix on how many more there may be. Sure, that's reasonable. (Mightn't be today.) Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_si

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

On 10/11/2020 16:35, Sean Turner wrote: Sorry for any confusion introduced as a result of this typo. DTLS 1.0 is RFC4347 not RFC 6347; RFC 6347 is DTLS 1.2. Ah, mea-culpa then (even if someone else suggested the change I should've spotted that;-). I'll look back at the script algorithm in any

Re: [TLS] ECH: Reuse HPKE context across HRR

Hiya, On 10/11/2020 22:27, Christopher Patton wrote: 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

Re: [TLS] Genart last call review of draft-ietf-tls-oldversions-deprecate-09

On 25/11/2020 11:46, Mohit Sethi via Datatracker wrote: Reviewer: Mohit Sethi Review result: Ready Thanks. Will look at those nits when next editing. Cheers, S. I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being proce

Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hiya, On 28/11/2020 04:39, Gary Gapinski wrote: Looking at https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-09 §2: * §2 ¶5 has «TLS 1.3, specified in TLSv1.3 [RFC8446]…». * §2 ¶4 has «TLSv1.2, specified

Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hi Keith, In general I agree with Ekr's position on this (not a surprise as a co-author I guess:-) so I won't repeat arguments. I do have one question below though that wasn't yet touched upon... On 28/11/2020 00:44, Keith Moore wrote: While I agree that TLSv1.0 and TLSv1.1 should be avoided as

Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hi Eliot, On 28/11/2020 10:45, Eliot Lear wrote: Hi there IESG I support the intent of this document, and I think the approach to update the various documents listed is the right one. Cool. Because of the breadth of documents updated, I wonder if at least some implementation guidance is wa

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hiya, On 01/12/2020 00:29, Peter Gutmann wrote: However I think your comment points out the overall problem: usage in web, mail and OSes This means there's no consideration at all of use in embedded/SCADA/whatever. I wouldn't agree with "no consideration" but guess we might agree about a

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

(Even though this sub-thread has no effect on the draft, I couldn't resist:-) On 03/12/2020 23:53, Rob Sayre wrote: The enterprise perspective is not usually considered or understood at IETF I think that perspective is both considered and understood, but not usually accommodated. I think yo

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hi Michael, On 04/12/2020 15:14, Ackermann, Michael wrote: We (Enterprises) are not as involved as we should be in IETF, and that is our own problem/fault. What I think irritates people like Stephen, I'm not irritated at all:-) is that there have been situations where we finally try to get

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hi Tom, On 10/11/2020 11:33, Stephen Farrell wrote: On 10/11/2020 11:30, tom petch wrote: Perhaps a second look at the algorithm to work out why these got missed to get a fix on how many more there may be. Sure, that's reasonable. (Mightn't be today.) Just did that check by

Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hiya, On 14/12/2020 19:25, Gary Gapinski wrote: On 11/28/20 10:13 AM, Stephen Farrell wrote: Hiya, On 28/11/2020 04:39, Gary Gapinski wrote: Looking at https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-09 <https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hiya, On 15/12/2020 12:51, tom petch wrote: I see RFC5953, RFC6353 have been added.  RFC5953 is obsoleted so should it be listed in 1.1 in the list of RFC already obsoleted, the one that start with RFC5101? Argh/oops:-) I just posted -11 fixing that. Thanks, S. OpenPGP_0x5AB2FAF17B172B

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

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 inter

Re: [TLS] Robert Wilton's No Objection on draft-ietf-tls-oldversions-deprecate-11: (with COMMENT)

Hiya, On 12/01/2021 18:14, Robert Wilton via Datatracker wrote: Robert Wilton has entered the following ballot position for draft-ietf-tls-oldversions-deprecate-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC line

Re: [TLS] Éric Vyncke's Yes on draft-ietf-tls-oldversions-deprecate-11: (with COMMENT)

Hiya, On 19/01/2021 10:23, Éric Vyncke via Datatracker wrote: Éric Vyncke has entered the following ballot position for draft-ietf-tls-oldversions-deprecate-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free

Re: [TLS] Robert Wilton's No Objection on draft-ietf-tls-oldversions-deprecate-11: (with COMMENT)

Hiya, On 19/01/2021 11:05, Rob Wilton (rwilton) wrote: -Original Message- From: iesg On Behalf Of Stephen Farrell Sent: 12 January 2021 21:35 To: Rob Wilton (rwilton) ; The IESG Cc: draft-ietf-tls-oldversions-deprec...@ietf.org; tls-cha...@ietf.org; tls@ietf.org Subject: Re: [TLS

Re: [TLS] Barry Leiba's Yes on draft-ietf-tls-oldversions-deprecate-11: (with COMMENT)

Hiya, On 19/01/2021 14:14, Barry Leiba via Datatracker wrote: Barry Leiba has entered the following ballot position for draft-ietf-tls-oldversions-deprecate-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free

Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-12.txt

Hiya, On 23/01/2021 02:35, Gary Gapinski wrote: https://github.com/tlswg/oldversions-deprecate/issues/10 remains unresolved. I believe that the RFC editor's copy editing pass should address that kind of thing, so left it for them. At this stage it's likely better to handle it that way, but I

Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

Hiya, I realise it's not proposed as a wg document, but fwiw, I think John is quite correct below. The only additional point I'd add is that I've seen cases over the years where the fact that confidentiality really *is* required only became clear when people actually considered how to attack sys

Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

elieve experience so far has shown that to be the wisest approach in general. S. Thanks, --Jack -Original Message- From: TLS On Behalf Of Stephen Farrell Sent: Wednesday, February 10, 2021 7:08 AM To: John Mattsson ; TLS@ietf.org Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authenticatio

Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

that can be dangerous in unexpected and hard to analyse ways, should they get widely deployed. (And I hope we've all learned that undeploying these things is a big pile of painful work, to put in very nicely:-) Cheers, S. Thanks, --Jack -Original Message- From: Stephen Farrell Sent

Re: [TLS] [ECH] Reverting the config ID change

Hiya, On 16/02/2021 21:31, Christopher Wood wrote: That's true, but I'd personally prefer one tracking vector to two. This structure also better aligns with other proposed use cases for HPKE configurations. I also don't see an immediate need for flexibility in this value given that there are ex

Re: [TLS] [ECH] Reverting the config ID change

On 17/02/2021 00:34, Eric Rescorla wrote: How is it any harder to manage a multi-octet server-chosen value than a single-octet server-chosen value? Easier for the library on the server side. If it's >1 octet then someone will want some semantics. If ==1 then they'll have to accept none and po

Re: [TLS] [ECH] Reverting the config ID change

On 17/02/2021 16:00, Eric Rescorla wrote: On Tue, Feb 16, 2021 at 4:44 PM Stephen Farrell wrote: On 17/02/2021 00:34, Eric Rescorla wrote: How is it any harder to manage a multi-octet server-chosen value than a single-octet server-chosen value? Easier for the library on the server side

Re: [TLS] [ECH] Reverting the config ID change

On 17/02/2021 21:00, Eric Rescorla wrote: On Wed, Feb 17, 2021 at 8:24 AM Stephen Farrell wrote: On 17/02/2021 16:00, Eric Rescorla wrote: On Tue, Feb 16, 2021 at 4:44 PM Stephen Farrell < stephen.farr...@cs.tcd.ie> wrote: On 17/02/2021 00:34, Eric Rescorla wrote: How is

[TLS] ech/esni - theoretically some inner CH's wouldn't fit...

Hiya, The CH in TLS has a 3 octet length. The payload in ECH has a 2-octet length. Hopefully that'll never matter but it's an inconsistency I don't recall coming up before. (Apologies if I've forgotten, or if I've missed something in 8446 that forbids bigger CH's.) I'm fine with just leaving it

Re: [TLS] Moving the ECH interop target

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/d

Re: [TLS] Moving the ECH interop target

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.o

[TLS] implementing ESNI/ECH draft-09

Hiya, I've just got my OpenSSL code "working" for draft-09. The s_client and s_server talk to one another and do ECH; NSS's tstclnt talks to my s_server and does ECH and my s_client talks to cloudflare's test server and does ECH. So this can be made work, which is the good news. (Thanks to Marti

Re: [TLS] implementing ESNI/ECH draft-09

Hiya, On 02/03/2021 21:49, David Benjamin wrote: On Sun, Feb 28, 2021 at 12:35 PM Stephen Farrell wrote: - This is *much* harder to implement compared to ESNI as it interacts with the rest of the TLS stack/library in many more ways. It should be an explicit goal to reduce that

Re: [TLS] implementing ESNI/ECH draft-09

Hiya, Since I was logged into the github web site (as happens occasionally but not often) and as requested at the TLS session, I translated the text below into github issues in the hope that they might be included in discussion. Links to each below. On 28/02/2021 17:34, Stephen Farrell wrote

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

Hi all, I raised a github issue [1] related to (but different from) this but would prefer a discussion via email if that's ok. Depending how this goes, I can create a new GH issue I guess. ECH draft-09 (and -10) requires the client to verify that the server has processed ECH by comparing 8 octe

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

Hiya, On 18/03/2021 16:55, Christian Huitema wrote: On 3/18/2021 7:35 AM, Christopher Patton wrote: 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 recal

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

Hiya, On 18/03/2021 19:17, David Benjamin wrote: I don't think I'd agree that *most* of the work is in the secret > computation per se. Actually doing trial decryption with > the secret requires reaching down into the record layer. > This is especially onerous for QUIC, where the record layer

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

Hiya, I agree with your analysis except for the very last part... On 19/03/2021 23:59, Christian Huitema wrote: We do have new information that this is somewhat costly to implement because it requires computing two handshake secrets on the client. On the other hand, it seems that the cost i

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

Hiya, On 23/03/2021 22:52, Christopher Patton wrote: 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

Re: [TLS] Solving HRR woes in ECH

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 TL

Re: [TLS] Don't Split HelloRetryRequest

I'm not sure I agree with all of Martin's remarks below, but I absolutely agree both that we seem to be almost happily adding complexity and that that's a bad plan. S. On 01/04/2021 02:57, Martin Thomson wrote: I just reviewed the proposal to split HelloRetryRequest into outer and (encrypted)

Re: [TLS] Don't Split HelloRetryRequest

Given the range of Martin's comments, I'd be surprised if that could be reduced to a PR;-) 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? Thanks, S. On 0

Re: [TLS] Don't Split HelloRetryRequest

Hiya, On 01/04/2021 19:13, Christopher Patton wrote: 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 serv

Re: [TLS] Don't Split HelloRetryRequest

, and there are even RFCs that show that;-) That is what I think may be happening wrt ECH - we seem to be forgetting that this stuff is inherently complex, even in it's simplest case, and making it more complex could kill it. Cheers, S. On Apr 1, 2021, at 4:46 AM, Stephen Farrell wrote: I

Re: [TLS] Don't Split HelloRetryRequest

Hiya, On 01/04/2021 19:24, Stephen Farrell wrote: some guidance on checking your front- end's choice of curves and failing when some of the HRR cases get out of whack Actually it occurs to me that we could for example say that back-ends are RECOMMENDED to support the first curve list

Re: [TLS] ECH-10 interop test server

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 for draft-ietf-tls-esni-09. The endpoint is https://crypto.clou

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 s

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 w

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, bu

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 30,

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] 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 rath

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] 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 de

[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] 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,

  1   2   3   4   5   6   7   >