Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-11.txt

Hi Peter, On 02/03/2023 18:06, Peter Saint-Andre wrote: Hi all, This version represents our attempt to address feedback received during the recent consensus call. The primary changes are: 1. Clarify the difference between service delegation and DNS delegation. 2. Clarify the difference

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

Hi, My apologies for late response. I read the document and I generally found it in a good state and thus support its publication. I have one minor comment: 2nd paragraph of 6.4 reads:    These identifiers provide an application service type portion to be    checked, but that portion is

Re: [Uta] Call for adoption of draft-ciphersuites-in-sec-syslog

Hi, On 22/04/2022 13:59, Valery Smyslov wrote: Hi, recent discussion on the ML showed some interest of the WG in adoption of draft-ciphersuites-in-sec-syslog. This message starts a two-week call for adoption of this document

Re: [Uta] Some quick comments on some changes in draft-ietf-uta-rfc6125bis-04

Hi Rich, On 29/11/2021 15:43, Salz, Rich wrote: Alexey, Thanks very much for your comments. I was a little over-zealous :). Does this diff address your concerns? Works for me. Best Regards, Alexey ___ Uta mailing list Uta@ietf.org

[Uta] Some quick comments on some changes in draft-ietf-uta-rfc6125bis-04

Hi Rich, I've noticed some recent changes to the document that don't look right to me: 3.  Designing Application Protocols    This section defines how protocol designers should reference this    document, which MUST be a normative reference in their specification. This is kind of a funny

Re: [Uta] 6125bis -- security considerations

Hi Rich, On 28/09/2021 15:20, Salz, Rich wrote: I am proposing the following for the security section.  Any comments?  In particular, what about the “multiple identifiers” at the last few lines?  Should that go away now?  If so, that will have ripple effects.  This text is currently at

Re: [Uta] Pinning

On 09/09/2021 16:12, Viktor Dukhovni wrote: On Thu, Sep 09, 2021 at 01:55:44PM +, Salz, Rich wrote: I updated https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/19 to have something based on Viktor's suggestion. The main wording changes were about using MUST MAY SHOULD language in

[Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

Hi, Section 3.8 of the draft says:    TLS implementations (both client- and server-side) MUST support the    Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]. This looks fine to me. I assume it is still up to application protocols to decide whether or not use of ALPN is

Re: [Uta] Wildcards

Hi Rich, On 08/07/2021 15: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. 

Re: [Uta] Adoption of draft-rsalz-use-san

Hi, > On 14 Mar 2021, at 14:47, Valery Smyslov wrote: > >  > Hi, > > this message starts 2 weeks formal adoption call for draft-rsalz-use-san. > The call will end on Sunday 28 March. I support adoption of this document. Best Regards, Alexey > > The draft has already received some support

Re: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

Hi, On 27/04/2020 12:25, Ralph Holz wrote: Hi, I am not sure which key requirement you are referring to, or why TLS 1.3 should not see widespread use. In fact, TLS 1.3 is getting much more traction already than TLS 1.2 ever had in a comparable amount of time:

Re: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

Hi, On 26/04/2020 10:35, Valery Smyslov wrote: Hi, during the last virtual interim meeting the draft draft-sheffer-uta-bcp195bis-00 was presented and the authors asked for its adoption. The general feeling in the room was in favor of the adoption, however the authors were asked to rename it

Re: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

On 27/04/2020 10:03, 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 It doesn't address TLS

Re: [Uta] Martin Vigoureux's No Objection on draft-ietf-uta-tls-for-email-04: (with COMMENT)

Hi Martin, On 17/02/2020 13:06, Martin Vigoureux via Datatracker wrote: -- COMMENT: -- Hi In the updates it proposes, this document seems to still allow for

Re: [Uta] [Technical Errata Reported] RFC8460 (5889)

> On 21 Nov 2019, at 10:13, Murray S. Kucherawy wrote: > > I would guess we can't rectify this oversight via the errata system. What > got IETF Review was the need for the registration, but not the registration > itself. > > I imagine this should either be done through DISPATCH (which is

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

Hi Ekr, On Thu, Feb 21, 2019, at 3:07 PM, Eric Rescorla wrote: > -- > DISCUSS: > -- > > I support Benjamin's DISCUSS. > > To elaborate on one point a bit: it

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

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 senders to > actively decide whether every outgoing message requires end-to-end TLS > protection or is safe to

