Re: [Uta] Warren Kumari's Discuss on draft-ietf-uta-smtp-tlsrpt-18: (with DISCUSS)

Confirmed, and updated the doc with the RFC reference. On Mon, Apr 16, 2018 at 11:39 AM, Viktor Dukhovni wrote: > > > > On Apr 16, 2018, at 2:24 PM, Warren Kumari wrote: > > > >> Strings in TXT records have a single-octet length field. When returning

Re: [Uta] **SPAM** Mirja Kühlewind's No Objection on draft-ietf-uta-smtp-tlsrpt-18: (with COMMENT)

Thank you Mirja. 'rua' is defined in Section 3 (Reporting Policy). Would that be sufficient? In fact "Aggregate report URI" is borrowed from DMARC. -binu On Wed, Apr 18, 2018 at 6:09 AM, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position

[Uta] Adam Roach's Yes on draft-ietf-uta-smtp-tlsrpt-18: (with COMMENT)

Adam Roach has entered the following ballot position for draft-ietf-uta-smtp-tlsrpt-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [Uta] is it time for 7525bis?

> On Apr 18, 2018, at 4:39 PM, Stephen Farrell > wrote: > >> Waiting until DTLS 1.3 is finished seems like a good idea. > > Agreed. And for TLS 1.3 interoperability to be sorted out with the passage of time. I noted in the thread about SNI and MTA-STS, the

Re: [Uta] [Gen-art] Genart telechat review of draft-ietf-uta-smtp-tlsrpt-18

Joel, thanks for your review. From the thread about Ben’s DISCUSS it looks like text to clarify the point about ignoring certificate validation errors may be forthcoming. I have noted this in my No Objection ballot and asked the authors to review your other points. Alissa > On Apr 5, 2018, at

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

Alissa Cooper has entered the following ballot position for draft-ietf-uta-smtp-tlsrpt-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [Uta] is it time for 7525bis?

On 4/18/18 2:39 PM, Stephen Farrell wrote: > > Hiya, > > On 18/04/18 21:13, Peter Saint-Andre wrote: >> On 4/17/18 3:37 PM, Stephen Farrell wrote: >>> >>> >>> On 17/04/18 16:22, Peter Saint-Andre wrote: During ART-ART and IESG review of draft-ietf-tram-stunbis, we realized that just

Re: [Uta] is it time for 7525bis?

Hiya, On 18/04/18 21:13, Peter Saint-Andre wrote: > On 4/17/18 3:37 PM, Stephen Farrell wrote: >> >> >> On 17/04/18 16:22, Peter Saint-Andre wrote: >>> During ART-ART and IESG review of draft-ietf-tram-stunbis, we realized >>> that just pointing to RFC 7525 might not be enough anymore, now that

Re: [Uta] is it time for 7525bis?

On 4/17/18 3:37 PM, Stephen Farrell wrote: > > > On 17/04/18 16:22, Peter Saint-Andre wrote: >> During ART-ART and IESG review of draft-ietf-tram-stunbis, we realized >> that just pointing to RFC 7525 might not be enough anymore, now that the >> TLS 1.3 spec has been approved for publication.

Re: [Uta] Ben Campbell's Discuss on draft-ietf-uta-smtp-tlsrpt-18: (with DISCUSS and COMMENT)

For the DISCUSS section: We did note that the reports could be made to be submitted elsewhere via hijacked DNS, as you've noted. I don't believe that an expired or self-signed certificate from the HTTPS endpoint should be a reason to stop the submission, so we can leave it to the submitter.

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

Thank you for the correction, the IPs have been altered now. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast -Original Message- From: Suresh Krishnan [mailto:sur...@kaloom.com] Sent: Tuesday, April 17, 2018 10:44 PM To: The IESG Cc: draft-ietf-uta-smtp-tls...@ietf.org;

Re: [Uta] SNI text from 7672

> On Apr 18, 2018, at 11:54 AM, Daniel Margolis wrote: > > How is it counter-intuitive? TLS 1.3 requires SNI, no? No, TLS 1.3, *does not* require SNI. SNI is mandatory to implement, but NOT mandatory to use:

Re: [Uta] SNI text from 7672

On Wed, Apr 18, 2018 at 03:54:14PM +, Daniel Margolis wrote: > > How is it counter-intuitive? TLS 1.3 requires SNI, no? No, it does not. - The server MAY require SNI. - The client SHOULD send SNI. - If the server requires SNI and client does not send one, the server SHOULD send

Re: [Uta] SNI text from 7672

> On Apr 18, 2018, at 11:18 AM, Daniel Margolis wrote: > > Thanks. I think this is consistent with what was added here: > https://github.com/mrisher/smtp-sts/blob/master/mta-sts.txt#L633. If not, let > me know. Looks largely fine to me. I am not fond of the

Re: [Uta] Ben Campbell's Discuss on draft-ietf-uta-smtp-tlsrpt-18: (with DISCUSS and COMMENT)

Hey. Thanks for the feedback. On Mon, Apr 16, 2018 at 6:10 AM Ben Campbell wrote: > > -- > DISCUSS: > -- > > I plan to ballot "Yes" for this,

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

Apologies for the slow reply here. (I was on vacation.) Ned: thanks for the clear summary. I'll start working on those issues. Dave: thanks also for the direct feedback. To be honest, though, after all this discussion, I'm somewhat struggling to sort out what's actionable from what isn't, as I

Re: [Uta] SNI text from 7672

Thanks. I think this is consistent with what was added here: https://github.com/mrisher/smtp-sts/blob/master/mta-sts.txt#L633. If not, let me know. Thanks again. On Fri, Mar 23, 2018 at 12:38 AM Viktor Dukhovni wrote: > > > > On Mar 22, 2018, at 4:17 PM, Daniel Kahn

[Uta] Mirja Kühlewind's No Objection on draft-ietf-uta-smtp-tlsrpt-18: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for draft-ietf-uta-smtp-tlsrpt-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer