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
My original mail had some 15 comments, some trivial, some not. Do you
expect 15 PRs?
Thanks,
Yaron
On 08/17/2015 10:37 AM, Martin Thomson wrote:
On 17 August 2015 at 05:02, Ilari Liusvaara wrote:
Actually, I think both should be 256 (256-byte expansion from AEAD
is already quite muc
,
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
A new version of I-D, draft-sheffer-tls-pinning-ticket-01.txt
has been
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 “oldversio
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 no
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? Bas
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 th
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
onger 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,
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 ta
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
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
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% of
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,
Y
ber 4, 2019 at 04:49
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?
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 continu
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
On 02/06/16 18:16, David Benjamin wrote:
On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni mailto:ietf-d...@dukhovni.org>> wrote:
> On Jun 2, 2016, at 10:49 AM, David Benjamin
mailto:david...@chromium.org>> wrote:
>
> I'm not sure I follow. The specification certainly spells
.txt
Date: Fri, 08 Jul 2016 06:42:25 -0700
From: internet-dra...@ietf.org
To: Yaron Sheffer
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-sheffer-tls-pinning-ticket
Revision
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 Con
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 , Daniel Migault
A new version of I-D, draft-sheffer-tls-pinning-ticket-03.txt
has been successfully submitted by Yaron Sheffer
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 red
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?
Th
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 avoid
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
signature
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
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 reli
Dear TLS WG, There will be a side meeting on Attested TLS tomorrow morning, Thursday 9:00-10:00 at the Prince of Wales room. The target audience is the TLS community, so please join us whether you are big fans of attestation or you think that attestation is a Bad Thing. Thanks, Hann
-1. The TLS working group, and this document in particular, has consistently ignored the products of the UTA working group. Specifically, RFC 9325 [1] published a mere two years ago is not even referenced in the draft, let alone a comparison made with these deployment recommendations that were made
This guidance document already exists: https://datatracker.ietf.org/doc/html/rfc9325 Thanks, Yaron On 26/11/2024, 22:58, "David A. Cooper" wrote:For me, the question of TLS-LTS or TLS 1.3. If TLS-LTS is a bug fix, then what bugs does it fix that can not be fixed without defining a n
I honestly think it is not, given the context – not until you read the IANA section. I would suggest: no changes (including any extensions). On 10/12/2024, 17:18, "Salz, Rich" wrote:English is hard. :). I think "no new features" is clear, given the context of the words around it. I could change it
Looks good. Thanks! From: Salz, Rich Date: Tuesday, 10 December 2024 at 18:41To: Yaron Sheffer , Alicja Kario Cc: TLS List Subject: Re: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature FreezejQcmQRYFpfptBannerEndFor the second paragraph, I would prefer “no changes and no new extension
For the second paragraph, I would prefer “no changes and no new extension values”. I don’t have a better idea for the title, so even if I think it’s not 100% precise, I’m good with keeping it. From: Salz, Rich Date: Tuesday, 10 December 2024 at 17:45To: Yaron Sheffer , Alicja Kario Cc: TLS List
I think the draft is confusing to the point of almost being misleading, in particular with its use of the word “feature”. Based on the words “feature freeze” people on this list have interpreted it as merely “the TLS WG will no longer work on TLS 1.2”. But by blocking IANA registrations, this has m
Hi Peter, Just to put matters straight, the predecessor of RFC 9325, RFC 7525, was published in May 2015. But that doesn’t matter a whole lot now. My point was much broader though: the IETF is sending deployers a bunch of mixed messages, and this is on us as a community. RFC 9325 basically tells th
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, wit
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
CertificateRe
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
act
38 matches
Mail list logo
