Just in case people hadn't seen this yet...
-Ben
On Wed, May 13, 2020 at 08:46:57AM -0700, The IESG wrote:
>
> The IESG has received a request from the Network File System Version 4 WG
> (nfsv4) to consider the following document: - 'Towards Remote Procedure Call
> Encryption By Default'
>as
On Thu, Feb 11, 2021 at 12:00:10PM -0800, uta-requ...@ietf.org wrote:
[...]
> 3. Requirements on cert naming
>
> RFC 7925 Sec. 4.4.2 says:
>
>For client certificates, the identifier used in the SubjectAltName or
>in the leftmost CN component of subject name MUST be an EUI-64.
>
> This l
On Thu, Jul 14, 2022 at 10:52:53AM +1000, Martin Thomson wrote:
>
>
> On Thu, Jul 14, 2022, at 10:20, Peter Saint-Andre wrote:
> > On 7/13/22 3:00 PM, Salz, Rich wrote:
> >> * It is definitely the "BCP" already--there are good reasons not to
> >> support TLS 1.2 on a server, and good reason
Hi Peter,
On Thu, Jul 14, 2022 at 03:34:03AM +, Peter Gutmann wrote:
> Rob Sayre writes:
>
> >I don't understand your rationale here, though.
>
> If you've got existing systems with implemented, tested, and in-production TLS
> 1.2 stacks then the motivation to do a completely new TLS stack
On Fri, Jul 15, 2022 at 10:30:55AM -0700, Rob Sayre wrote:
> On Fri, Jul 8, 2022 at 7:19 AM Cullen Jennings via Datatracker <
> nore...@ietf.org> wrote:
>
>
> > I see no evidence of any
> > discussion of how that will work out for things that use HTTP but are not
> > browsers.
> >
>
> There jus
On Mon, Aug 01, 2022 at 02:58:08PM -0600, Cullen Jennings wrote:
>
>
> > On Jul 30, 2022, at 1:40 PM, Peter Saint-Andre wrote:
> >
> > Hi again,
> >
> > The authors have conferred on this and at this time we don't think that we
> > can recommend anything other than EC ciphers, for several rea
Just a few things that I jotted down while reading this on the plane
(nothing major)...
In section 5, the text "most TLS stacks that support TLS 1.2 will fallback
to TLS 1.0 without alerting the client" is describing the normal TLS
version negotiation, not the "fallback dance" which DKG is going t
> Date: Sat, 22 Apr 2017 19:35:26 +0200
> From: Daniel Margolis
> To: uta@ietf.org
> Subject: Re: [Uta] back to smtp-sts-04
>
> On Thu, Apr 6, 2017 at 4:11 PM, Viktor Dukhovni
> wrote:
>
> >
> > Your JSON reference is to the obsolete RFC4627, the non-obsolete
> > reference is RFC7159.
> >
>
>
Benjamin Kaduk has entered the following ballot position for
draft-ietf-uta-smtp-tlsrpt-18: 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
Benjamin Kaduk has entered the following ballot position for
draft-ietf-uta-mta-sts-17: 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
On Wed, May 09, 2018 at 11:43:50AM -0700, Ned Freed wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-uta-mta-sts-17: No Objection
>
> > When responding, please keep the subject line intact and reply to all
> > email addresses incl
Benjamin Kaduk 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
On Thu, Feb 21, 2019 at 10:24:17AM +, Alexey Melnikov wrote:
> Hi Benjamin,
> A couple of comments on some of your DISCUSS points:
>
> > On 21 Feb 2019, at 04:55, Benjamin Kaduk wrote:
> >
> > I'm also concerned about the apparent new burden placed on sender
Hi Viktor,
Sorry for the slow response. It took me a while to mull over why exactly
this position felt incorrect to me.
On Thu, Feb 21, 2019 at 12:54:17AM -0500, Viktor Dukhovni wrote:
> > On Feb 20, 2019, at 11:55 PM, Benjamin Kaduk wrote:
> >
> > While I understand that
On Tue, Feb 26, 2019 at 03:26:05PM -0800, Jim Fenton wrote:
> On 2/21/19 8:55 PM, Benjamin Kaduk wrote:
> > --
> > DISCUSS:
> > --
> >
On Wed, Feb 27, 2019 at 07:09:33PM +, Salz, Rich wrote:
> I think Jim's explanation makes sense -- even if it's not required, you can
> still do best-effort -- and captures the desired semantics exactly right. I
> hope the SecAD's will clear that discuss item.
To be clear: I don't have a pa
On Wed, Feb 27, 2019 at 03:12:04PM -0500, Viktor Dukhovni wrote:
> On Wed, Feb 27, 2019 at 01:35:42PM -0600, Benjamin Kaduk wrote:
>
> > It seems like implicit in this stance is a belief that DANE and/or MTA-STS
> > as currently specified are flawed, in that they do not have a r
On Wed, Feb 27, 2019 at 03:27:00PM -0500, Viktor Dukhovni wrote:
> On Wed, Feb 27, 2019 at 02:11:38PM -0600, Benjamin Kaduk wrote:
>
> > > > I'm also unsure exactly how tightly nailed down the (non-DANE) TLS
> > > > certificate validation process is
On Thu, Feb 28, 2019 at 11:42:08AM -0500, Viktor Dukhovni wrote:
>
>
> > On Feb 28, 2019, at 11:01 AM, Barry Leiba wrote:
> >
> > I have to agree with EKR about it not completely being the sender's
> > decision, though for a rather different reason. I really doubt that
> > in the vast majority
On Thu, Feb 28, 2019 at 02:49:13PM -0800, Jim Fenton wrote:
> On 2/27/19 12:11 PM, Benjamin Kaduk wrote:
> > On Tue, Feb 26, 2019 at 03:26:05PM -0800, Jim Fenton wrote:
> >> On 2/21/19 8:55 PM, Be
[sorry about the broekn threading; I get uta@ in digest form and can't dig
out a proper message-id ATM from the archives]
On Wed, Mar 27, 2019 at 12:00:16PM -0700, uta-requ...@ietf.org wrote:
> Date: Wed, 27 Mar 2019 09:34:14 +0100
> From: Jim Fenton
> To: "uta@ietf.org"
> Subject: [Uta] Revised
On Tue, Jul 30, 2019 at 04:11:36PM -0700, Jim Fenton wrote:
> On 7/17/19 12:18 PM, Benjamin Kaduk via Datatracker wrote:
>
> > --
> > DISCUSS:
> > --
On Tue, Jul 30, 2019 at 09:19:40PM -0400, Viktor Dukhovni wrote:
> On Tue, Jul 30, 2019 at 07:02:23PM -0500, Benjamin Kaduk wrote:
>
> > > This work was inspired by a paper, "Neither Snow Nor Rain Nor MITM ...An
> > > Empirical Analysis of Email Delivery Securi
On Wed, Jul 31, 2019 at 05:08:42AM -0400, Viktor Dukhovni wrote:
> On Tue, Jul 30, 2019 at 11:16:25PM -0700, Jim Fenton wrote:
>
> > The RFC 7672 definition of Reference Identifier includes the CN-ID, so it
> > would be more consistent to include it when referencing 6125 as well.
>
> For the reco
On Wed, Jul 31, 2019 at 07:58:07PM -0400, Viktor Dukhovni wrote:
> On Jul 31, 2019, at 7:05 PM, Benjamin Kaduk wrote:
>
> > That seems likely; I don't feel a particular need to introduce skew between
> > reality and the text of the specification. I guess, if the WG wants,
Hi Jim,
On Fri, Aug 02, 2019 at 10:17:37AM -0700, Jim Fenton wrote:
> It seems we're fairly clear on what needs to go into the revision, except
>
> On 7/30/19 11:16 PM, Jim Fenton wrote:
> > On 7/30/19 5:02 PM, Benjamin Kaduk wrote:
> >> On Tue, Jul 30, 2019 at
On Fri, Aug 02, 2019 at 03:18:39PM -0700, Jim Fenton wrote:
> On 8/2/19 3:06 PM, Benjamin Kaduk via Datatracker wrote:
>
> > --
> > COMMENT:
> >
Reviewer: Benjamin Kaduk
Review result: Has Issues
I made a PR on github with some suggested fixes for essentially editorial
issues. Some more substantive comments below.
There seem to be a handful of instances where we restate essentially the
same normative requirement (e.g., "SHOULD NO
Reviewer: Benjamin Kaduk
Review result: Ready
I looked over the updates from -07 to -09, and they all look good.
I recognize that not all of my previous comments resulted in any text
changes, and appreciate that they were given consideration and the
conscious choice made to not act. I'd
Benjamin Kaduk has entered the following ballot position for
draft-ietf-uta-smtp-require-tls-08: 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
Benjamin Kaduk has entered the following ballot position for
draft-ietf-uta-smtp-require-tls-09: 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
Benjamin Kaduk has entered the following ballot position for
draft-ietf-uta-tls-for-email-04: Abstain
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
32 matches
Mail list logo
