Re: [Uta] [Technical Errata Reported] RFC8689 (7705)

Viktor Dukhovni and I have been corresponding with the originator of this erratum, and I believe that this report should be verified. The last sentence in the notes (about unusable TLSA records) should probably be removed because it refers to a situation where DANE would not verify

Re: [Uta] Wildcards

On 12 Jul 2021, at 14:27, Salz, Rich wrote: * that further validation happens outside (before, after, or in parallel to) RFC 6125 processing. It seems like it would be worthwhile for us to mention that in the beginning. Part of my problem is that I don’t know what the boundaries of RFC

Re: [Uta] Wildcards

On 8 Jul 2021, at 7:12, Salz, Rich wrote: > I’d like to know what the WG thinks. As we’re not really using GitHub for > discussion, please comment on this list. I made a comment on the pull request that is beyond editorial, so I’d like to bring that back to the list. Section 6.4.3 begins

Re: [Uta] Wildcards

On 8 Jul 2021, at 7:12, Salz, Rich wrote: > A discussion started on the GitHub repo > https://github.com/richsalz/draft-ietf-uta-rfc6125bis about what is allowed > for the wildcard character, such as in DNS entries in subjectAltName. I am > about to publish a new draft which takes the old

Re: [Uta] How should we change draft-ietf-use-san?

I’m probably joining in the middle of this conversation, but please be patient with me: On 19 Apr 2021, at 10:48, Eliot Lear wrote: Hi Rich, A few of us just had this discussion in another context. Try this: CAs MUST populate a SAN. Verifiers MUST use a SAN if present. Verifiers MUST

Re: [Uta] Benjamin Kaduk's No Objection on draft-ietf-uta-smtp-require-tls-09: (with COMMENT)

On 8/2/19 3:06 PM, Benjamin Kaduk via Datatracker wrote: > -- > COMMENT: > -- > > Thank you for resolving my Discuss points! > > I do think the added text in

Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-08: (with DISCUSS and COMMENT)

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 04:11:36PM -0700, Jim Fenton wrote: >>> On 7/17/19 12:18 PM, Benjamin Kaduk via

Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-08: (with DISCUSS and COMMENT)

On 7/30/19 5:02 PM, Benjamin Kaduk wrote: 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: The following paragraph (unchanged from my ballot on -07) received only minimal discussion so far: I'm also concerned about

Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-08: (with DISCUSS and COMMENT)

On 7/17/19 12:18 PM, Benjamin Kaduk via Datatracker wrote: > -- > DISCUSS: > -- > > I'm glad that we were able to come to consensus to rename the header > field

Re: [Uta] RequireTLS: Revised text on message origination

Hi Rolf, On 4/15/19 2:06 PM, Rolf E. Sonneveld wrote: > Hi, Jim, > > On 12-04-19 21:44, Jim Fenton wrote: >> >> One of the significant discussions at the Prague meeting (and >> originally resulting from IESG comments) was that the Section 6, >> "Mailing list

[Uta] RequireTLS: Revised text on message origination

One of the significant discussions at the Prague meeting (and originally resulting from IESG comments) was that the Section 6, "Mailing list considerations" was incomplete because it didn't consider other causes of origination such as Sieve and vacation programs. So I have drafted an alternative

Re: [Uta] Revised wording on security consideration re TLS-Required

On 3/30/19 7:44 PM, Benjamin Kaduk wrote: > > This doesn't really say anything about or give guidance to intermediate > MTAs. (Do we want to differentiate between initial and intermediate MTAs, > too?) Part of the reason for using the term "client MTA" is that it's inclusive of initial and

Re: [Uta] Revised wording on security consideration re TLS-Required

of the reports. > >   > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > >   > > *From:*Jim Fenton > *Sent:* Thursday, March 28, 2019 9:57 AM > *To:* Brotman, Alexander ; > uta@ietf.org > *Subjec

Re: [Uta] Revised wording on security consideration re TLS-Required

