Re: [TLS] New Draft: Using DNS to set the SNI explicitly

For me, the main drawback here (besides the futuristic assumptions), is the continued reliance on the DNS infrastructure. Even when using TLS, the DNS is architecturally hostile to privacy, e.g., due to resolvers operated by ISPs or the client subnet extension. I'm sympathetic to the desire to

Re: [TLS] TLS 1.3 -> TLS 2.0?

I am in total agreement with Nick here. "TLS 1.3" accurately describes what we're doing here, and it's consistent with our past naming scheme. There is no upside to changing away from 1.3, and as Nick notes, lots of potential downside. --Richard On Wednesday, August 31, 2016, Nick Sullivan

Re: [TLS] Confirming consensus: TLS1.3->TLS*

On Mon, Nov 21, 2016 at 2:51 PM, Yoav Nir wrote: > > > On 21 Nov 2016, at 20:43, Salz, Rich wrote: > > > > > >> With this in mind, I'm voting in favor of any re-branding of TLS 1.3 > where the > >> protocol name remains "TLS" and major version becomes > 1.

Re: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors

+1 On Thu, Dec 8, 2016 at 8:57 AM, Eric Rescorla wrote: > +1 > > On Thu, Dec 8, 2016 at 8:05 AM, Sean Turner wrote: > >> All, >> >> There’s been some interest on the list and more in Seoul to adopt >>

Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)

On Thu, Dec 29, 2016 at 1:50 PM, Stephen Farrell wrote: > > > On 29/12/16 18:38, Eric Rescorla wrote: > > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell < > stephen.farr...@cs.tcd.ie > >> wrote: > > > >> > >> Hiya, > >> > >> On 29/12/16 17:37, Adam Langley wrote: >

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Fri, Jul 7, 2017 at 12:35 PM, Russ Housley wrote: > Richard: > > Without taking a position on whether this group should take on this work, > a couple of questions about alternative approaches (sorry if these have > been answered before): > > 1. It seems like the

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Sat, Jul 8, 2017 at 12:11 PM, Tony Arcieri <basc...@gmail.com> wrote: > On Fri, Jul 7, 2017 at 6:02 AM, Richard Barnes <r...@ipv.sx> wrote: > >> You could avoid changing how the DH works altogether by simply exporting >> the DH private key, encrypted with a

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Without taking a position on whether this group should take on this work, a couple of questions about alternative approaches (sorry if these have been answered before): 1. It seems like the requirement here is that the DH private key be *predictable* by the monitoring box based on some static

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Wed, Jul 12, 2017 at 10:22 AM, Ted Lemon wrote: > On Jul 12, 2017, at 10:18 AM, Kyle Rose wrote: > > We need to dispel the myth that mere inaction on our part will on its own > prevent implementation of these mechanisms, if for no other reason but to >

Re: [TLS] Comments on EndOfEarlyData

On Mon, May 15, 2017 at 11:16 AM, Britta Hale wrote: > On the Sunday 30/05 TLS:DIV workshop there was mention of the > EndOfEarlyData message and its status as a handshake message or alert > message. > > The main argument mentioned for making EndOfEarlyData a handshake

Re: [TLS] Comments on EndOfEarlyData

On Tue, May 16, 2017 at 2:59 PM, Eric Rescorla wrote: > First, let me say I'm largely indifferent to this handshake versus alert > point, so if the WG wants to flip it back, I'm generally OK with that. > With that said, we recently implemented -20 and having it be > a handshake

Re: [TLS] Encrypted SNI