Re: [Uta] [ietf-smtp] New Version Notification for draft-levine-additional-registered-clauses-00

Hi all, On 24 Jan 2019, at 23:41, Salz, Rich wrote: >> As I have always understood it, "spec required" means a >published, stable, readily-accessible, etc., specification. >Not necessarily an RFC but, until the definition of an I-D is >changed to eliminate all of the "don't

Re: [Uta] storing SNI in the Received header [was: Re: how to log, was flake ho, was MTA-STS with lots of domains]

Hi Tony, On 15/01/2019 11:49, Tony Finch wrote: John R Levine wrote: Per the subsequent note, I'm sticking it in the BY header which allows a second domain name in the parens that nobody ever uses. Hi, I'm nobody :-) Our mail servers populate the BY clause like BY servername

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

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. The document needs to specify line length increase and whether the extension is allowed for SMTP Submission

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

Hi Jim, Very quick comment on just one point: On 10/01/2019 19:48, Jim Fenton wrote: Examples/ABNF, I had thought this was simple enough that these weren't needed, but fair point, will add. For new header fields it is important to show whether any CFWS are allowed in values, so I prefer

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

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. The document needs to specify line length increase and whether the extension is allowed for SMTP Submission and LMTP (I think

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

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 following text: If published as an RFC, this draft requests the addition of an entry to the Permanent Message

Re: [Uta] Scanresults mta-sts policies

Hi Hanno, Thank you for sending your scanresults! On 30/09/2018 19:11, Hanno Böck wrote: Hi, I did now some more scans for MTA-STS and I thought it might be interesting for the list to learn the results. A very effective way of finding hosts that support mta-sts is to scrape the Certificate

Re: [Uta] Typo in MTA-STS policy definition (draft-ietf-uta-mta-sts-21)

Hi Richard, > On 5 Sep 2018, at 10:49, Richard Gray wrote: > > Is there a typo in the formal definition of an MTA-STS policy in > draft-ietf-uta-mta-sts-21 section 3.2? > > Specifically, sts-policy-mx is not referenced from anywhere else in the ABNF > definition. It seems that this was

Re: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-23.txt

On 14/06/2018 13:20, 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 TLS Reporting Authors : Daniel

Re: [Uta] I-D Action: draft-ietf-uta-mta-sts-20.txt

Hi James, On 06/06/2018 17:48, James Cloos wrote: Was the s/https/http/g in the boilerplate intentional? The boilerplate is generated by a tool, so it is not under control of document editors. I can ask the tools team. Best Regards, Alexey ___

Re: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-22.txt

On 23/05/2018 16:52, internet-dra...@ietf.org wrote: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-22

[Uta] draft-ietf-uta-smtp-tlsrpt-20.txt: suggested changes to Section 6.2 (Report Type)

I would like to suggest the following replacement for the Section 6.2 (Report Type): OLD:    This document registers a new parameter "report-type="tlsrpt"" under    "multipart/report" top-level media type for use with [RFC6522].    The media type suitable for use as a report-type is defined in

Re: [Uta] MTA-STS (r16) & TLSRPT (r19)

Hi Alexander, On 02/05/2018 17:57, Brotman, Alexander wrote: Hello, We wanted to upload another set of drafts so that we could ensure we've properly addressed items previously raised. I believe Alexey and Ned were still discussing an item relating to MTA-STS, Ned just suggested a minor

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

Hi Benjamin, Thank you for your review comments! Just a generic reply on one of them: On 16/04/2018 16:22, Benjamin Kaduk wrote: Section 3 o "v": This value MUST be equal to "TLSRPTv1". How about something like "This document defines version 1; other versions may be defined in later

[Uta] Proposed text for registering _tls DNS label

Hi, I response to Phillip Hallam-Baker's SecDir review, I propose to add the following note to the document: -- [[RFC Editor: if draft-ietf-dnsop-attrleaf gets published as an RFC before this document, please add the following text (as a new 6.X Section) to the

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

Hi Phillip, To followup on the IANA issue from your SecDir review: On 08/03/2018 19:39, Phillip Hallam-Baker wrote: > > Specific issues > > The DNS prefix _smtp-tlsrpt is defined. This is not mentioned in the IANA > considerations. It is a code point being defined in a protocol that is outside

[Uta] AD review of draft-ietf-uta-mta-sts-14

Hi, I just finished my AD review of the document. As far as I am concerned, all "major" issues need to be addressed and other issues need to be discussed before I start IETF LC on this draft. Major issues: 1) 3.2. MTA-STS Policies The [RFC7231] "Content-Type" media type for this

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

