On Mon, Apr 27, 2020 at 2:04 AM tom petch wrote:
> What is the point of rfc7525bis? Why do we need it?
>
> It seems to me that RFC7525 is a good set of recommendations and little
> has changed, in practical terms, since it was produced, although
> cryptanalysts can find weaknesses therein
>
> --
On Tue, Apr 28, 2020 at 1:41 AM tom petch wrote:
> One requirement that was raised in the later stages of the work on TLS 1.3
> related to audit, and was raised, I think, by representatives of the
> finance industry; the WG rejected the requirement.
It's worth noting that to the extent that thi
On Thu, Apr 30, 2020 at 7:59 PM Keith Moore
wrote:
> People do not always have the luxury of upgrading their clients and
> servers to versions that support the recent TLS.Some legacy hardware
> has firmware that cannot be upgraded because no upgrades are
> available. Service providers do no
On Fri, May 1, 2020 at 10:47 AM wrote:
> > IMO RFC7525 and this new draft both suffer from dubious assumptions and
> > make poor recommendations because of those assumptions. In particular,
> > there are many cases for which using an old version of TLS is suboptimal
> > and it shouldn't be consi
On Fri, May 1, 2020 at 4:43 PM Keith Moore
wrote:
> On 5/1/20 6:48 PM, Eric Rescorla wrote:
>
> On Thu, Apr 30, 2020 at 7:59 PM Keith Moore
> wrote:
>
>> People do not always have the luxury of upgrading their clients and
>> servers to versions that support the
On Sat, May 2, 2020 at 10:26 PM Peter Gutmann
wrote:
> Eric Rescorla writes:
>
> >if you are running a piece of hardware that cannot upgrade its TLS stack
> at
> >all, you quite likely have a number of serious unpatched vulnerabilities,
> and
> >should reconsider w
> On Tue, Apr 28, 2020 at 1:41 AM tom petch wrote:
> It's worth noting that to the extent that this is a requirement, it is
> already violated by any installation which is compliant with RFC
> 7525. The auditing techniques in question depend un using static RSA
> cipher suites, but 7525
> https:/
I am in favor of adoption
On Sat, May 9, 2020 at 8:50 AM Valery Smyslov
wrote:
> Hi,
>
> the chairs encourage WG members to more actively participate in the call.
> At the meeting a lot of participants expressed a favor of adoption,
> we ask these participants to reconfirm their position on the
I am in favor of adoption and am willing to review.
I note that this requires CCM8. ISTM that the analysis of this we just
landed in DTLS should call this into question.
-Ekr
On Fri, May 15, 2020 at 12:54 AM Valery Smyslov wrote:
> Hi,
>
> during the last virtual interim meeting the
> draft-
On Wed, Jan 19, 2022 at 6:57 AM Yaron Sheffer wrote:
> 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 th
This discussion seems kind of out of scope for 7525-bis, which is about how
to use TLS, but doesn't seem to say much of anything in terms of how to
operate a CA.
The current draft seems not to say anything about what clients ought to do
and to say that servers SHOULD support OCSP and OCSP stapling
Hi David,
This question seems a bit out of scope for TLS, which is kind of
indifferent to the transport interaction.
Perhaps it might make sense to be in UTA, though unfortunately, RFC
7525-bis is in the editor queue now...
-Ekr
On Mon, Nov 7, 2022 at 1:37 AM David Barr wrote:
> How can I ma
This LGTM.
On Fri, Feb 20, 2015 at 8:23 AM, Richard Barnes wrote:
>
>
> On Fri, Feb 20, 2015 at 9:42 AM, Peter Saint-Andre - &yet <
> pe...@andyet.net> wrote:
>
>> On 2/20/15 3:45 AM, Ralph Holz wrote:
>>
>>> Hi Viktor,
>>>
>>> Basically, I'm fine with "raising the ceiling" as high as it se
On Thu, Apr 14, 2016 at 10:38 PM, Jim Fenton wrote:
> On 4/13/16 10:43 AM, Chris Newman wrote:
>
> DANE is merely one method of validating a certificate, there can also be
> SMTP policy orthogonal to DANE. Take for example, DEEP’s “tls11” and
> “tls12” directives. Those specify a minimum acceptab
Eric Rescorla has entered the following ballot position for
draft-ietf-uta-email-deep-09: 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
introductory paragraph, however.)
Please refer to https
On Tue, Oct 24, 2017 at 5:31 PM, Keith Moore
wrote:
> (inline)
>
> Line 186
>> TLS, and to encourage a greater consistency for how TLS is used, this
>> specification now recommends use of Implicit TLS for POP, IMAP, SMTP
>> Submission, and all other protocols used between a Mail User
On Thu, Oct 26, 2017 at 7:56 PM, Keith Moore
wrote:
> On 10/26/2017 07:18 PM, Chris Newman wrote:
>
> Line 304
>preference to services supporting STARTTLS (if offered). (See
>also Section 4.5.)
> I note that 6186 is kind of unclear on what should go in SNI. It obviously
> needs t
AM, Keith Moore
wrote:
>
> > On Oct 27, 2017, at 7:48 AM, Eric Rescorla wrote:
> >
> > The entire principle here is that (absent DNSSEC) TLS operates on what
> was fed into the client.
>
> Could you elaborate a bit? I feel like I'
On Fri, Oct 27, 2017 at 11:03 AM, Chris Newman
wrote:
> On 26 Oct 2017, at 19:56, Keith Moore wrote:
>
>> On 10/26/2017 07:18 PM, Chris Newman wrote:
>>
>> Line 304
>preference to services supporting STARTTLS (if offered). (See
>also Section 4.5.)
> I note that 6186 i
Yeah, this doesn't seem like an actually secure set of practices, which is
why we don't do it for HTTPS even when there are CNAMEs.
-Ekr
On Fri, Oct 27, 2017 at 12:20 PM, Viktor Dukhovni
wrote:
>
>
> > On Oct 27, 2017, at 2:34 PM, Eric Rescorla wrote:
> >
>
Eric Rescorla has entered the following ballot position for
draft-ietf-uta-mta-sts-17: Discuss
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
introductory paragraph, however.)
Please refer to https
On Thu, May 3, 2018 at 10:19 PM, Viktor Dukhovni
wrote:
> On Thu, May 03, 2018 at 06:14:44PM -0700, Eric Rescorla wrote:
>
> > S 10.2.
> > > mode, to allow clean MTA-STS removal, as described in Section
> 8.3.)
> > >
> > > Resistance to do
On Fri, May 4, 2018 at 7:41 AM, Viktor Dukhovni
wrote:
> [ Re-ordered for clarity. Hope the below adds some context. ]
>
> > On May 4, 2018, at 8:11 AM, Eric Rescorla wrote:
> >
> > Preemptive removal of non-matching MX hosts is liable (in sloppy
> > implementati
Eric Rescorla has entered the following ballot position for
draft-ietf-uta-mta-sts-19: No Objection
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
introductory paragraph, however.)
Please refer to
Eric Rescorla has entered the following ballot position for
draft-ietf-uta-smtp-require-tls-07: Discuss
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
introductory paragraph, however.)
Please refer to
On Thu, Feb 21, 2019 at 10:37 AM Viktor Dukhovni
wrote:
> > On Feb 21, 2019, at 10:07 AM, Eric Rescorla wrote:
> >
> > To elaborate on one point a bit: it seems to me that it's harmful to
> > security to allow the sender to unilaterally override the recipient's
On Thu, Feb 21, 2019 at 12:43 PM Viktor Dukhovni
wrote:
> On Thu, Feb 21, 2019 at 12:22:32PM -0800, Eric Rescorla wrote:
>
> > > A recipient has no expectation that the sending MTA supports any of
> > > DANE, MTA-STS, REQUIRETLS, or even STARTTLS.
> >
> > Nor
On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton wrote:
> On 2/21/19 7:07 AM, Eric Rescorla wrote:
> > --
> > DISCUSS:
> > --
> >
>
On Thu, Feb 28, 2019 at 9:33 AM Jim Fenton wrote:
> On 2/27/19 2:10 PM, Eric Rescorla wrote:
>
>
>
> On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton wrote:
>
>> On 2/21/19 7:07 AM, Eric Rescorla wrote:
>> > --
On Thu, Feb 28, 2019 at 10:36 AM Viktor Dukhovni
wrote:
> On Thu, Feb 28, 2019 at 09:42:31AM -0800, Eric Rescorla wrote:
>
> > > The preferences we're talking about here (MTA-STS and DANE) are
> basically
> > > advertisements saying, "if you send mail to this
On Tue, Mar 12, 2019 at 7:10 PM Viktor Dukhovni
wrote:
> > On Mar 12, 2019, at 8:01 PM, Eric Rescorla wrote:
> >
> > I'm sorry, but I don't see how any of this is meaningfully different
> from the
> > situation with HSTS. In both cases, the receiving system
On Wed, Mar 13, 2019 at 1:59 PM Alexey Melnikov
wrote:
> Hi Ekr,
>
> On Thu, Feb 21, 2019, at 3:07 PM, Eric Rescorla wrote:
>
> >
On Wed, Mar 13, 2019 at 2:49 PM Viktor Dukhovni
wrote:
> > On Mar 13, 2019, at 5:13 PM, Eric Rescorla wrote:
> >
> > Well, I think this field should only override the outgoing and not
> incoming policies (or be removed).
>
> To be clear, let's imagine a company
utton in the MUA UI?
On Wed, Mar 13, 2019 at 2:55 PM Eric Rescorla wrote:
>
>
> On Wed, Mar 13, 2019 at 2:49 PM Viktor Dukhovni
> wrote:
>
>> > On Mar 13, 2019, at 5:13 PM, Eric Rescorla wrote:
>> >
>> > Well, I think this field should only override the
On Thu, Mar 14, 2019 at 9:38 AM Viktor Dukhovni wrote:
> > On Mar 14, 2019, at 11:53 AM, Eric Rescorla wrote:
> >
> > We had a bunch more discussion on this on the IESG call. It seems like
> > the primary use case for TLS-Required=no may be to exempt what's
> b
On Thu, Mar 14, 2019 at 10:27 AM Nico Williams
wrote:
> | 4. Policy Validation
> |
> |When sending to an MX at a domain for which the sender has a valid
> |and non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS MUST
>^^^
On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson
wrote:
>
> Please note and respect the Reply-To: uta@ietf.org.
>
>
4. Find a sensible way to extend RFC6066 to accomodote other forms of SNI.
> There isn't an IANA registry for this.
>
Just as a technical matter, it's not really possible to ext
9:31 PM Watson Ladd wrote:
>
> On Mon, Jan 6, 2025 at 6:14 PM Eric Rescorla wrote:
> >
> >
> >
> > On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson <
> mcr+i...@sandelman.ca> wrote:
> >>
> >>
> >> Please note and respect the R
On Mon, Jan 6, 2025 at 9:31 PM Watson Ladd wrote:
> On Mon, Jan 6, 2025 at 6:14 PM Eric Rescorla wrote:
> >
> >
> >
> > On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson <
> mcr+i...@sandelman.ca> wrote:
> >>
> >>
> >> Please not
On Thu, Feb 20, 2025 at 4:39 PM Geoff Huston wrote:
>
>
> On 21 Feb 2025, at 11:17 am, Eric Rescorla via dnsdir
> wrote:
>
>
>
> On Thu, Feb 20, 2025 at 3:55 PM Geoff Huston via Datatracker <
> nore...@ietf.org> wrote:
>
>> Reviewer: Geoff Huston
>
On Thu, Feb 20, 2025 at 3:55 PM Geoff Huston via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Geoff Huston
> Review result: Ready with Nits
>
> I was assigned as the dnsdir reviewer for draft-ietf-uta-require-tls13-05.
> For more information about the DNS Directorate, please see
> https://wi
On Fri, Feb 21, 2025 at 11:07 PM Geoff Huston wrote:
> So if the sense of the advice in section 3 refers to the use of a crypto
> exchange to protect the privacy of the subsequent session then the key
> consideration is: "What is the period over which you think that such
> privacy protection ios
On Tue, Apr 8, 2025 at 9:06 AM Toerless Eckert wrote:
> Dear IESG, *:
>
> We received IESG review for draft-ietf-anima-brski-prm that was asking to
> make the use of TLS 1.3 mandatory based on the expectation that
> draft-ietf-uta-require-tls13
> would become RFC - unless we provide sufficient ju
On Wed, Apr 9, 2025 at 7:35 PM Toerless Eckert wrote:
> On Tue, Apr 08, 2025 at 11:23:44AM -0700, Eric Rescorla wrote:
> > I don't agree that this change is indicated. TLS 1.3 is far more
> widespread
> > than just in browsers. It's been in major libraries for years
> On Wed, Apr 09, 2025 at 07:51:59PM -0700, Eric Rescorla wrote:
> > Perhaps not, but that's not what I am saying. Rather, the point I am
> > making is that your proposed text limiting this to *browsers* is far
too narrow and the
> > original text that says TLS 1.3 is
On Thu, Apr 10, 2025 at 11:41 AM Jared Mauch wrote:
> On Tue, Apr 08, 2025 at 06:05:22PM +0200, Toerless Eckert wrote:
> > Dear IESG, *:
> >
> > We received IESG review for draft-ietf-anima-brski-prm that was asking to
> > make the use of TLS 1.3 mandatory based on the expectation that
> draft-ie
On Thu, Apr 10, 2025 at 11:59 AM Eric Rescorla wrote:
>
>
> On Thu, Apr 10, 2025 at 11:41 AM Jared Mauch
> wrote:
>
>> On Tue, Apr 08, 2025 at 06:05:22PM +0200, Toerless Eckert wrote:
>> > Dear IESG, *:
>> >
>> > We received IESG review for
On Thu, Apr 10, 2025 at 6:59 AM Michael Richardson
wrote:
>
> Peter Gutmann wrote:
> >> Or, you can write new application level code, but the base embedded
> system,
> >> which contains TLS as part of the SDK, can not be upgraded without
> a new
> >> review.
>
> > That's what I u
On Thu, Apr 10, 2025 at 6:54 AM Michael Richardson wrote:
> Peter Gutmann wrote:
> > Some sort of qualification like that would be my preference as
> well. I don't
> > think I've ever encountered TLS 1.3 in SCADA (I mean, there's still
> a lot of
> > TLS 1.0 out there that people ar
49 matches
Mail list logo
