The basic issue is Email has two critically important properties that
make it uniquely useful despite the age of the service and the cruft
that has accumulated due to that age:
1. decentralized control
2. communication without introduction
If you don't preserve these two properties, then what
I've read this draft. Overall, I support publication of this draft or a revised
version as a BCP.
Minor issues (not issues I consider blocking):
* I'd like a single list/table of TLS extensions that implementers/operators
need to consider seriously included. It's fine if it just includes referenc
--On June 19, 2014 18:11:55 -0400 "Salz, Rich" wrote:
> I think almost every section should have a rationale. For example, 3.5 could
> say "because it's at the wrong layer and has been the subject of security
> weaknesses" :)
My editorial preference is to have rationale separated into an Appendi
I've reviewed draft-ietf-uta-tls-attacks-01.txt and support its publication. I
believe the document would be improved by including CVE numbers for the
vulnerabilities in the document.
I had volunteered to write text describing the STARTTLS attack. Here's strawman
text:
---
2.9 STARTTLS Command In
--On July 21, 2014 16:16:07 -0600 Peter Saint-Andre wrote:
> Hi Chris, thanks for the proposed text. That's always appreciated.
>
> On 7/21/14, 6:46 PM, Chris Newman wrote:
>> I've reviewed draft-ietf-uta-tls-attacks-01.txt and support its publication.
>> I believe
--On August 18, 2014 9:55:19 +0200 Leif Johansson wrote:
> This starts a 2 week working group last call on
> draft-ietf-uta-tls-attacks-02. Please send any final comments on the
> list by 1/9.
I had previously spent the time to write suggested text for the draft (message
attached).
It seems that
--On August 18, 2014 20:30:08 +0200 Leif Johansson wrote:
> On 2014-08-18 20:01, Chris Newman wrote:
>> --On August 18, 2014 9:55:19 +0200 Leif Johansson wrote:
>>> This starts a 2 week working group last call on
>>> draft-ietf-uta-tls-attacks-02. Please send any fin
--On August 30, 2014 10:48:28 +0200 Leif Johansson wrote:
> On 2014-08-30 08:39, Yaron Sheffer wrote:
>> I am fine with this text.
>>
>
> OK then I think its fine for you to deal with this as any WGLC comment -
> just include it in your final IETF-LC version.
Assuming this is done, I withdraw m
--On September 3, 2014 19:42:32 +0200 Ralph Holz wrote:
> Good day,
>
> I have solicited some feedback on the wording in 4.1, the MUST NOT on
> selecting the NULL cipher. I have feedback from members of the TLS WG,
> and from operators of Grid centres. My fear was that MUST NOTing the
> NULL ciph
I noticed this reference:
> current document. See Section 2.5 of [I-D.ietf-uta-tls-attacks] for
Is pointing to the wrong section; should be 2.6.
- Chris
--On November 11, 2014 7:14:00 -0700 Peter Saint-Andre - &yet
wrote:
> FYI. The authors believe that this version address
--On November 13, 2014 5:30:10 +0100 Leif Johansson wrote:
>> Your clarifications seem helpful to me, thanks!
>>
>>> I am content with all my other feedback being ignored, as it is less
>>> important.
>>
>> OK. But I for one will look at it more closely soon.
>>
>
> Since we are out of WGLC I
--On March 2, 2015 23:45:40 + "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
I'm not clear on what is "new" vs. what is "bcp" from your perspective. I can't
find a clear division. I am open to re-organizing the document to improve
clarity if there are specific suggestions to do so.
Although DEEP is about the single subject of improving confidentiality for MUA
to server con
--On March 23, 2015 13:51:16 +0100 Leif Johansson wrote:
> On 03/23/2015 06:30 AM, Chris Newman wrote:
>> I'm not clear on what is "new" vs. what is "bcp" from your perspective. I
>> can't find a clear division. I am open to re-organizing the documen
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.
One possible clarification, if you feel like it:
_imap.example.net SRV-ID is needed to use STARTTLS on the imap port
_imap
I should be able to do a revision late November.
- Chris
On November 3, 2015 at 21:42:57 , Orit Levin (LCA) (or...@microsoft.com) wrote:
Thanks, Aaron.
Actually, I am not sure that we are looking at the right document yet.
draft-ietf-uta-email-deep-01 was posted just before the
On March 11, 2016 at 1:40:36 , Jeremy Harris (j...@wizmail.org) wrote:
> On 11/03/16 06:13, internet-dra...@ietf.org wrote:
> > Filename : draft-ietf-uta-email-deep-02.txt
>
> 4.3 para 2: "It is desirable to migrate MUA
> software to implicit TLS over time for consistency as well as the
> reason
On March 11, 2016 at 13:34:03 , Julien ÉLIE (jul...@trigofacile.com) wrote:
Hi all,
Here are a few remarks:
5.1. Email Security Tags
Each security latch is given a name known as an email security tag.
An email security tag is a short alphanumeric token that represents a
security facility th
On March 13, 2016 at 10:32:03 , Aaron Zauner (a...@azet.org) wrote:
Hi,
Excellent to see that there's renewed progress with this (important) document!
I will be looking over the document again in the next few days a couple of
times, I've just reviewed the diff and this came to mind:
Appendix
Has the security area produced any published text describing the general
benefits of implicit vs. STARTTLS? I can’t exactly reference a discussion on
IETF/crypto-protocol-security.
There is existing text in the main document (as opposed to the non-normative
appendix) that favors implicit TLS. I
s is
published. The second one, is to record additional information, i.e. the
server's capabilities (or policy) for potential client's upgrade in the future?
Is that correct?
Yes.
- Chris
From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Chris Newman
Sent: Friday,
This document is providing STS functionality for SMTP relay, while DEEP is
providing STS functionality for SMTP submission (plus IMAP & POP). I believe
it’s important to align these two proposals and am open to changing DEEP to do
so (https://tools.ietf.org/html/draft-ietf-uta-email-deep-04).
N
nable points about
using the DEEP policy framework (which I will read up on), changing the
reporting syntax, and recording cipher usage. I have questions for you below on
some of the other points.
Thanks.
On Thu, Mar 24, 2016 at 4:44 AM, Chris Newman wrote:
This document is providin
44 AM, Chris Newman wrote:
This document is providing STS functionality for SMTP relay, while DEEP is
providing STS functionality for SMTP submission (plus IMAP & POP). I believe
it’s important to align these two proposals and am open to changing DEEP to do
so (https://tools.ietf.org/html/d
On March 24, 2016 at 12:42:07 , Jim Fenton (fen...@bluepopcorn.net) 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-fenton-smtp-require-tls-01. There has been some
discussion of this
are
added.
- Chris
Thanks for the comments,
/m
--
Mark E. Risher | Group Product Manager | ris...@google.com |
650-253-3123
On Fri, Mar 25, 2016 at 2:28 PM, Chris Newman wrote:
On March 23, 2016 at 18:45:45 , Daniel Margolis (dmargo...@google.com) wr
I’m unconvinced by these two design reasoning documents.
They start with the assumption that signed routing information, security policy
and reporting should be conflated. I consider those separate functions. The
only relationship between signed routing and security policy is that security
poli
On April 1, 2016 at 19:18:31 , Viktor Dukhovni (ietf-d...@dukhovni.org) 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. Doing anything else creates a much
y
effectively.
- Chris
On Mon, Apr 4, 2016 at 6:27 AM, Chris Newman wrote:
On April 1, 2016 at 19:18:31 , Viktor Dukhovni (ietf-d...@dukhovni.org) wrote:
On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote:
> I feel very strongly that policy for SMTP relay should
successful SPF is in practice — our server
implements it but I don’t hear much customer traffic about it.
- Chris
Thanks for the feedback. Looking forward to the face to face in a few hours,
/m
---
Mark Risher | Google | 650-253-3123
On Apr 4, 2016 10:44 AM, "Chris Newman"
DANE is merely one method of validating a certificate, there can also be SMTP
policy orthogonal to DANE. Take for example, DEEP’s “tls11” and “tls12”
directives. Those specify a minimum acceptable version of TLS for future
connections. Although we haven’t debated yet whether to include those in
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 directive in the wild in addition to those in the HSTS
On April 14, 2016 at 22:38:23 , Jim Fenton
(fen...@bluepopcorn.net(mailto:fen...@bluepopcorn.net)) wrote:
> On 4/13/16 10:43 AM, Chris Newman wrote:
> > DANE is merely one method of validating a certificate, there can also be
> > SMTP policy orthogonal to DANE. Take for example
On April 17, 2016 at 13:45:24 , Jim Fenton
(fen...@bluepopcorn.net(mailto:fen...@bluepopcorn.net)) wrote:
> On 4/16/16 10:23 AM, Chris Newman wrote:
> >
> >>> So while Viktor made a compelling case that the TLS version directive is
> >>> not appropri
I am opposed to using CBOR. CBOR is not well deployed. Most codebases need XML
and JSON parsers but do not need CBOR parsers. So choosing CBOR significantly
increases the code complexity. My codebase has a JSON and XML parser but no
CBOR parser. I would strongly prefer to keep it that way, so CB
On May 9, 2016 at 9:56:17 , Viktor Dukhovni
(ietf-d...@dukhovni.org(mailto:ietf-d...@dukhovni.org)) wrote:
> > On the other hand, you can set up out of band reporting with a DNS
> > record pointing to the URL, and a little mail handling script or web
> > CGI script to accept all of your repor
On May 10, 2016 at 13:06:12 , Viktor Dukhovni wrote:
> On Tue, May 10, 2016 at 12:56:54PM -0700, Daniel Margolis wrote:
>
> > Agreed; makes sense to me. I'm not sure if it makes sense to extend the
> > DEEP-specific reporting to cover this case; it may be easier to just draft
> > a short separa
The report is composed as a plain text file encoded in the JSON
format ([RFC7159]).
Can we use I-JSON format instead? RFC 7493. I'd prefer if the report is
encoded in UTF-8 rather than an arbitrary Unicode encoding that the
recipient has to dynamically detect.
o "email-address": The
Overall, I find the document hard to read and the structure problematic.
If I'm verifying STS policy, I want to know how to fetch the policy,
then I want to know what to fetch. The document structure is awkward for
that goal. And if I want to publish STS policy, I want to know where I
publish i
On 20 Jul 2017, at 20:54, Daniel Margolis wrote:
Hey, Chris,
Thanks for the thorough review. A few inline comments off the cuff;
others
we will have to address in the draft.
On Thu, Jul 20, 2017 at 6:02 PM, Chris Newman
wrote:
Overall, I find the document hard to read and the structure
On 29 Sep 2017, at 11:34, Stephan Bosch wrote:
Hi,
Op 9/29/2017 om 5:54 PM schreef The IESG:
The IESG has received a request from the Using TLS in Applications WG
(uta)
to consider the following document: - 'Cleartext Considered Obsolete:
Use of
TLS for Email Submission and
Access'
as P
On 23 Oct 2017, at 21:13, Keith Moore wrote:
--
COMMENT:
--
Balloting "Yes" because I think this is a very welcome and important
update to
its antecedent do
On 25 Oct 2017, at 3:48, Keith Moore wrote:
--
COMMENT:
--
I am balloting YES because I believe it is important to publish this.
But there
are a few issues I
On 24 Oct 2017, at 17:31, Keith Moore wrote:
(inline)
Line 186
TLS, and to encourage a greater consistency for how TLS is used,
this
specification now recommends use of Implicit TLS for POP, IMAP,
SMTP
Submission, and all other protocols used between a Mail User
Agent
Do you
On 26 Oct 2017, at 19:56, Keith Moore wrote:
On 10/26/2017 07:18 PM, Chris Newman wrote:
Line 304
preference to services supporting STARTTLS (if
offered). (See
also Section 4.5.)
I note that 6186 is kind of unclear on what should go in SNI. It
obviously
needs to be what you
On 27 Oct 2017, at 11:34, Eric Rescorla wrote:
On Fri, Oct 27, 2017 at 11:03 AM, Chris Newman
wrote:
On 26 Oct 2017, at 19:56, Keith Moore wrote:
On 10/26/2017 07:18 PM, Chris Newman wrote:
Line 304
preference to services supporting STARTTLS (if offered).
(See
also
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 are more considerations
and pitfalls than can reasonably be thought
Overall, this is in much better shape than the last time I reviewed the
document (-07). I agree with several of Alexey's issues but won't repeat
them. I have some minor concerns with the level of requirement for SNI,
and I think the security considerations should be improved.
When I reviewed -
On 21 Mar 2018, at 20:10, Chris Newman wrote:
Section 8.2
My analysis of section 8.2 is wrong and I withdraw the comment. Serves
me right for trying to do a quick security analysis during the plenary
while jet lagged. :-)
I'm going to continue to think about the relationship between
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
London. There were also inconsistencies in the header field name
(Require-TLS vs. RequireTLS) so I chose the latter.
On 11 Apr 2018, at 14:29, Jim Fenton wrote:
Thanks for your review, Chris:
On 4/9/18 6:08 PM, Chris Newman wrote:
3. The IANA considerations are incomplete. For example, they are
missing fields required to register in the SMTP mail system response
codes registry. See RFC 5248. I'm not
On 14 Sep 2018, at 12:59, Jim Fenton wrote:
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 suggestio
On 14 Jan 2019, at 20:43, Grant Taylor wrote:
On 1/14/19 8:29 PM, John Levine wrote:
When the ABNF about extended-domain was written with the comment
about info derived from the TCP connection, the TCP connection was
synonymous with the transport.
I don't accept that at face value.
IANA has
On 24 Jan 2019, at 11:56, John R Levine wrote:
Apropos of recent discussions about SNI logging, here's a draft that
adds an SNI clause to Received: headers, and per Chris Newman's
suggestion, changes the registry criteria to Expert Review so you
don't need to publish an RFC merely to register a
54 matches
Mail list logo