On Fri, Jun 2, 2017 at 11:43 AM, Toerless Eckert wrote: > Thanks, Benoit > > [hope it's ok. to cross-port and redirect replies to TLS] > > I have not followed TLS 1.3 in detail, so a quick question first: > > Will TLS 1.3 still permit servers to send their certificate and/or SNI

Re: [TLS] OpenSSL now at draft-20

On Wed, May 3, 2017 at 6:48 PM, Martin Thomson wrote: > On 4 May 2017 at 02:29, Matt Caswell wrote: > > FYI, I have just made the necessary updates to bring the OpenSSL > > master branch up to draft-20 compatibility. Please test!! > > > That's

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Mon, Oct 2, 2017 at 5:43 PM, Russ Housley wrote: > > For starters, though, I'd be interested answers from the authors > > to two quick questions, though I suspect I can guess 'em: > > > > 1. TLS1.3 has had significant formal analysis. Did the authors > > or other

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Hi Ralph, Russ, Thanks for the update here. I agree that this is an improvement over draft-green-tls-static-dh-in-tls13, in particular because (1) it has a mechanism for mutual consent and (2) it only touches the outputs of the handshake, not the inputs. A couple of points to consider: Like

Re: [TLS] Update on TLS 1.3 Middlebox Issues

On Oct 7, 2017 10:43, "Salz, Rich" wrote: ➢ I don't want to speak for browser vendors, but history suggests that Option 3) may not be a viable one for browsers with a significant market share. They can do what they want, but if they’re “in the rough” on the consensus call, I

Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

Hey Cas, This question is a good one. Earlier I brought up mcTLS, which some folks have been working on to provide even more granular separations than you suggest: https://mctls.org/ I think the authors of draft-rhrd are trying for a more lightweight change to TLS. That said, there might be

Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

ges >> in the security analyses; for mctls, I expect it would be a completely new >> analysis. (I haven't seen any analyses of rhrd, but of the three, it is of >> course closest to the current setup.) >> >> Best, >> >> Cas >> >> >> On Fri, Nov 3,

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 25, 2017 22:34, "Stephen Farrell" wrote: Replying to just a couple of bits... On 25/10/17 15:23, David A. Cooper wrote: > Similarly, the best that TLS can offer in terms of privacy is that the > contents of the communication between the two endpoints is not

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Wed, Oct 25, 2017 at 12:06 PM, Salz, Rich wrote: > > since those other means would be easier and more effective. You > have done nothing to suggest otherwise. > > Public-key pinning and CT seem like they would prevent those other > mechanisms. No? > Remember that

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

But I agree, it would be good to have some more clarity around use cases and why not other solutions. On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes <r...@ipv.sx> wrote: > HTTP CONNECT is not great for some use cases because it requires the app > to be aware that it's dealing

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

it would be helpful to have a > section on when/why one would do this vs. CONNECT. > > On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes <r...@ipv.sx> wrote: > >> Hey TLS folks, >> >> Owen, Max, and I have been kicking around some ideas for how to make >> secure

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

ur description of client > behavior applies equally to ATLS and HTTP CONNECT. > > On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes <r...@ipv.sx> wrote: > >> But I agree, it would be good to have some more clarity around use cases >> and why not other solutions. >>

Re: [TLS] Proposed text for dnsssec chain extension draft

On Thu, Apr 26, 2018 at 11:13 AM, Nico Williams wrote: > On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote: > > Thanks for producing some text. I understand why one might think that > > having a reserved 16-bit field is useful here, but I don't really > >

Re: [TLS] Proposed text for dnsssec chain extension draft

On Thu, Apr 26, 2018 at 11:22 AM, Nico Williams wrote: > On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote: > > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni > > > wrote: > > > On Apr 26, 2018, Eric Rescorla wrote: >

Re: [TLS] Draft updates: tls-dnssec-chain

On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni wrote: > > > > On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote: > > > >This specification can also be used to optionally convey > >authenticated denial of existence of TLSA records. Restrictive

Re: [TLS] raw public keys in the wild?

Since we're talking about bare public keys / not verifying certificates again, a brief reminder: https://tools.ietf.org/html/draft-barnes-dane-uks-00 On Wed, Aug 22, 2018 at 12:49 AM Peter Gutmann wrote: > Viktor Dukhovni writes: > > >Some DANE users have reached similar conclusions, though a

Re: [TLS] integrity only ciphersuites

On Mon, Aug 20, 2018 at 7:46 PM Geoffrey Keating wrote: > "Nancy Cam-Winget \(ncamwing\)" > writes: > > > In following the new IANA rules, we have posted the draft > > https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00 > > to document request for registrations of HMAC based

[TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt

ls-pake-04.txt To: Richard Barnes , Owen Friel A new version of I-D, draft-barnes-tls-pake-04.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-barnes-tls-pake Revision: 04 Title: Usage of PAKE with TLS 1.3 Document d

Re: [TLS] TLS interception technologies that can be used with TLS 1.3

<ynir.i...@gmail.com> > *Date: *Thursday, March 15, 2018 at 6:41 PM > *To: *Richard Barnes <r...@ipv.sx> > *Cc: *Rich Salz <rs...@akamai.com>, Hubert Kario <hka...@redhat.com>, " > tls@ietf.org" <tls@ietf.org> > *Subject: *Re: [TLS] TLS interception

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey wrote: > Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document as is or to bring the > document

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Re-adding the list. On Wed, Apr 4, 2018, 22:39 Richard Barnes <r...@ipv.sx> wrote: > > > On Wed, Apr 4, 2018, 22:34 Nico Williams <n...@cryptonector.com> wrote: > >> On Wed, Apr 04, 2018 at 07:22:38PM -0700, Eric Rescorla wrote: >> > I don't think that

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

ere's not still some utility to be had. --Richard On Wed, Apr 4, 2018, 22:57 Eric Rescorla <e...@rtfm.com> wrote: > > > On Wed, Apr 4, 2018 at 7:31 PM, Nico Williams <n...@cryptonector.com> > wrote: > >> On Thu, Apr 05, 2018 at 02:39:43AM +, Richard Barnes wro

[TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

-tls-pake-00.txt To: Richard Barnes <r...@ipv.sx>, Owen Friel <ofr...@cisco.com> A new version of I-D, draft-barnes-tls-pake-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-barnes-tls-pake Revision: 00 Title:

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Thu, Apr 12, 2018 at 9:46 AM, Paul Wouters <p...@nohats.ca> wrote: > On Thu, 12 Apr 2018, Richard Barnes wrote: > > The question Ben was asking, though, is whether the impact of that process >> mistake is serious enough to merit pulling back the doc from the RFC editor.

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

This is in fact what I proposed in the room in London. Let's publish draft this as-is, and handle what they want as a follow-on. On Thu, Apr 12, 2018 at 5:47 PM, Martin Thomson wrote: > If this is indeed about adding [goo], what prevents Viktor or Paul > from

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams wrote: > On Thu, Apr 12, 2018 at 04:10:27PM -0700, Eric Rescorla wrote: > > On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni > > > wrote: > > > Proposed text: > > > > > >When the server has

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

rotection than symmetric PSK in the > event of server breach. > > > > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Richard Barnes > *Sent:* 11 April 2018 15:54 > > […] > > We would love to hear any feedback on the approach proposed here, and on > whether o

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, Apr 18, 2018 at 4:56 PM, Nico Williams <n...@cryptonector.com> wrote: > On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote: > > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni <ietf-d...@dukhovni.org > > > > wrote: > > > > > >

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote: > On Wed, 18 Apr 2018, Joseph Salowey wrote: > > This is a combined response of Viktor, Nico and Paul. > > Concerns have been raised about the trade-offs associated with pinning >> and I >> do not think we currently have

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes <r...@ipv.sx> wrote: > > > > I do not support adding a field to the protocol with semantics to be > defined later. Especial

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > > On Apr 18, 2018, at 4:52 PM, Richard Barnes <r...@ipv.sx> wrote: > > > > Secondary point. Still don't think we should deliberately include > undefined fields, e.g., be

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey wrote: > We've had a lot of discussion on this thread that has pointed out that > there are enough issues with the current document that we should recommend > that the AD pull it back from the RFC editor. > > Concerns have been

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

nst server compromise with SPAKE2. >> The server can store w*N as you suggest, but it also has to store w*M >> because it must calculate y*(T-w*M). An attacker that learns w*M and w*N >> from a compromised server can then impersonate a client. >> >> The rest of your comment

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

from observing a > previous session, and that the server identity can be identified through > probing.) > > Regards, > > Jonathan > > > > On Mon, 16 Apr 2018 at 19:43 Richard Barnes <r...@ipv.sx> wrote: > >> Hey Jonathan, >> >> Thanks fo

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

> You are, but it's not mentioned in the security section. > As it's a security consideration that you don't get in vanilla TLS I feel > that it should be mentioned. > > Regards, > > Jonathan > > > On Mon, 16 Apr 2018 at 20:01 Richard Barnes <r...@ipv.sx> wrote: >

Re: [TLS] Connection ID in TLS

I don't think Connection-ID is really required for ATLS. As Carsten and Owen mentioned in the side meeting, there are a few ways to use HTTP to correlate the relevant messages. On Tue, Mar 20, 2018 at 5:15 PM, Fossati, Thomas (Nokia - GB/Cambridge) < thomas.foss...@nokia.com> wrote: > On

Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS

On Tue, Oct 16, 2018 at 10:02 AM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > Unjust certificates can be bought for 150,- $ [citation-needed] https://xkcd.com/285/ I'm sure if you could produce such a certificates, the root programs would be happy to investigate how it was caused to be

Re: [TLS] TLS interim meeting material

I may have a conflict with the call, so I've gone ahead and put some opinion inline below... On Wed, Sep 12, 2018 at 5:40 PM Paul Wouters wrote: > > Hi, > > We have made available what we believe is a good starting point for > further discussion regarding tls-dnssec-chain draft. > > While I

Re: [TLS] TLS interim meeting material

Your responses here reveal a lot of the assumptions that you're reading in here that are not actually true, e.g., those noted below. On Wed, Sep 12, 2018 at 8:56 PM Paul Wouters wrote: > On Wed, 12 Sep 2018, Richard Barnes wrote: > > > Speaking as one of the attendees, I

Re: [TLS] TLS interim meeting material

One other bit of context here: DANE itself doesn't prevent these "downgrade" attacks in its native form, to say nothing of TLS. Recall that caching is optional for DNS clients, and the usage of DNSSEC validation results is up to the application. Suppose you had an application with the following

Re: [TLS] Interim meeting information

I am getting "This link to the event is no longer valid" from the below link, and I hear folks are having PSTN trouble as well. Are there some different coordinates we should be using? On Wed, Sep 12, 2018 at 9:59 AM Christopher Wood < christopherwoo...@gmail.com> wrote: > Below is an agenda

Re: [TLS] Interim meeting information

I just tried again, same error. On Fri, Sep 14, 2018 at 12:15 PM Joseph Salowey wrote: > It should be working now. > > On Fri, Sep 14, 2018 at 10:05 AM, Daniel Kahn Gillmor < > d...@fifthhorseman.net> wrote: > >> On Wed 2018-09-12 07:58:43 -0700, Christopher Wood wrote: >> > >>

Re: [TLS] TLSv1.2 - Is zero signature allowed in client CertificateVerify message?

I don't believe that's a valid signature according to rsa_pkcs1_sha256, so yeah, this is probably an error. --Richard On Sun, Sep 1, 2019 at 11:33 PM M K Saravanan wrote: > Hi, > > Is zero signature allowed in client CertificateVerify message (I am > guessing may be to indicate error

Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet

Thanks for invoking me by name, EKR :) tl;dr: We considered all available options, and using a new handshake type was the least bad. Watson has correctly summarized the goal here, which is to distribute a key that encrypts another key, which encrypts media. 1. Keys from the DTLS handshake

Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet

On Thu, Sep 5, 2019 at 2:38 AM Watson Ladd wrote: > I wish I understood the analysis of TLS 1.3 better, but a core feature > of the protocol is compositionality: the keys from the handshake are > fresh, unlike in TLS 1.2 where they were used to encrypt the Finished > thus posing an obstacle to

Re: [TLS] Distinguishing between external/resumption PSKs

t; Jonathan > > On Thu, 19 Sep 2019 at 16:26, Richard Barnes wrote: > >> On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland < >> jonathan.hoyl...@gmail.com> wrote: >> >>> That's how I would interpret the spec yes. >>> You could argue that there's

Re: [TLS] Distinguishing between external/resumption PSKs

On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland < jonathan.hoyl...@gmail.com> wrote: > That's how I would interpret the spec yes. > You could argue that there's a distinguishing attack where the attacker > measures the response time on PSKs to determine if it was an OOB PSK or a > resumption,

Re: [TLS] Distinguishing between external/resumption PSKs

I don't think anyone's asking for these cases to be differentiable on the wire. The question is whether the *server* can differentiate, in particular, the application running on the server. --Richard On Thu, Sep 19, 2019 at 2:36 PM Nico Williams wrote: > On Thu, Sep 19, 2019 at 08:06:26AM

Re: [TLS] Distinguishing between external/resumption PSKs

On Thu, Sep 19, 2019 at 5:49 PM Nico Williams wrote: > On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote: > > I don't think anyone's asking for these cases to be differentiable on the > > wire. The question is whether the *server* can differentiate, in

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

I also support adoption. On the question of how the work should be factored: It is true that this work comprises 3-4 fairly separable technologies. However, they have in common that they need to be pre-agreed between the client and server (except possibly the "known certificates" mechanism,

Re: [TLS] Adoption call for draft-rescorla-tls-semistatic-dh

I am also in favor of advancing this document, for similar reasons to Hannes. On Fri, Nov 22, 2019 at 2:56 AM Eric Rescorla wrote: > +1 > > On Thu, Nov 21, 2019 at 7:30 PM wrote: > >> I am in favor of adopting this document as a starting point for further >> work. It fits nicely into the work

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

On Mon, Oct 21, 2019 at 11:44 AM David Benjamin wrote: > On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: > >> On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: >> > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, >> > which can be found here: >> > >> >

Re: [TLS] I-D Action: draft-rescorla-tls-ctls-04.txt

So it seems like that would add a third class of extension: 1. Required extensions (type + value), not serialized 2. Required extensions (type only) [<--new], serialized as length+value 3. Optional extensions, serialized as type+length+value There is some appeal to the logical completeness. The

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

I agree that this is a worthwhile effort for the WG. On Wed, Sep 2, 2020 at 16:05 Eric Rescorla wrote: > > > On Wed, Sep 2, 2020 at 12:52 PM David Schinazi > wrote: > >> I support adoption and am willing to help review. >> >> In case anyone else finds it helpful, here's a diff from RFC 8446:

Re: [TLS] TLS 1.3 Problem?

The client is expected to adapt its behavior based on the negotiated version indicated in the ServerHello. If the server selects TLS 1.2, for example, then the client behaves as specified in RFC 5246. This is no different from previous version of TLS. --Richard On Sun, Sep 27, 2020 at 10:29 PM

Re: [TLS] Banning implicit CIDs in DTLS

I agree with EKR that this seems like the most expedient solution to the issue. --Richard On Thu, May 21, 2020 at 12:00 PM Christopher Wood wrote: > PR #148 in the DTLS 1.3 draft ( > https://github.com/tlswg/dtls13-spec/pull/148) proposes banning implicit > CIDs. This comes at an obvious cost

Re: [TLS] RFC8446 backward compatibility question

For example, the mint TLS 1.3 library only supports 1.3. https://github.com/bifurcation/mint On Thu, Aug 5, 2021 at 10:46 AM Nick Harper wrote: > Yes, backward compatibility is optional. > > On Thu, Aug 5, 2021 at 1:44 PM Toerless Eckert wrote: > >> I am trying to figure out if every

Re: [TLS] RFC8446 backward compatibility question

I’m not aware of any spec (at least in the IETF) that mandates support for prior versions. Are you? My point being that there is a pretty universal default assumption that no such requirement exists. No different for TLS, and thus no need to explain when that’s the case. —Richard On Thu, Aug

Re: [TLS] SSO Attacks in Browser

Just to be clear: * These "picture in picture" attacks have been around for years, as Ben points out. * WebAuthn is not vulnerable, because its assertions are bound to the origin, and a phishing site can't access the correct origin. * Anything that doesn't involve asymmetric cryptography will be

Re: [TLS] [EXTERNAL] Re: Servers sending CA names

On Mon, Apr 17, 2023 at 11:41 AM Robert Relyea wrote: > I know of no public CA which issues SSL client auth certs (or what it > would mean for a server to trust a public client auth cert). > Let's Encrypt issues roughly 3 million publicly trusted certificates per day that contain the client

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

+1 On Tue, Mar 28, 2023 at 10:15 PM Christopher Patton wrote: > I support this. Adding P256 + Kyber768 seems like a good idea. > > Chris P. > > On Wed, Mar 29, 2023 at 10:50 AM Christopher Wood > wrote: > >> As discussed during yesterday's meeting, we would like to assess >> consensus for

Re: [TLS] Resurrect AuthKEM?

Hi Uri, Just to be clear, the AuthKEM draft you mean is this one? https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/ Assuming that's the case, in case anyone else is confused (as I was), the "AuthKEM" here does not refer to a KEM implementing the AuthEncap/AuthDecap interface from