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] 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. 

[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 require

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

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 http

[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 "MU

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 https://www.

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 (https://datatracker.ietf.org/doc/draft-ciphersuites-in-sec-syslog/).

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 com

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 betw

Re: [Uta] getting back to UTA and injecting clue

On 23/04/2014 02:29, Peter Saint-Andre wrote: Any thoughts on this path forward? I was also under the impression that we want to make quick progress on main documents and work on harder issues in parallel or even later revisions of them. On 3/26/14, 10:26 AM, Peter Saint-Andre wrote: On 3/1

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 verific

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

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 and similar attacks. In cases where an application protocol allows implementations or depl

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 Stri

Re: [Uta] Fwd: I-D Action: draft-ietf-tls-prohibiting-rc4-00.txt

On 30/07/2014 15:26, Sean Turner wrote: FYI - the TLS WG has adopted Andrei’s draft as a WG item. Please direct discussion about it to t...@ietf.org. From the pedantic department: I think you meant "t...@ietf.org". (But this is an excellent news otherwise :-)) spt Begin forwarded message:

Re: [Uta] Opportunistic TLS and draft-ietf-uta-tls-bcp-04

> On 5 Oct 2014, at 20:26, Yaron Sheffer wrote: > > So we could: > > 1. Say explicitly that opportunistic TLS is out of scope. > 2. Or say explicitly that it is in scope, and with the same requirements as > "regular" TLS. > 3. Or come up with a different set of requirements for opportunistic T

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] reminder: call for agenda items

Hi Leif, > On 3 Nov 2014, at 21:16, Leif Johansson wrote: > > We are currently looking at a pretty thin agenda for Honolulu. > > Agenda requests are not like wine: they don't improve with age. We should talk about Keith/Chris's document about use of TLS in email and latching, if either of the

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

> On 11 Nov 2014, at 14:52, Leif Johansson 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 > document. We

Re: [Uta] Recommendations for Secure Use of TLS and DTLS

> On 15 Nov 2014, at 14:51, Hannes Tschofenig wrote: > > Here is a suggestion: > > Title: "Recommendations for Secure Use of TLS in the Web" > > Abstract: > > Transport Layer Security (TLS) is widely used to protect data exchanged > over application protocols such as HTTP, SMTP, IMAP, POP, S

Re: [Uta] Brief summary of the UTA WG meeting @IETF 91, Honolulu

Hi Peter, On 26 Nov 2014, at 03:38, Peter Saint-Andre - &yet wrote: >>> This document is not an application profile standard, in the sense of >>>Section 9 of [RFC5246]. As a result, clients and servers are still >>>REQUIRED to support the mandatory TLS cipher suite, >>>TLS_RSA_WITH_

Re: [Uta] Brief summary of the UTA WG meeting @IETF 91, Honolulu

Hi Peter/Yaron, > On 2 Dec 2014, at 02:03, Peter Saint-Andre - &yet wrote: > >> On 11/26/14, 2:55 AM, Alexey Melnikov wrote: >> Hi Peter, >> >> On 26 Nov 2014, at 03:38, Peter Saint-Andre - &yet wrote: >> >>>>> This docum

Re: [Uta] Brief summary of the UTA WG meeting @IETF 91, Honolulu

Hi, On 2 Dec 2014, at 17:55, Yaron Sheffer wrote: >>> This document is not an application profile standard, in the sense of >>> Section 9 of [RFC5246]. As a result, clients and servers are still >>> REQUIRED to support the mandatory TLS cipher suite, >>> TLS_RSA_WITH_AES_1

Re: [Uta] Alissa Cooper's Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)

Hi Leif, On 18/02/2015 10:45, Leif Johansson wrote: On 02/17/2015 08:49 PM, Alissa Cooper wrote: [snip] -- DISCUSS: -- Thanks for all your work on this. I

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 e

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 found

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

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 Victor, On 22/03/2015 19:37, Viktor Dukhovni wrote: 2. MTAs are sometimes configured to act as submission clients. Most frequently on single-user machines. When should such an MTA use an SRVNAME reference identifier for the target SMTP server? To clarify, a typ

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 th

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 valid

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

Hi Sean, On 23/03/2015 20:42, Sean Turner wrote: I read version -02 and think it’s a fine document. One nit s/Certificate Authority/Certification Authority in s1 but you can fix that if anything else comes up. Fixed in my copy, thank you. ___ Uta

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

Hi Chris, Thank you for your review. On 03/04/2015 19:14, Chris Newman wrote: I've reviewed this document and support its advancement as is or with minor changes. Only nit I found is the SMTP Submission reference should be updated from 4409 to 6409. Done. One possible clarification, if you fe

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

Hi Brian, On 12/04/2015 00:08, Brian Smith wrote: Viktor Dukhovni wrote: Brian Smith wrote: That said, maybe I'm not understanding the importance of SRV-ID. Clarification of why supporting SRV-ID is important would be useful. My understanding is that clients should support SRV-ID when they l

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

On 15/04/2015 02:14, Brian Smith wrote: Viktor Dukhovni wrote: Brian Smith wrote: When the MUA connects to imap.gmail.com, how would the server know which certificate to give the MUA? Would the MUA put "_imap.example.com" in the SNI extension of the TLS ClientHello when connecting to the GMai

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 clien

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

On 12/04/2015 00:08, Brian Smith wrote: Are there any existing MUAs, certificate verification libraries, and/or mail servers that implement support for SRV and SRV-ID that can be used for interop testing? Has any interop testing been done yet? I think such interop testing should be done before SR

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

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

[Uta] draft-ietf-uta-email-deep-01 is ready for WGLC

Hi, I've reviewed changes between -01 and -00 and I think it is ready for WGLC. I have reviewed -00 earlier. Best Regards, Alexey ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

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

Hi Viktor, On 18/06/2015 17:02, Viktor Dukhovni wrote: On Wed, Jun 17, 2015 at 11:53:02AM +0100, Alexey Melnikov wrote: Filename: draft-ietf-uta-email-tls-certs-03.txt I believe this version addresses WGLC comments. Let me know if I've missed anything. Sorry, I've

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

Hi Stephen, On 20/11/2015 14:23, Stephen Farrell wrote: On 20/11/15 13:10, Eliot Lear wrote: Hi Stephen, Just on this point... On 11/20/15 1:53 PM, Stephen Farrell wrote: - I think the answer is "no," but I'll ask anyway:-) Many mail service providers use names like mail.example.com, smtp.ex

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 encour

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. > > C

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. Thank

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 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 between email and netnews.

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 u

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

Hi Harald, On 01/12/2015 14:34, Harald Alvestrand wrote: If I understand this draft correctly, I object. It says: 2. When using email service discovery procedure specified in [RFC6186] the client MUST also use the right hand side of the email address as another "reference

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 they

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 do

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

On 02/12/2015 15:40, John R Levine wrote: Given that there are mail services with tens of thousands of domains on the same set of servers, and probably at least one mail service with 100,000 domains, this really doesn't scale. Yes, I can add a note about this. Also recommending use of SNI (case

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 t

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] 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-07.txt