Session(s): 1 Hour >>> Number of Attendees: 50 >>> Conflicts to Avoid: >>> First Priority: tokbind tls oauth secevent >>> >>> >>> >>> >>> People who m

Re: [Uta] Updated TLSRPT

Viktor, On 29/01/2018 15:46, Viktor Dukhovni wrote: On Jan 29, 2018, at 2:35 AM, Valery Smyslov wrote: Again, please provide the text. Otherwise the iterations update-review may last forever. It is unclear from the current state of the document whether my suggestion

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

On 17/11/2017 09:56, Leif Johansson wrote: > On 2017-11-17 01:01, Viktor Dukhovni wrote: >> >> People are forgetting that especially smaller sites >> that implement STS or DANE don't always have the >> operational discipline to keep these working. I >> have considerable evidence to support this

[Uta] New UTA co-chair

Dear UTA WG, I am pleased to announce that Leif now has another co-chair: Valery Smyslov . Valery edited several documents in IPSECME and is now looking forward to help the UTA WG. Thank you, Alexey ___ Uta mailing list

Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

Hi Keith, One little thing about your new ABNF for DH group: On 25/10/2017 01:31, Keith Moore wrote: Line 328    the TLS ciphersuite of the session in which the mail was received,    in the Received field of the outgoing message.  (See Section 4.3.) Do you want to also suggest that

[Uta] Orit is stepping down as a co-chair

Dear WG participants, Due to Orit's other commitments at her day job, she decided to step down as UTA co-chair. I would like to thank you Orit for her chairing of the UTA WG and I would like to wish her the best of luck in whatever she is going to do next! Best Regards, Alexey

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

A few more comments on filenames: On 09/08/2017 14:33, Alexey Melnikov wrote: Regarding filenames - I am ambivalent. If you need this information somewhere, you will need to define new header fields as well. In IMAP filename Content-Disposition parameter is returned as a part

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

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 in 5.3? I don't think Jim made a convincing argument for

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

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: >>> A better approach IMO would be to suggest the us

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

> On 1 Aug 2017, at 00:02, Jim Fenton wrote: > > Section 7, additional consideration: The "untrusted content" > consideration talks about malicious code, but attackers could also send > counterfeit reports that look real in an effort to confuse the report > recipient.

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

> On 1 Aug 2017, at 00:02, Jim Fenton wrote: > > As the document notes, the reference for MTA-STS needs to be added. If > it is a normative reference, this document will be held up until that is > published. I think it is Informative.

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

Jim, I would like to disagree: > On 1 Aug 2017, at 00:02, Jim Fenton wrote: > > Section 5.3, I don't think it's a good idea to define and require new > message header fields for this. This means that some of the > general-purpose libraries for sending email messages

Re: [Uta] Review of draft-ietf-uta-email-deep-08

Hi Keith, Quickly answering to a few easy ones: On 25/07/2017 05:18, Keith Moore wrote: > Hi Alexey, > > Thanks for the review! Some responses: > > > On 07/24/2017 12:04 PM, Alexey Melnikov wrote: >> I am generally very pleased with -07 and -08. >> &g

[Uta] Review of draft-ietf-uta-email-deep-08

I am generally very pleased with -07 and -08. A few minor comments: 1. Introduction This memo does not address use of TLS with SMTP for message relay (where Message Submission [RFC6409] does not apply). Improved use of TLS with SMTP for message relay requires a different approach.

Re: [Uta] consensus call on K/V vs JSON

Hi, If we end up going the K/V route: > On 22 Jul 2017, at 09:53, Viktor Dukhovni wrote: > > On Fri, Jul 21, 2017 at 12:59:51PM +0100, Jeremy Harris wrote: > >>> I would prefer to have more opinions (implementors in particular) but >> >> There's no way I would add JSON

Re: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt

> On 28 Jun 2017, at 22:31, Leif Johansson wrote: > >> On 2017-06-28 20:17, Brotman, Alexander wrote: >> We believe so. We'd like to gather as many comments as possible to go with >> Alexey's and bundle those up, and hopefully finalize this. > > If you have more outstanding

