Re: [TLS] consensus call: deprecate all FFDHE cipher suites

Yes, this is clear to people on this thread. My comment was just about the document, which IMO should define its scope more clearly and early on. Thanks,     Yaron From: David Benjamin Date: Saturday, 17 December 2022 at 19:25 To: Yaron Sheffer Cc: Carrick Bartle , TLS

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

Hi Carrick, While this is clear to the authors, it is not very clear in the document. Even though the document only applies to TLS 1.2, TLS 1.2 (the version number) is not mentioned in the doc title, in the abstract or in the introduction. Thanks,     Yaron From: TLS on

Re: [TLS] [Uta] Question regarding RFC 8446

Hi Paul, I'm actually not sure this is a good idea, and not because we are at the RFC Editor. TLS has intentionally kept this aspect out of scope basically forever. The following text appears in TLS 1.0 (Jan. 1999) and still appears unchanged in TLS 1.3: "No part of this standard should be

Re: [TLS] OCSP in RFC7525bis - summary of the discussion

recommended. There was some back and forth about DNSSEC, short-lived certs, CAA and CT as mitigating controls, but we don't see them as clearly in scope of the document. Thanks, Yaron [1] https://github.com/yaronf/I-D/pull/279/files --- From: Yaron Sheffer Date: Wednesday, January 19

Re: [TLS] OCSP in RFC7525bis

, but with caveats. It’s been more than 6 years since the RFC was published, and we are reviewing our recommendations, which may or may not still be valid. Thanks,    Yaron From: Hannes Tschofenig Date: Thursday, January 20, 2022 at 12:00To: Yaron Sheffer , u...@ietf.org , tls@ietf.org Subject: RE

[TLS] OCSP in RFC7525bis

Hi, RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use OCSP and OCSP stapling. We are changing these recommendations [2] in view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961. But this raises a larger question: many client-side implementations soft-fail if

Re: [TLS] [EXTERNAL] Re: supported_versions in TLS 1.2

On 11/29/21, 22:40, "Peter Saint-Andre" wrote:On 11/29/21 11:29 AM, Andrei Popov wrote:> Perhaps I missed some part of this thread, but it’s still not clear to > me what would be the purpose of adding supported_versions extension to a > TLS 1.2 implementation? What problem(s) would that solve? 

Re: [TLS] Secdir telechat review of draft-ietf-tls-exported-authenticator-14

Ben On Fri, Apr 02, 2021 at 09:05:38AM -0700, Yaron Sheffer via Datatracker wrote: > Reviewer: Yaron Sheffer > Review result: Has Issues > > After a bit of back and forth over my *two* previous SecDir requests, I'm > afraid that my original comment has not yet

[TLS] Secdir telechat review of draft-ietf-tls-exported-authenticator-14

Reviewer: Yaron Sheffer Review result: Has Issues After a bit of back and forth over my *two* previous SecDir requests, I'm afraid that my original comment has not yet been fully addressed. The IANA considerations section (Sec. 8.1) adds server_name as a possible extension for CertificateRequest

[TLS] Obsoleting SCSV in draft-ietf-tls-oldversions-deprecate

Hi, We are now revising RFC 7525 for the new world, and in general we are following this draft. So, MUST NOT negotiate TLS 1.0 and 1.1. This brought up the question of SCSV, which was new when RFC 7525 was published but has since been widely implemented/deployed. I think marking the

[TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-13

Reviewer: Yaron Sheffer Review result: Has Nits It's been a long time... My mail here [1] mentions two remaining open issues: a mention of QUIC and the code point. The first (small) issue seems to have been forgotten. I believe the second issue has been addressed by the WG

Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

To: Yaron Sheffer Cc: , , , "" Subject: Re: Secdir last call review of draft-ietf-tls-exported-authenticator-09 Following up, Yaron, do the responses by myself and Benjamin along with the does the following PR sufficiently address your comments/concerns? https://github.com

[TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

Reviewer: Yaron Sheffer Review result: Has Issues The document is generally clear in both its motivation and the proposed solution. I think it's playing a bit too liberal with TLS 1.3, in sort-of but not quite deprecating renegotiation, and in changing the IANA registry in a way that actually

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

I strongly support this work. Also, having made this mistake myself in the past: please make sure that we have one fully specified PAKE in this document, and not only a generic envelope. This will ensure that TLS libraries have at least one working, and interoperable, PAKE, Thanks,

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

I'd encourage you to try get people to be open about things here - there's no particular shame in having 10% TLSv1.0 sessions after all:-) It isn't a question of shame but it is just a bit too much information to provide a potential adversary. That is, to say that Stock Exchange XYZ has n%

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

On 18/07/17 18:34, Watson Ladd wrote: I understand the logics but, since LURK boxes don’t scale, the cost to cover your entire footprint for the sporadic cases when the CA is down might be a bit prohibitive. CA reliability is not good. From my own experience, I agree that CA

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

Hi Stephen, Like you, I am very unhappy with this draft, and would not support its adoption as a WG draft. However I think that open discussion is in general good, and that the best venue for discussion of this draft is this mailing list. Even if some of this discussion devolves into generic

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

I’m not even sure what my position is on this. Specifying the use of a context here goes against the recommendation in the CFRG draft: Contexts SHOULD NOT be used opportunistically, as that kind of use is very error-prone. If contexts are used, one SHOULD require all

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

So the key schedule changed and therefore we think cross-version attacks are impossible. Have we also analyzed other protocols to ensure that cross protocol attacks, e.g. with SSH or IPsec, are out of the question? Put differently, algorithm designers gave us a cheap, easy to use tool to

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

Hi Rich, I am confused by your response. For those who missed CURDLE, could you please briefly explain why we don't need signature context in non-TLS areas. And even if this is the case, the current thread is about TLS! So why are we now saying that contexts are not needed even for TLS?

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

I have not read the document in full (but still noticed a typo in the paragraph we're discussing), so I will not comment on its readiness. Regarding signature context: I don't understand the CFRG recommendation that Yoav is citing. IMO we should include a context string wherever we can, to

[TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-03.txt

Subject: New Version Notification for draft-sheffer-tls-pinning-ticket-03.txt Date: Tue, 04 Oct 2016 03:00:10 -0700 From: internet-dra...@ietf.org To: Yaron Sheffer <yaronf.i...@gmail.com>, Daniel Migault <daniel.miga...@ericsson.com> A new version of I-D, draft-sheffer-tls-pinning-t

Re: [TLS] Industry Concerns about TLS 1.3

What exactly is the problem you are concerned with? As I've pointed out previously one can still log the contents of TLS protected connections: you do this at the client, or with an intercepting proxy. What information does this not get you that you need on the network? For enterprises using

[TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-02.txt

.txt Date: Fri, 08 Jul 2016 06:42:25 -0700 From: internet-dra...@ietf.org To: Yaron Sheffer <yaronf.i...@gmail.com> A new version of I-D, draft-sheffer-tls-pinning-ticket-02.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-sheff

Re: [TLS] Downgrade protection, fallbacks, and server time

On 02/06/16 18:16, David Benjamin wrote: On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni > wrote: > On Jun 2, 2016, at 10:49 AM, David Benjamin > wrote: > > I'm not

Re: [TLS] PR #493: Multiple concurrent tickets

Hi EKR, This is confusing: on the one hand you encourage clients to use multiple tickets when available, "to the extent possible use a different one for each new connection", and on the other hand you say that a simple way to follow the Generation policy is to keep only the latest ticket, and

Re: [TLS] Issue 471: Relax requirement to invalidate sessions on fatal errors

This still makes the *stateful* implementation much more deterministic and those implementations are common enough. So how about: Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may

[TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-01.txt

, Yaron Forwarded Message Subject: New Version Notification for draft-sheffer-tls-pinning-ticket-01.txt Date: Sat, 06 Feb 2016 12:25:54 -0800 From: internet-dra...@ietf.org To: Yaron Sheffer <yaronf.i...@gmail.com> A new version of I-D, draft-sheffer-tls-p

[TLS] TLS 1.3 comments

Below a long list of comments, generally minor. The document is already very good - we're making great progress! The record length field is limited by encrypted-length+2048. Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an expansion of greater