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

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

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 listed

Re: [TLS] Don't Split HelloRetryRequest

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'm not sure I agree with all of Martin's

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

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

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

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

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

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

[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

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

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

[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

Re: [TLS] Moving the ECH interop target

: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

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:

[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

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

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

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

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

hings is a big pile of painful work, to put in very nicely:-) Cheers, S. Thanks, --Jack -----Original Message- From: Stephen Farrell Sent: Wednesday, February 10, 2021 6:46 PM To: Jack Visoky ; John Mattsson ; TLS@ietf.org Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity onl

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

nce 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 Authentication and Integrity only Ciph

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

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

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

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

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

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.

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

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 comparing

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

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

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

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

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

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,

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

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

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

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

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) from Oct 23 has a few minor incompatible ch

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.

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 used is what's

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

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 target. Cheers, On 28 Oct 2020, at 7:31 a

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:

[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

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

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

rsion. 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 Stephen Farrell <

[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

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

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

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

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

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

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

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 those have > been v

Re: [TLS] Consultation About Assignment of ExtensionTypes

Hiya, On 19/06/2020 01:36, Benjamin Kaduk wrote: > On Fri, Jun 19, 2020 at 01:24:05AM +0100, Stephen Farrell wrote: >> >> Hiya, >> >> I think these are 16 bit code points? If so, I would >> barf slightly less if we could allocate 0x0bad every >> time.

Re: [TLS] Consultation About Assignment of ExtensionTypes

Hiya, I think these are 16 bit code points? If so, I would barf slightly less if we could allocate 0x0bad every time. I do think signalling opprobrium somehow would be right here. Not sure how best we ought do that though tbh. Cheers, S. On 13/06/2020 18:20, Yoav Nir wrote: > Hi. > > I’m

Re: [TLS] TLS Encrypted Client Hello implementations?

On 15/06/2020 19:41, Rob Sayre wrote: > Are there public implementations that track recent drafts and/or the github > repository? Is anyone publishing DNS records that conform to the more > recent specifications and names? I've been busy on another thing but do plan to do that based on the

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

Hiya, Sorry if I'm missing a bit of context... On 02/06/2020 18:28, Christian Huitema wrote: >clients prevent server identification by sending > an empty record_digest field in the ClientEncryptedCH, and That seems to me to be an unnecessary breach of the do-not-stick-out

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

Hi, It's now four 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? Thanks, S. On 06/01/2020 15:16, Stephen Farrell wrote: > > Hi all, > > I've just submitted -06 that (I think/hope:-) addresses

Re: [TLS] Bikeshedding ECHO

On 07/05/2020 23:52, Christopher Wood wrote: > Erik raises some compelling reasons to change the name from ECHO > to... something else less confusing or misleading [1]. Candidates > from the PR include ETCH (Encrypted TLS Client Hello), ECH, and > EHELLO. Since the HTTPSSVC draft aims for WGLC

Re: [TLS] ECHO padding review and some open issues

Hiya, On 24/04/2020 00:37, Stephen Farrell wrote: > > Sorry - I have one more I wanted to raise as an issue. Will > do that tomorrow and send a mail, > I've done that now. [1] We did have some list mails on this earlier but it kinda tailed off rather than got resolved. Cheers, S

Re: [TLS] ECHO padding review and some open issues

Sorry - I have one more I wanted to raise as an issue. Will do that tomorrow and send a mail, Cheers, S. On 24/04/2020 00:30, Christopher Wood wrote: > In preparation for next week's virtual interim session on ECHO, I'd like to > draw your attention to the following issues and PRs we'll be

Re: [TLS] Virtual TLS Interim Meeting

Hiya, Ack wrt fine-grained issues. If nobody says otherwise I'll do that. On 04/04/2020 15:36, Christopher Wood wrote: > I'll leave it to Sean and Joe to determine whether or not re-hashing > some of these issues is appropriate. Yeah, I figured asking would be best. For a bunch of these issues,

Re: [TLS] Virtual TLS Interim Meeting

Hi Joe, Pre-agenda bashing question for chairs and authors of the ESNI/ECHO draft... I'd like to try again to suggest simplifications for ECHOConfig (e.g. no extensions, just one public key per RR VALUE etc.) and perhaps also some more rules constraining inner/outer CH variances. How would you

Re: [TLS] Dropping "do not stick out" from ECHO

Hiya, I was wondering what I wanted to say about this, until... On 22/03/2020 22:16, Eric Rescorla wrote: > I think we should relax this requirement. It's turning out to be hard > enough to design ECHO as-is. > > If/when we get ECHO fully designed and widely deployed, we can then try to > find

Re: [TLS] three ECHO issues

Hiya, On 09/03/2020 02:13, Christian Huitema wrote: > On 3/8/2020 10:14 AM, Stephen Farrell wrote: > >> I'm questioning whether that's a good goal or not. In my >> analysis of the various extensions, only SNI and ALPN seem >> to offer immediate value. >

Re: [TLS] three ECHO issues

Moar below... :-) On 08/03/2020 17:25, Christopher Wood wrote: > > > On 8 Mar 2020, at 10:14, Stephen Farrell wrote: > >> Hiya, >> >> On 08/03/2020 16:07, Christopher Wood wrote: >>> Thanks for raising these issues! Please see inline below. >>&

Re: [TLS] three ECHO issues

Hiya, On 08/03/2020 16:07, Christopher Wood wrote: > Thanks for raising these issues! Please see inline below. > > On 8 Mar 2020, at 8:18, Stephen Farrell wrote: > >> Hiya, >> >> Thanks for the new ECHO PR. [1] I think this is the right direction >> but I

Re: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS

sium.  She filled in some of the > details and the work was recognized by those there. Whit was also there > also there and gave a great presentation. Unfortunately, women in this > field seem not to get the credit they deserve. > > --tony > > > On 2020-03-08 10:56 AM, Step

[TLS] three ECHO issues

Hiya, Thanks for the new ECHO PR. [1] I think this is the right direction but I have three issues with how it's done in the PR right now that I think would benefit from list discussion before a new I-D is produced or the PR is merged. 1) Padding. This should be easy but somehow seems to be

Re: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS

On 08/03/2020 14:46, Tony Rutkowski wrote: > > TLS is particular has a history going back to 1986 when the platform was > first announced by the USG and the TLS specification was instantiated > initially in the GOSIP standards and then in ITU/ISO standards. That's false. I've seen it repeated

Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

Hiya, On 05/03/2020 04:32, Watson Ladd wrote: > It's not the usecase: it's the program. Postfix made architectural > choices that make storing tickets allegedly expensive. > > I would be a lot more sympathetic if Viktor could provide actual > measurements with actual numbers demonstrating that

Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

Hiya, On 05/03/2020 02:25, Rob Sayre wrote: > >> I also note what seems like a correlation between >> people's yes/no opinions on this and whether or not they >> (or sponsors/employers) are involved in implementing >> a web browser. >> > I don't think this is a fair characterization To be

Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

Hiya, On 04/03/2020 16:06, Sean Turner wrote: > Must the ticket reuse use case be addresses > in draft-ietf-tls-ticketrequests? Yes. I think Viktor's use case is one to not bugger up (even if one doesn't need to support it) and don't see how supporting it breaks something. (While also

Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

Hiya, On 04/03/2020 03:36, Joseph Salowey wrote: > The chairs are moving forward with accepting the document as a working > group item without any additional constraints except that the document MUST > be evaluated for potential incompatibilities with NIST competition entries > before WGLC.

Re: [TLS] ESNI/ECHO updates

Hiya, On 24/02/2020 03:57, Christopher Wood wrote: > We’re actively analyzing ECHO. As of now, we expect this to complete > in March, I would welcome seeing that done in a more open manner. S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

Hiya, On 21/02/2020 22:28, Watson Ladd wrote: > How do these characteristics affect the proposal in the draft? I don't know. There are 17 of them. I'm not spending the time on this myself 'till there are a small number of winners. Speculating though, NIST often end up with a load of variants -

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

On 21/02/2020 22:11, Watson Ladd wrote: > https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/ > https://blog.cloudflare.com/the-tls-post-quantum-experiment/ > > This was also presented at the NIST standardization workshop in October of > 2019. Thanks. I read through [1].

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

On 21/02/2020 22:02, Watson Ladd wrote: > We have already deployed widespread experiments that conducted the > hybridization described in this draft, already have implementations > supporting an approach similar to this draft, and that produced > valuable input to the standardization process. It

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

Hiya, On 21/02/2020 21:24, Scott Fluhrer (sfluhrer) wrote: > What it tries to address is "once we have an > approved algorithm, how do we integrate it into TLS". Except that we do not have an approved algorithm. We have 17 round 2 KEMs with vastly different properties. Even when NIST are done

Re: [TLS] ESNI/ECHO updates

Hiya, On 15/02/2020 00:17, Rob Sayre wrote: > Hi, > > Are there any updates to ESNI/ECHO to share as a draft or an update? I'm also interested:-) > > It's been a few months, so just wondering (even if there's not much to say). I did some initial hacking on a branch of my openssl fork to see

Re: [TLS] ESNI Android Implementation

Sorry, I had meant to reply to this but forgot... On 13/02/2020 21:34, Nick Sullivan wrote: > Hi Justice, > > Thanks for reaching out and welcome. At this point, another implementation > of draft-02 wouldn't hurt, but it also likely won't contribute much to the > development process for this

Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

Hiya, I said this in the other thread but I'll repeat a call for a bit of clarity that's not normally needed: On 13/02/2020 17:12, Joseph Salowey wrote: > Adopting the draft means the working group thinks the topic is a good idea > and the draft is a good place to start the work. I think the

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

, though IIRC the circumstances that lead to that phrase didn't pan out as well as had been hoped. And one minor addendum: On 12/02/2020 23:41, Watson Ladd wrote: > What's the point of composite schemes after the NIST competition > finishes? SHA-0:-) Cheers, S. > > > > On 2/

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

Hiya, On 12/02/2020 21:57, Martin Thomson wrote: > Only a few of them. Some are OK, but the number is few, I agree. I > haven't found a good summary of the second round candidates and I > don't have time to dig into all of the candidates. Fine reason to wait and see IMO. I'd be much happier

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Hiya, I have no particular position about this draft but am curious about 2 things: #1 I don't get why it's not possible for postfix to determine the best way to manage tickets based on the destination port to which the ClientHello is sent. I totally get why that won't solve 100% of cases, but

<    1   2   3   4   5   >