[Uta] Review of draft-ietf-uta-mta-sts-04

Hi, Below is my early "AD review" of the document. I think it is in pretty good shape and is ready for WG Last Call (I am Ok with the question of JSON versa something else be settled during or after WGLC.) 1) In 1.1: o Policy Domain: The domain for which an MTA-STS Policy is defined.

Re: [Uta] draft-ietf-uta-mta-sts-04 Review

Hi Daniel, On 18/04/2017 17:15, Daniel Margolis wrote: On Thu, Apr 6, 2017 at 11:08 AM, > wrote: _ Section 3.3 HTTPS Policy Fetching "When fetching a new policy or updating a policy, the HTTPS endpoint MUST

[Uta] AD review of draft-ietf-uta-smtp-tlsrpt-04.txt

Hi, I've done an early Area Director-style review of the document. Some of the issues I found in -03 were already fixed in -04. In Section 1: Specifically, this document defines a reporting schema that covers failures in routing, STARTTLS negotiation, and both DANE [RFC6698] and

Re: [Uta] I-D Action: draft-ietf-uta-email-deep-06.txt

Nit in the latest version: 12.6. Advertisement of STS policies MSPs SHOULD advertise STS policies that include at least tls11, tls- I think "tls11" was changed to "tls-version=1.1". cert and sts-url, with the latter having an associated https URL that can be used to inform clients of

Re: [Uta] Obsolete TLS wording in IMAP specification

Hi Julien, > On 6 Jan 2017, at 21:00, Julien ÉLIE wrote: > > Hi all, > > I've just seen that IMAP specification (RFC 3501) mentions in Section 11.1 > that "IMAP client and server implementations MUST implement the > TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite". >

Re: [Uta] MTA STS and HTTPS fetch timeouts

Hi Daniel, > On 11 Sep 2016, at 14:56, Daniel Margolis wrote: > > There was some discussion of this at IETF96: Should we be specifying timeouts > on the HTTPS GET during policy fetch? > > I was looking at RFC 2821's timeouts for comparison (section 4.5.3.2): > > "Based

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

Hi Viktor, On 22/03/2016 16:09, Viktor Dukhovni wrote: On Tue, Mar 22, 2016 at 11:10:57AM +0100, Daniel Margolis wrote: Thanks for the feedback to both of you. I don't disagree; I think Viktor makes a very solid point in favor of simplicity. In addition, a report-only protocol could be

Re: [Uta] wrt draft-ietf-uta-email-tls-certs

Hi Jeff, On 02/02/2016 00:54, =JeffH wrote: > Hi Alexey, > > I was taking a look at wrt draft-ietf-uta-email-tls-certs and noted that > it says this in Section 3.. > >[...] >Matching is performed according >to the rules specified in Section 6 of

Re: [Uta] Agenda requests

Hi, On 21/01/2016 22:58, Orit Levin (CELA) wrote: Folks, We are one month away from the final cutoff day 2016-02-19 (Friday). Please, send your requests to the list ASAP so we all can plan for the meeting accordingly. I would like to discuss draft-friedl-uta-smtp-mta-certs-00 (TLS

Re: [Uta] I-D Action: draft-ietf-uta-email-tls-certs-08.txt

On 17/12/2015 13:29, internet-dra...@ietf.org wrote: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-email-tls-certs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-uta-email-tls-certs-08 A diff from the

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

Hi Ben, On 16/12/2015 20:25, Ben Campbell wrote: -- COMMENT: -- - section 3, first paragraph: MiTM prevention is just one of many reasons to match the

Re: [Uta] Barry Leiba's Discuss on draft-ietf-uta-email-tls-certs-07: (with DISCUSS and COMMENT)

Hi Barry, Thank you for your comments: On 15/12/2015 21:20, Barry Leiba wrote: -- COMMENT: -- In the Introduction, you say that ths document replaces Section

Re: [Uta] Barry Leiba's Discuss on draft-ietf-uta-email-tls-certs-07: (with DISCUSS and COMMENT)

Hi Barry, I am going to quickly answer to your DISCUSS point and will reply to your comments separately: On 15/12/2015 21:20, Barry Leiba wrote: -- DISCUSS:

Re: [Uta] I-D Action: draft-ietf-uta-email-tls-certs-07.txt

Victor, > On 14 Dec 2015, at 16:44, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > >> On Wed, Dec 09, 2015 at 05:29:43PM +0000, Alexey Melnikov wrote: >> >>> On 09/12/2015 17:26, internet-dra...@ietf.org wrote: >>> The IETF datatracke

Re: [Uta] I-D Action: draft-ietf-uta-email-tls-certs-07.txt

Hi, On 09/12/2015 17:26, internet-dra...@ietf.org wrote: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-email-tls-certs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-uta-email-tls-certs-07 A diff from

Re: [Uta] I-D Action: draft-ietf-uta-email-tls-certs-06.txt

for Email Related Protocols Author : Alexey Melnikov Filename: draft-ietf-uta-email-tls-certs-06.txt Pages : 10 Date: 2015-12-04 Abstract: This document describes TLS server identity verification procedure for SMTP

Re: [Uta] UTA: Server certificate management (Re: Last Call: )

On 02/12/2015 15:17, John Levine wrote: 1) use Server Name Indication TLS extension. At the moment none of the email specs requires it. But maybe it is something that the draft should encourage. 2) run each domain on its own IP/port, then each IP/port can use separate certificate with a single