e > be a reference to TLSRPT?  Either not to be counted or to explain the > lack of TLS based on “TLS-Required: no” being set? > >   > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > >   > > *From:*Uta *On Behalf

[Uta] Revised wording on security consideration re TLS-Required

Thanks for the feedback on my proposed language for a new security consideration regarding conflicts between the TLS-Required header field and DANE and MTA-STS recipient policies. Here's another stab at it: = 8.4. Policy Conflicts In some cases, the use of the TLS-Required header field may

Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

Picking a somewhat arbitrary place to join this discussion... On 3/14/19 9:43 AM, Eric Rescorla wrote: > > Well, my point is that this use case is in direct conflict with the plain > text of the semantics of MTA-STS. > IMO, characterizing MTA-STS and DANE as policy mechanisms is confusing. If it

Re: [Uta] Secdir last call review of draft-ietf-uta-smtp-require-tls-07

On 2/22/19 10:43 AM, Yaron Sheffer wrote: > Reviewer: Yaron Sheffer > Review result: Has Nits > > [Apologies for the late review.] [And for the late response.] > > * Intro: To avoid confusion, please mention the header parameter "No" to > clarify why the header is named RequireTLS when its

Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

On 2/28/19 4:08 PM, Viktor Dukhovni wrote: >> On Feb 27, 2019, at 5:00 PM, Spencer Dawkins at IETF >> wrote: >> >> Not my ballot thread, but "TLS Required: no" is a LOT clearer to me. I'm not >> the target audience, but the original order screws me up every time I see it >> in a ballot e-mail.

Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

On 2/28/19 8:28 AM, John Levine wrote: > In article > you > write: >> system requiring TLS for that message. My experience with working in >> organizations that use such markings is that they overuse them: the >> sending human doesn't actually determine the sensitivity; rather, the >> sending

Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

On 2/28/19 9:42 AM, Eric Rescorla wrote: > > > On Thu, Feb 28, 2019 at 9:33 AM Jim Fenton <mailto:fen...@bluepopcorn.net>> wrote: > > On 2/27/19 2:10 PM, Eric Rescorla wrote: >> >> >> On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton &g

Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

On 2/28/19 8:01 AM, Barry Leiba 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 preferences that something be encrypted. To forestall one argument, yes, the sender knows the

Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

On 2/27/19 2:10 PM, Eric Rescorla wrote: > > > On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton <mailto:fen...@bluepopcorn.net>> wrote: > > On 2/21/19 7:07 AM, Eric Rescorla wrote: > > > -

Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

On 2/27/19 3:45 PM, Viktor Dukhovni wrote: > On Tue, Feb 26, 2019 at 03:26:05PM -0800, Jim Fenton wrote: > >>>If a REQUIRETLS message is bounced, the server MUST behave as if >>>RET=HDRS was present as described in [RFC3461]. If both RET=FULL and >>>

Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

On 2/21/19 7:07 AM, Eric Rescorla wrote: > -- > DISCUSS: > -- > > I support Benjamin's DISCUSS. > > To elaborate on one point a bit: it seems to me that it's

Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

On 2/21/19 8:55 PM, Benjamin Kaduk wrote: > -- > DISCUSS: > -- > > I'm pretty sad to see that the "RequireTLS: no" header field has the > name "require TLS" and

Re: [Uta] Alissa Cooper's No Objection on draft-ietf-uta-smtp-require-tls-07: (with COMMENT)

On 2/21/19 6:07 AM, Alissa Cooper wrote: > -- > COMMENT: > -- > > I support Benjamin's first three DISCUSS points. > > I feel like there are some fairly

Re: [Uta] Ben Campbell's Yes on draft-ietf-uta-smtp-require-tls-07: (with COMMENT)