Victor, > On 14 Dec 2015, at 16:44, Viktor Dukhovni 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 datatracker status page for this draft is: >>>

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] 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 2

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 referenc

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 p

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

Hi Ben, On 17/12/2015 16:10, Ben Campbell wrote: On 17 Dec 2015, at 6:02, Alexey Melnikov wrote: and 6066 I think UTA DEEP document is going to talk more about use of SNI with TLS. I'm not sure how that changes things. While it's not a normative statement, it's one of t

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 Certificate

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 [R

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 extende

[Uta] SMTP Strict Transport Security - reporting

Speaking of reporting specifically: On 26 Mar 2016, at 00:45, Mark Risher wrote: >> it still requires a core MTA upgrade to the sender before it actually >> improves security for the domain...So I see no actual deployment benefit for >> the SMTP policy negotiation by putting it in DNS. > > Th

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

> On 1 Apr 2016, at 22:48, Chris Newman wrote: > > I’m open to proposals to advertise reporting information separately from (or > together with) SMTP security policy and to provide a mechanism to report SMTP > security without requiring SMTP security policy to be present. Given the > interest

Re: [Uta] STS directive registry: separate or shared?

Hi Chris, On 14/04/2016 17:54, Chris Newman wrote: Right now we have 3 STS proposals: HSTS, SMTP relay STS and MUA STS (DEEP). HSTS described its extensibility model, but punted on actually creating a registry. A registry covering HSTS would be useful because there’s at least one limited-use

Re: [Uta] Updated SMTP STS Draft

On 02/05/2016 23:27, John Levine wrote: Honestly I can't tell from the thread if there is consensus or not. I don't think it's perfect, but I do think the problem it addresses is real and the basic approach: publishing policies, and collecting reports about actual practices is sound. So yes, pl

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 on extensive experienc

Re: [Uta] MTA STS and HTTPS fetch timeouts

ine thing to say, but, IMHO, it should be said in addition to the above. > > What do you think? There's a tiny touch of bike-shedding to my comment above, > I admit, but if we didn't bikeshed we'd never decide what color to paint the > damn thing, amiright? > >

Re: [Uta] No meeting in Seoul... unless ...

> On 29 Sep 2016, at 19:18, Orit Levin wrote: > > The chairs haven’t got any requests towards the IETF meeting in Seoul. > We will not hold a f2f session in Seoul, unless we hear from you otherwise > TODAY. > Please, continue the discussion and the drafts’ revisions going on the list, > of cou

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". > Section 11.1 also does not gi

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

[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 MTA

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 present a X.509 certificate which

[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] Review of draft-ietf-uta-mta-sts-04

On 23/04/2017 12:58, Daniel Margolis wrote: Thanks. Comments inline, mostly ticking off changes. :) I have pushed all my changes in response to this to the git repo and they should appear in our next draft. On Wed, Apr 19, 2017 at 1:05 PM, Alexey Melnikov mailto:alexey.melni...@isode.com

Re: [Uta] IETF 99 Prague

On 11/05/2017 10:37, gerard.draper-...@ec.europa.eu wrote: Hi, I am not sure if it is too early to ask, or if it is the right list (I hope you will excuse me). Is there an UTA meeting planned for the next IETF 99 in Prague? Now is a good time. Face to face meeting in Prague can be requeste

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

You can treat these comments as WGLC comments: 4.4. JSON Report Schema The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. Section 3) { "organization-name": organization-name, "date-range": { "start-datetime": date-time,

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

s would be largely expanded, if ever. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast x5364 -Original Message- From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Alexey Melnikov Sent: Wednesday, June 28, 2017 6:03 AM To: uta@ietf.org Subject: [Uta] AD review of draft-ietf-uta-s

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 issues than Alexei

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

Hi Tom, > On 21 Jul 2017, at 18:34, tom p. wrote: > > Leif > > K/V > > Not something that I would expect to implement but rather my views are > based on tracking the work of NETCONF and RESTCONF, the latter being > JSON. I see the difficulties encounterd in the definition of RESTCONF > and am

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 support to exim. > >> O

[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. On

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

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 can't be used. Do you mean t

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. ___ Uta mailing

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. Should valid DKIM signature

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 wrote: >>> A better approach IMO would be to suggest the use of separate email >>>

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

On 20/07/2017 13:28, Chris Newman wrote: >> o "email-address": The contact information for a responsible party >> of the report. It is provided as a string formatted according to >> Section 3.4.1, "Addr-Spec", of [RFC5322]. > > Can we format according to the "Mailbox" rule in section

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 remov

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 of

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

Hi Jim, On 03/08/2017 06:01, Jim Fenton wrote: 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 sin

[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] 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 i

[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 Uta@ietf.org https://www.ietf.or

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 cl

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

On Tue, Oct 31, 2017, at 06:29 PM, Chris Newman wrote: > On 30 Oct 2017, at 19:30, Keith Moore wrote: > > After a bit more thought on this, I've concluded that using the mail > > server's server certificates to verify authenticity of SRV records > > probably isn't a good idea - or at least there

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 to have just one MIME typ

Re: [Uta] Updated TLSRPT

On 29/01/2018 16:17, Viktor Dukhovni wrote: On Jan 29, 2018, at 10:51 AM, Alexey Melnikov 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

  1   2   >