Re: [Uta] UTA: Server certificate management (Re: Last Call: )

Hi John, On 02/12/2015 13:42, John R Levine wrote: But it has to be signed by a CA. If the CA is not happy for you to assert SRV-ID, it should not include SRV-ID in an issued certificate. Now I'm really confused. Are you saying the SRV-ID is optional? I am saying that CAs can't sign what

Re: [Uta] UTA: Server certificate management (Re: Last Call: )

On 02/12/2015 15:54, John R Levine wrote: If there's no SRV-ID, you don't need SNI since all 100,000 domains point at the same server name. Yes, but then they can't be verified automatically by MUAs, so each of them would need to be approved manually by users. Aren't we back to RFC 6186? If

Re: [Uta] UTA: Server certificate management (Re: Last Call: )

On 01/12/2015 18:38, John Levine wrote: The key word in that text is "another". This does not require the server to have a certificate that matches this identifier, provided there is some other some suitable identifier. It provides additional flexibility, not a constraint. NOTE HOWEVER, that

Re: [Uta] Last Call: (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard

Hi Julien, > On 24 Nov 2015, at 21:26, Julien ÉLIE wrote: > > Couldn't the draft also update Section 5 of RFC 4642 about the use of TLS in > NNTP? > The NNTP protocol is also a protocol that is found in email clients, so it > would make sense to have consistent rules

Re: [Uta] Last Call: (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard

ps://tools.ietf.org/html/rfc6125#ref-PKIX>] and [URI <https://tools.ietf.org/html/rfc6125#ref-URI>] then it would be alright. If we start explaining reference identifiers, etc., then it is much harder job and I an worried of not copying enough, which can make this misleading wh

Re: [Uta] Last Call: (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard

Hi Russ, Thank you for your comments. On 20/11/2015 21:36, Russ Housley wrote: > I support this document going forward. Below I suggest four improvements to > the document. > > (1) In Introduction says: > >Note that this document doesn't apply to use of TLS in MTA-to-MTA >SMTP. > >

Re: [Uta] AD review of draft-ietf-uta-email-tls-certs-05

Hi Stephen, On 20/11/2015 12:53, Stephen Farrell wrote: > > Hiya, > > Sorry for being slow getting this done. My AD review of this > is below. Please consider my comments as last call comments. > I have requested last call for this one so you should see the > announcement of that shortly.

Re: [Uta] AD review of draft-ietf-uta-email-tls-certs-05

Hi John, On 20/11/2015 15:55, John Levine wrote: IMHO, this is something for the to-be-written mail service discovery document, which is not this spec. How does that differ from RFC 6186? It isn't. But I've heard people saying that RFC 6186 is insufficient or needs updating. I'd rather

Re: [Uta] WGLC draft-ietf-uta-email-tls-certs

On 15/04/2015 02:14, Brian Smith wrote: Thanks for answering my questions. I still think that the X.509 certificate with SRV-ID approach seems too impractical to expect widespread enough adoption to make it worthwhile to implement the infrastructure for it. Consequently, I think saying that

Re: [Uta] Call for draft-ietf-uta-email-tls-certs-01 reviews

On 21/03/2015 07:38, Viktor Dukhovni wrote: [...] Below is a proposal to expand the scope to cover use of email certificates (still other than MTA-to-MTA) with DANE. Since the DANE SRV draft is almost ready for IETF LC, I think it is reasonable to also discuss the use-case for DNSSEC/DANE

Re: [Uta] Call for draft-ietf-uta-email-tls-certs-01 reviews

On 21/03/2015 07:38, Viktor Dukhovni wrote: On Thu, Mar 19, 2015 at 12:06:13PM +0100, Leif Johansson wrote: We need to get this document out the door! Getting a few reviews would help a great deal! Overall the document is in good shape. In section 3 a sentence is truncated: 3.

Re: [Uta] Call for draft-ietf-uta-email-tls-certs-01 reviews

On 22/03/2015 15:49, Leif Johansson wrote: On 03/22/2015 04:10 PM, Alexey Melnikov wrote: On 19/03/2015 11:06, Leif Johansson wrote: Folks, We need to get this document out the door! Getting a few reviews would help a great deal! In the latest version I split the requirements into different

Re: [Uta] Call for draft-ietf-uta-email-tls-certs-01 reviews

On 19/03/2015 11:06, Leif Johansson wrote: Folks, We need to get this document out the door! Getting a few reviews would help a great deal! In the latest version I split the requirements into different sections talking about Mail User Agent implementors, Mail Service Providers and CAs. I

Re: [Uta] Call for draft-ietf-uta-email-tls-certs-01 reviews

Hi Victor, On 22/03/2015 19:37, Viktor Dukhovni wrote: On Sun, Mar 22, 2015 at 03:12:31PM +, Alexey Melnikov wrote: On 21/03/2015 07:38, Viktor Dukhovni wrote: On Thu, Mar 19, 2015 at 12:06:13PM +0100, Leif Johansson wrote: We need to get this document out the door! Getting a few

Re: [Uta] Call for draft-ietf-uta-email-tls-certs-01 reviews

Hi Viktor, On 22/03/2015 20:43, Viktor Dukhovni wrote: On Sun, Mar 22, 2015 at 08:34:56PM +, Alexey Melnikov wrote: Should use of _submission SRVNAMES be inferred from the target port? No. OK. Or enabled via per-destination configuration? I think direct

Re: [Uta] Splitting the draft? [was RE: draft-ietf-uta-email-deep-00 comments]

Hi Orit, On 02/03/2015 23:45, Orit Levin (LCA) wrote: During the last meeting, I expressed my opinion (as an individual, not as a chair) that it would be reasonable to split the draft into two: 1. A best current practices for e-mail document expanding the tls-bcp document and based on

Re: [Uta] (extra) WGLC for draft-ietf-uta-tls-bcp-07.txt

On 11 Nov 2014, at 14:52, Leif Johansson le...@sunet.se wrote: Since there were so many LC on draft-ietf-uta-tls-bcp-06.txt the chairs have decided to run an additional short WGLC on draft-ietf-uta-tls-bcp-07.txt Please make sure your comments have been addressed by reviewing the

Re: [Uta] Fwd: New Version Notification for draft-ietf-uta-tls-bcp-05.txt

On 22/10/2014 03:20, Peter Saint-Andre - yet wrote: On 10/14/14, 1:36 PM, Viktor Dukhovni wrote: On Tue, Oct 14, 2014 at 05:59:13PM +0300, Yaron Sheffer wrote: Thanks for your comments! I agree we SHOULD tone down a few of the requirements, to make sure we do accommodate the opportunistic

Re: [Uta] Review of draft-ietf-uta-tls-bcp-01

On 21/07/2014 22:47, Peter Saint-Andre wrote: On 7/21/14, 1:55 PM, Alexey Melnikov wrote: I've read this draft and I support its publication as a BCP. I have one minor issue: In 3.3, first paragraph: Combining unprotected and TLS-protected communication opens the way to SSL Stripping

Re: [Uta] verify host difference between HTTPS and SMTP+STARTTLS

Hi, On 17/06/2014 20:34, Franck Martin wrote: http://tools.ietf.org/html/rfc2818 in section 3.1 it defines the server identity... It does not seem there is the similar concept for SMTP with STARTTLS http://tools.ietf.org/html/rfc3207 This last text remains vague about server identity