On 2/21/19 7:50 PM, Ben Campbell wrote: > -- > COMMENT: > -- > > Thanks for this. I am balloting "yes", but I have a couple of questions. (The > first would

Re: [Uta] Adam Roach's Yes on draft-ietf-uta-smtp-require-tls-07: (with COMMENT)

On 2/20/19 11:14 PM, Adam Roach wrote: > -- > COMMENT: > -- > > Thanks for the work everyone did on this specification. I'm happy to see the > state-of-the-art

Re: [Uta] Last Call: (SMTP Require TLS Option) to Proposed Standard

On 1/27/19 2:32 AM, Stephan Bosch wrote: Op 27/01/2019 om 06:13 schreef Jim Fenton: The draft discusses situations where intermediaries (relays) might generate bounce messages and the like, but doesn't deal with what are effectively reply messages back to the originator of the message

Re: [Uta] Last Call: (SMTP Require TLS Option) to Proposed Standard

Hi Russ, On 1/26/19 7:27 AM, Russ Housley wrote: > I have no problem with the protocol itself, but I do not understand how this > specification can not have a reference to TLS. It does have at least a couple of indirect references to TLS, through STARTTLS (RFC 3207) and BCP 195. An informative

Re: [Uta] Last Call: (SMTP Require TLS Option) to Proposed Standard

Thanks for the review, Stephan. On 1/25/19 1:58 PM, Stephan Bosch wrote: > > I just quickly reviewed this document. I notice that this extension > also applies to LMTP. Now, I wonder what should happen when Sieve [RFC > 5228] is involved there, particularly when actions like "redirect", >

Re: [Uta] AD review of draft-ietf-uta-smtp-require-tls-06

Thanks for your review, Alexey. Responses and a few clarifying questions below. On 1/9/19 8:34 AM, Alexey Melnikov wrote: > Hi, > > Sorry for the delay in reviewing this. I reviewed it in 2018, but > needed to work on expanding/decoding my notes so that they become > useful for other readers. > >

Re: [Uta] MTA-STS with lots of domains

On 1/8/19 12:59 PM, John R Levine wrote: > Adding to the excitement, every domain has its own name for the mail > server, e.g., for foo.com the mail server name is mx1.foo.com, all > pointing at the same IP address.  (This is not unusual; Tucows > hostedemail does the same thing with much longer

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

On 1/7/19 12:33 PM, Franck Martin wrote: It took years to deprecate RC4. DKIM still uses outdated cyphers, and there are no new ones approved (yet) AFAIK. See RFC 8463. -Jim ___ Uta mailing list Uta@ietf.org

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

On 1/5/19 7:05 PM, Alice Wonder wrote: > Well since SMTP is point to point, if you depend upon encryption you > need S/MIME or PGP and always will. Yes, and remember that S/MIME and PGP only encrypt the message body. There's still quite a bit of information in the message header and SMTP

Re: [Uta] Wrapping up draft-ietf-uta-smtp-require-tls-05

OK; shall I do an update or wait for more comments? -Jim On 12/4/18 7:11 AM, Alexey Melnikov wrote: > Hi Valery, > > On 04/12/2018 15:00, Valery Smyslov wrote: >> Hi, >> >> while preparing shepherd write-up for the draft I came across >> one issue. IANA Considerations section contains the

Re: [Uta] Adoption call for draft-lvelvindron-tls-for-email-02

I support the adoption of this; seems pretty straightforward. But isn't it possible to point specifications like RFC 8314 to a BCP somewhere so that we don't need to revise everything that references TLS whenever there is a version update? Seems like a lot of unnecessary work. If 8314 is

Re: [Uta] REQUIRETLS and MX spoofing

le authn mechanisms. On Tue, Oct 23, 2018 at 11:09 PM Viktor Dukhovni mailto:ietf-d...@dukhovni.org>> wrote: > On Oct 23, 2018, at 5:05 PM, Jim Fenton mailto:fen...@bluepopcorn.net>> wrote: > >> And yet, my preference would have been to not take this ap

Re: [Uta] REQUIRETLS and MX spoofing

On 10/22/18 3:02 PM, Viktor Dukhovni wrote: On Mon, Oct 22, 2018 at 11:46:27AM +0200, Daniel Margolis wrote: Close, but this conflates two issues: (1) making sure that the MX record hasn't been forged (which MTA-STS or DNSSEC in the mailbox domain will do) and authenticating the mail server

Re: [Uta] REQUIRETLS and MX spoofing

Thanks for your response, Dan. Comments inline. On 10/19/18 10:40 AM, Daniel Margolis wrote: Hey Jim, I've been too busy to follow along on REQUIRETLS closely, unfortunately, so I may be missing some context. Feel free to ignore: One caveat on your last statement is that, /alone/, you

[Uta] REQUIRETLS and MX spoofing

On 8/23/18 6:49 PM, Viktor Dukhovni wrote: This is recognized in the Security Considerations: Another active attack involves the spoofing of DNS MX records of the recipient domain. An attacker having this capability could cause the message to be redirected to a mail server under the

Re: [Uta] I-D Action: draft-ietf-uta-smtp-require-tls-04.txt

Author : Jim Fenton Filename: draft-ietf-uta-smtp-require-tls-04.txt Pages : 15 Date: 2018-09-26 Abstract: The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful

[Uta] Late comment on REQURIETLS: Received header field

In addition to the comment from Viktor a couple of weeks ago, I received a suggestion off-list the other day that is worthy of discussion. The submitter did not want to join the mailing list but did agree to the terms of the Note Well. The suggestion: I had the idea, that it would be useful

Re: [Uta] Last call: "SMTP Require TLS Option"

On 8/23/18 6:49 PM, Viktor Dukhovni wrote: On Jul 18, 2018, at 1:50 PM, Valery Smyslov wrote: draft-ietf-uta-smtp-require-tls-03 In https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-03#section-4.2.1 bullet 3, the reference to DANE authentication is to RFC6698, but DANE for SMTP is

Re: [Uta] Last call: "SMTP Require TLS Option"

Valery, Thanks for your review. Responses inline. On 8/15/18 7:55 AM, Valery Smyslov wrote: Hi, here is my review of the document. The draft is well written, however I found few places where it could be improved. 1. Section 2: In the following para: In order to specify REQUIRETLS

Re: [Uta] I-D Action: draft-ietf-uta-smtp-require-tls-03.txt

Author : Jim Fenton Filename: draft-ietf-uta-smtp-require-tls-03.txt Pages : 15 Date: 2018-06-22 Abstract: The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from

Re: [Uta] I-D Action: draft-ietf-uta-smtp-require-tls-02.txt

Thanks for your review, Chris: On 4/9/18 6:08 PM, Chris Newman wrote: > On 6 Apr 2018, at 16:20, Jim Fenton wrote: >> The major change in this version is the removal of the options (CHAIN, >> DANE, and DNSSEC) from the REQUIRETLS SMTP option as discussed in >> Lo

Re: [Uta] I-D Action: draft-ietf-uta-smtp-require-tls-02.txt

uire TLS Option > Author : Jim Fenton > Filename: draft-ietf-uta-smtp-require-tls-02.txt > Pages : 14 > Date: 2018-04-06 > > Abstract: >The SMTP STARTTLS option, used in negotiating transport-level

Re: [Uta] Genart last call review of draft-ietf-uta-smtp-tlsrpt-17

On 3/26/18 5:40 PM, Brotman, Alexander wrote: > So, we'd need to create a new Service Type (I see only * and email > currently), correct? Could we alternately use the "n=" field and require > that the note be set to "tlsrpt"? If we do add this, and the receiving party > is unable to find the

Re: [Uta] RequireTLS: NO

On 3/23/18 1:19 AM, Tim Hollebeek wrote: >> to (easy with e.g. Postfix header_checks): >> >> Require-TLS: NO >> Subject: [insecure-delivery]: actual subject >> >> or (not easy with header_checks, but hides the subject tag): >> >> Require-TLS: NO >> Subject: actual subject > I

Re: [Uta] RequireTLS: NO

On 3/22/18 12:59 PM, Daniel Kahn Gillmor wrote: > On Thu 2018-03-22 15:17:18 -0400, Viktor Dukhovni wrote: >>> On Mar 22, 2018, at 2:59 PM, Martin Thomson >>> wrote: >>> >>> https://tools.ietf.org/html/draft-trammell-optional-security-not-00 is >>> relevant. >> A

Re: [Uta] Genart last call review of draft-ietf-uta-smtp-tlsrpt-17

Requiring that the selector have a particular name or name prefix associates semantics with selector names, of which there is none. It also requires the management (e.g., rotation) of more keys per domain. There is a better way to do this. The s= tag on the key record (service type) can be used

Re: [Uta] uta - New Meeting Session Request for IETF 101

>>> Conflicts to Avoid: >>> First Priority: tokbind tls oauth secevent >>> >>> >>> >>> >>> People who must be present: >>>

Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC

On 2/20/18 10:13 PM, Valery Smyslov wrote: > Hi, > > this is the second working group last call (WGLC) for the "SMTP TLS Reporting" > (https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/). > The WGLC will be short and will last for one week till March the 1st. The > document has received

Re: [Uta] I-D Action: draft-ietf-uta-smtp-require-tls-01.txt

Gentle reminder: I haven't yet gotten any comments on this new version of the REQUIRETLS draft, and would appreciate some review. -Jim On 1/16/18 1:58 PM, Jim Fenton wrote: > This version moves the "REQUIRETLS=NO" option to a message header field, > RequireTLS: No, and removes

Re: [Uta] I-D Action: draft-ietf-uta-smtp-require-tls-01.txt

On 1/16/18 1:53 PM, internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Using TLS in Applications WG of the IETF. > > Title : SMTP Require TLS Option > Author

Re: [Uta] Require TLS=NO is very much needed

On 11/17/17 6:28 AM, Eliot Lear wrote: > I've been watching the back and forth and trying to get my hands around > the technical issues between the two cases.  The closest I see for a > technical explanation in this thread is this: > > > On 11/17/17 3:55 AM, Viktor Dukhovni wrote: >> As I pointed

Re: [Uta] Require TLS=NO is very much needed

On 11/16/17 7:06 PM, Leif Johansson wrote: > > On 2017-11-17 03:55, Viktor Dukhovni wrote: >> >>> On Nov 16, 2017, at 8:56 PM, Leif Johansson wrote: >>> >>> The sense of the room in Singapore was that the semantics >>> of REQUIRETLS=NO was sufficiently different from REQUIRETLS

Re: [Uta] REQUIRETLS vs. headers

On 11/16/17 3:49 PM, Viktor Dukhovni wrote: > 1. I agree that REQUIRETLS=NO needs a header so it can be >tunnelled via an "agnostic" MTA. > > 2. However, even REQUIRETLS=YES needs a header, because: > >a. Within an MTA a message may make multiple internal > hops, for example

Re: [Uta] Comments on mta-sts-11

On 11/12/17 10:48 AM, Viktor Dukhovni wrote: > >> On Nov 12, 2017, at 6:01 AM, Jim Fenton <fen...@bluepopcorn.net> wrote: >> >> An attacker that is positioned between mail servers to be >> able to block the negotiation of STARTTLS probably is also positioned to >

[Uta] Comments on mta-sts-11

Hi, On the flight to Singapore, I went through the latest mta-sts draft, and have a number of comments. Some of these I have probably made before, but (at the risk of belaboring old items) I think they warrant revisiting. My overarching concern is whether MTA-STS would be effective against an

Re: [Uta] STS and SAN (vs Host) matching

On 11/1/17 3:59 AM, Daniel Margolis wrote: > The decision to use policy-to-SAN matching instead of > policy-to-hostname matching was discussed here > (https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). I > think the WG was at the time largely in consensus (or we misread the >

Re: [Uta] STS and SNI (was Re: Interaction between MTA-STS and DANE)

On 10/24/2017 11:59 AM, Viktor Dukhovni wrote: > >> On Oct 24, 2017, at 2:48 PM, Jim Fenton <fen...@bluepopcorn.net> wrote: >> >> Regarding a) above: I apparently missed this. Is there any other >> circumstance where the certificate presented is matche

Re: [Uta] Establishing minimum TLS requirements for use with STS

A slightly different view of things, inline: On 10/25/2017 11:16 AM, Viktor Dukhovni wrote: > We're losing track of a few facts here: > > - It is not the client that has enhanced security requirements, > rather it is the recipient domain that is politely requesting > enhanced security, and

Re: [Uta] STS and SNI (was Re: Interaction between MTA-STS and DANE)

> On Oct 24, 2017, at 5:10 AM, Daniel Margolis wrote: > > Regarding arguments in favor of supporting SNI, Jim made the best attempt in > this thread to come up with a motivating use case, and I don't find it very > compelling. In his example (where two hosting providers

Re: [Uta] STS and SNI (was Re: Interaction between MTA-STS and DANE)

> On Oct 21, 2017, at 2:40 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > >> On Oct 20, 2017, at 7:09 PM, Jim Fenton <fen...@bluepopcorn.net> wrote: >> >> Maybe this was explained somewhere earlier in the thread and I missed it,

Re: [Uta] STS and SNI (was Re: Interaction between MTA-STS and DANE)

> On Oct 19, 2017, at 4:03 AM, Daniel Margolis wrote: > > Yes, I also don't see the point of vanity hosts, but I guess some people want > this for some reason. Maybe this was explained somewhere earlier in the thread and I missed it, but can you explain what ‘vanity

Re: [Uta] not gona meet in Singapore?

Oops, your earlier message fell through the cracks. I will be in Singapore, and would like the opportunity to talk some more about REQUIRETLS, now that it is a WG draft. I'm also a little confused on the status of the other WG documents. Apparently DEEP is ready for IETF Last Call? TLSRPT is in

Re: [Uta] Rationale for mts-sts.

On 9/15/17 1:46 PM, Viktor Dukhovni wrote: > On Fri, Sep 15, 2017 at 08:14:40PM +, Binu Ramakrishnan wrote: > >> One advantage of using a sub-domain is the ability to delegate STS policy >> serving (and mail hosting) to a 3rd party service provider. > If support for 302 redirects is added,

Re: [Uta] I-D Action: draft-ietf-uta-smtp-require-tls-00.txt

; Title : SMTP Require TLS Option > Author : Jim Fenton > Filename: draft-ietf-uta-smtp-require-tls-00.txt > Pages : 13 > Date: 2017-08-07 > > Abstract: >The SMTP STARTTLS option, used in negotiating tra

Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.

On 8/10/17 10:46 AM, Viktor Dukhovni wrote: > On Thu, Aug 10, 2017 at 10:02:41AM -0700, Daniel Margolis wrote: > >> If anyone else has read this far on the thread, I'm happy to get feedback >> on this proposal from others on the list. > Yes, please! > I have been following the discussion, although

Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06

On 8/9/17 6:33 AM, Alexey Melnikov wrote: > Hi, > > (As a participant) > > > On 09/08/2017 14:07, Brotman, Alexander wrote: >> Jim, >> >> To be clear, you'd like to remove the headers (5.3) and filename >> (5.1) sections, and have all the filtering based solely on the >> subject that is specified

Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06

In response to Leif's request for specific text for the larger issues: On 7/31/17 4:02 PM, Jim Fenton wrote: > > General comments: > > All of the references are listed as normative, which I strongly suspect > isn't really the case. Informative references need to be separated. >

Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06

On 08/01/2017 10:17 PM, Leif Johansson wrote: > > On 2017-08-01 22:08, Jim Fenton wrote: >> >> I don't think I was suggesting anything involving Subject. There's >> already some of this in Section 5.3, and I'm not crazy about doing that >> either, especially since it'

Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06

On 8/1/17 1:02 PM, Alexey Melnikov wrote: > On 01/08/2017 19:41, Jim Fenton wrote: >> On 8/1/17 2:11 AM, Alexey Melnikov wrote: >>> Jim, >>> I would like to disagree: >>> >>>> On 1 Aug 2017, at 00:02, Jim Fenton <fen...@bluepopcorn.net> wrote:

Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06

On 8/1/17 2:11 AM, Alexey Melnikov wrote: > Jim, > I would like to disagree: > >> On 1 Aug 2017, at 00:02, Jim Fenton <fen...@bluepopcorn.net> wrote: >> >> Section 5.3, I don't think it's a good idea to define and require new >> message heade

Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06

On 7/12/17 3:11 AM, Leif Johansson wrote: > This starts a 3 week working group last call (WGLC) on > draft-ietf-uta-smtp-tlsrpt-06. Please provide your comments to the list > by Wednesday > August 2nd. General comments: All of the references are listed as normative, which I strongly suspect isn't

Re: [Uta] adopt draft-fenton-smtp-require-tls-03 as WG document

Rolf, thanks very much for your review, including the nitpicking. Responses to a few items below. On 07/22/2017 02:57 PM, Rolf E. Sonneveld wrote: > > Page 4: > > this option MUST only be specified in the context >of an SMTP session meeting the security requirements that have been >

Re: [Uta] Comments on draft-ietf-uta-mta-sts-03

On 3/27/17 1:21 AM, Viktor Dukhovni wrote: >> On Mar 27, 2017, at 4:08 AM, Federico Santandrea - Diennea >> wrote: >> >> >> Let's suppose the sending MTA finds the MTA-STS TXT record, which states >> the receiving domain has an MTA-STS policy. The draft says "To

Re: [Uta] New Version Notification for draft-fenton-smtp-require-tls-03.txt

Responses inline. On 3/3/17 4:36 PM, Viktor Dukhovni wrote: >> On Feb 14, 2017, at 12:51 AM, Jim Fenton <fen...@bluepopcorn.net> wrote: >> >> A new version of I-D, draft-fenton-smtp-require-tls-03.txt >> has been successfully submitted by Jim Fenton and posted to th

[Uta] Comments on draft-ietf-uta-mta-sts-03

Below are comments from my recent reading of draft-ietf-uta-mta-sts-03. The biggest concern I have is the relationship between the DNS TXT record and the HTTPS policy record. The policy is hosted in HTTPS rather directly in DNS in order to attempt to provide security without DNSSEC. But if

[Uta] Fwd: New Version Notification for draft-fenton-smtp-require-tls-03.txt

A new version of I-D, draft-fenton-smtp-require-tls-03.txt has been successfully submitted by Jim Fenton and posted to the IETF repository. Name: draft-fenton-smtp-require-tls Revision: 03 Title: SMTP Require TLS Option Document date: 2017-02-13 Group

Re: [Uta] UTA meeting in Chicago?

o meet in Chicago and progress the work. > Please, share your plans (drafts, etc.) for the upcoming meeting and request > a slot ASAP by Feb 9th. > > Thank you, > The chairs. > > -Original Message- > From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Jim Fenton > S

Re: [Uta] REQUIRETLS update

On 12/16/16 3:31 PM, Viktor Dukhovni wrote: >> On Dec 16, 2016, at 5:53 PM, Jim Fenton <fen...@bluepopcorn.net> wrote: >> >> It seems that Viktor and I have differing views on the usefulness of >> MAYTLS and REQUIRETLS. That said, I agree that it doesn't make s

Re: [Uta] REQUIRETLS update

On 12/10/16 1:55 AM, ned+...@mrochek.com wrote: >> On Fri, Dec 09, 2016 at 04:13:08PM -, John Levine wrote: What would (for example) be the result if a client requested both the REQUIRETLS and a separate MAYTLS feature? >>> Given that mail servers will do whatever they wany with

[Uta] REQUIRETLS update

It has been a little while, so I thought it might be appropriate to give the WG an update on the status of REQUIRETLS (draft-fenton-smtp-require-tls-02). There are now two prototype implementations: - Exim implementation by Jeremy Harris (announced on UTA list on 2 September) - MDaemon

Re: [Uta] review of smtp-require-tls-02

On 9/18/16 6:38 PM, Viktor Dukhovni wrote: >> On Aug 22, 2016, at 10:53 AM, Jeremy Harris wrote: >> >>> draft-fenton-smtp-require-tls > ion >> Abstract >> >>The SMTP STARTTLS option, used in negotiating transport-level >>encryption of SMTP connections, is not as useful

Re: [Uta] review of smtp-require-tls-02

On 9/18/16 5:35 PM, Viktor Dukhovni wrote: >> On Sep 18, 2016, at 6:47 PM, Jim Fenton <fen...@bluepopcorn.net> wrote: >> >> Yes; I'm not sure why I singled out MX and CNAME because I know those >> aren't the only ways of locating the server. I would propose to change

Re: [Uta] review of smtp-require-tls-02

Apologies for the very late reply; this slipped through the cracks somehow. On 8/22/16 7:53 AM, Jeremy Harris wrote: > On 16/08/16 23:09, Jim Fenton wrote: >> Name:draft-fenton-smtp-require-tls >> Revision:02 > - Section 2, bullet point discussing th

[Uta] Fwd: New Version Notification for draft-fenton-smtp-require-tls-02.txt

I-D, draft-fenton-smtp-require-tls-02.txt has been successfully submitted by Jim Fenton and posted to the IETF repository. Name: draft-fenton-smtp-require-tls Revision: 02 Title: SMTP Require TLS Option Document date: 2016-08-16 Group: Individual Submission Pages:

Re: [Uta] New proposal: SMTP Strict Transport Security

On 4/4/16 5:45 AM, Jeremy Harris wrote: > On 04/04/16 13:01, Jim Fenton wrote: >> On 4/4/16 3:14 AM, Jeremy Harris wrote: >>> On 01/04/16 23:18, Viktor Dukhovni wrote: >>>> On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote: >>>>> I feel ve

Re: [Uta] New proposal: SMTP Strict Transport Security

On 4/4/16 3:14 AM, Jeremy Harris wrote: > On 01/04/16 23:18, Viktor Dukhovni wrote: >> On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote: >>> I feel very strongly that policy for SMTP relay should be advertised by >>> SMTP and protected by SMTP TLS. >> Unfortunately, in MTA-to-MTA SMTP,

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On 3/25/16 3:19 PM, Viktor Dukhovni wrote: > On Fri, Mar 25, 2016 at 12:35:02PM -0700, Jim Fenton wrote: > >>> If the entire goal is to ensure the integrity of the RFC 6125 >>> "reference identifier" used to authenticate the nexthop SMTP >>>

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On 03/25/2016 11:24 AM, Viktor Dukhovni wrote: > On Thu, Mar 24, 2016 at 07:12:43PM -0700, Jim Fenton wrote: > >> Not to distract from the STS discussion, but I thought I'd point out >> another approach to SMTP TLS 'encouragement' that I submitted a few >> weeks ago: draft

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On 03/25/2016 07:24 AM, Jeremy Harris wrote: > On 25/03/16 02:12, Jim Fenton wrote: >> draft-fenton-smtp-require-tls-01 >> The idea here is that REQUIRETLS allows the SMTP client to override the >> default "deliver even if you can't do it securely" beha

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On 03/25/2016 06:45 AM, Jeremy Harris wrote: > On 25/03/16 12:09, Aaron Zauner wrote: >>> On 25 Mar 2016, at 03:12, Jim Fenton <fen...@bluepopcorn.net> wrote: >>> REQUIRETLS is an SMTP service extension that allows an SMTP client to >>> specify (via a MAIL FR

[Uta] REQUIRETLS: another SMTP TLS mechanism

Not to distract from the STS discussion, but I thought I'd point out another approach to SMTP TLS 'encouragement' that I submitted a few weeks ago: draft-fenton-smtp-require-tls-01. There has been some discussion of this draft, primarily on the ietf-smtp mailing list and a little on the perpass