IMO RFC7525 and this new draft both suffer from dubious assumptions and
make poor recommendations because of those assumptions. In particular,
there are many cases for which using an old version of TLS is suboptimal
and it shouldn't be considered as secure, but it may still be better
than depr
On 5/1/20 12:27 PM, Ned Freed wrote:
IMO RFC7525 and this new draft both suffer from dubious assumptions and
make poor recommendations because of those assumptions. In particular,
there are many cases for which using an old version of TLS is suboptimal
and it shouldn't be considered as secure,
On 5/1/20 5:02 PM, Peter Saint-Andre wrote:
On 4/30/20 8:59 PM, Keith Moore wrote:
IMO RFC7525
That ship sailed in 2015.
IETF isn't bound by /stare decisis/.
I don't think we ever said anything to the contrary. BCP does stand for
*best* current practice, after all.
If BCP re
On 5/1/20 6:48 PM, Eric Rescorla wrote:
On Thu, Apr 30, 2020 at 7:59 PM Keith Moore
mailto:mo...@network-heretics.com>> wrote:
People do not always have the luxury of upgrading their clients and
servers to versions that support the recent TLS. Some legacy
hardware
On 5/3/20 3:14 PM, Eric Rescorla wrote:
I don't have much experience with SCADA TLS stacks, so I can't speak
to this, but I wasn't thinking primarily of the TLS stack itself but
just of the overall software on the device. In general, most software
has some defects and some of them will be secu
On 5/9/20 11:50 AM, Valery Smyslov wrote:
the chairs encourage WG members to more actively participate in the call.
At the meeting a lot of participants expressed a favor of adoption,
we ask these participants to reconfirm their position on the list (if they
didn't do it yet).
Since we wouldn'
Short version: this is, in many cases, a Bad Idea.
To the extent email delivery is reliable, it is because of persistence
in relaying traffic. Many mail user agents are not in a good position
to do that. It is generally better to submit the message to a service
that is well-connected and w
On 11/13/20 11:03 AM, Mikko Rantalainen wrote:
Keith Moore (2020-11-13 17:26 Europe/Helsinki):
To the extent email delivery is reliable, it is because of persistence
in relaying traffic. Many mail user agents are not in a good position
to do that. It is generally better to submit the
On 5/24/21 12:08 PM, Valery Smyslov wrote:
I also think that authors of original RFC should be contacted and
asked whether they want to co-author bis document (and one of errata
was reported by them).
IMO it's fine to contact the authors of an original RFC and point out
that an update is nee
On 5/31/21 3:37 PM, Salz, Rich wrote:
* IMO it's fine to contact the authors of an original RFC and point
out that an update is needed. But it's really presumptuous and
rude to appoint oneself a co-author of a bis document and suggest
that the original authors should become co-au
On 5/31/21 4:19 PM, Valery Smyslov wrote:
the 6125-bis draft has not been yet been issued, even the -00 version,
so it's a bit early for you
to make conclusions on selecting its authors. I agree with you that
it's best if original
authors take part in authoring -bis document and that's why
On 6/1/21 10:27 AM, Salz, Rich wrote:
After Valery’s suggestion I wrote to Jeff and Peter on May 24. No
reply yet, but it’s been a holiday weekend in the US.
This particular document was AD-sponsored, so perhaps Keith’s thoughts
are more applicable. For WG docs, however, another aspect to con
On 03/23/2014 06:32 PM, Michael Richardson wrote:
Keith Moore wrote:
> Note that as far as I can tell, it will still be possible to implement a
> client that supports only OE; it just doesn't bother verifying the cert /
> DNSSEC + TLSA record / pinned key / whatev
On 03/24/2014 11:44 AM, Michael Richardson wrote:
Keith Moore wrote:
> I strongly doubt that this is appropriate advice for all (or even most)
> applications or protocols. In particular, if there's some reason to
believe
> that a server intended to provide a v
On 03/24/2014 12:20 PM, Daniel Kahn Gillmor wrote:
On 03/24/2014 10:36 AM, Keith Moore wrote:
Yes, it's more work and expense for a site to maintain valid CA-signed
certs. But if clients complain when they're not there, providing
CA-signed certs becomes "part of the cost of
On 03/25/2014 04:09 PM, Trevor Perrin wrote:
On Mon, Mar 24, 2014 at 9:51 AM, Daniel Kahn Gillmor
wrote:
On 03/24/2014 12:36 PM, Keith Moore wrote:
So, what's the incentive for either clients or servers to support OE if
clients just silently accept it without any indication to the user?
On 03/25/2014 04:47 PM, Trevor Perrin wrote:
Please be cautious about suggesting user indications. UI is complicated and
>all that. More specifically in the browser case, even if you could strongly
>authenticate a connection over which you request ahttp:// page, I wouldn't
>want to give that pag
Of possible interest to this WG, or to the members of this WG, is
draft-moore-smtp-addrquery-01
Basically this is an extension to SMTP to allow mail exchangers to be
queried for information about the email addresses for which they accept
mail.
Such information could include public keys.
TLS is
John,
Thanks very much for the review. Comments inline.
On 07/21/2015 06:12 PM, John Levine wrote:
Basically this is an extension to SMTP to allow mail exchangers to be
queried for information about the email addresses for which they accept
mail.
Such information could include public keys.
TL
On 07/22/2015 01:59 AM, John Levine wrote:
Here's my use model: I set up my online access account at bigbank, and
give them the address john+bigb...@example.com. Then they fetch my
key and all the mail they send me is encrypted to my key.
I'm also thinking that we should avoid making the perfec
On 07/29/2015 06:02 PM, Viktor Dukhovni wrote:
On Wed, Jul 22, 2015 at 02:55:02AM -0400, Keith Moore wrote:
Clearly this draft isn't insisting on "very secure", as it's relying on TLS
certs and the model that any trusted CA is trusted for all domains, which is
already kn
On 07/30/2015 01:52 PM, Viktor Dukhovni wrote:
On Thu, Jul 30, 2015 at 11:34:43AM -0400, Keith Moore wrote:
The secret swept under the rug is that there is no security at all
in the provisioning process for DV certificates.
Ok, I agree with you there. A DNSSEC signature is not less reliable
On 07/31/2015 11:28 AM, Viktor Dukhovni wrote:
On Thu, Jul 30, 2015 at 04:02:58PM -0400, Keith Moore wrote:
And finally, the idea that a DNS client
could simply trust its local resolver to do DNSSEC validation for it never
made any sense at all.
Perhaps you're using the phrase "loca
On 07/31/2015 04:33 PM, Viktor Dukhovni wrote:
On Fri, Jul 31, 2015 at 02:23:25PM -0400, Keith Moore wrote:
Perhaps you're using the phrase "local resolver" in some novel way
that I don't understand. Why shouldn't an application trust
responses from 127.0.0.1:53?
T
On 08/01/2015 01:14 AM, Viktor Dukhovni wrote:
On Fri, Jul 31, 2015 at 06:49:59PM -0400, Keith Moore wrote:
They'd also need new SMTP software to support
AQRY. That software would need to be well maintained too. I trust
the DNSSEC validation code in unbound and BIND more than I would
On 03/30/2017 05:26 PM, Jim Fenton wrote:
[removing saag list because this is probably at a lower level of
detail than appropriate there. But feel free to add them if I'm wrong]
My sense that there is a "BCP part" to the draft is probably more
clearly stated that there are really two differe
After thinking about this a bit, it seems to me that if any portions of
draft-ietf-email-deep should be BCP, it's those that describe
requirements for MSPs. Those are indeed practice, not protocol.
In the interest of expediency, I'd be fine with making those portions of
MUA-STS non-normative
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.
A few minor comments:
1. Introduction
This memo does not address use of TLS with SMTP for message relay
(where Message Submission [RFC6409]
On 07/25/2017 02:56 AM, Alexey Melnikov wrote:
Use of pinned certs isn't forbidden by the draft, but pinned certs don't
meet minimum confidentiality requirements.
I think it might be possible to adequately address the security concerns
associated with the usual implementation of pinned certifica
: Keith Moore
Chris Newman
Filename: draft-ietf-uta-email-deep-09.txt
Pages : 28
Date: 2017-09-12
Abstract:
This specification outlines current recommendations for use of
Transport Layer Security (TLS) to provide
Thanks for the review. Comments below:
On 10/16/2017 01:18 AM, Roni Even wrote:
Reviewer: Roni Even
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.
Thanks for the review. Comments inline:
On 10/16/2017 12:55 PM, Carlos Pignataro wrote:
Reviewer: Carlos Pignataro
Review result: Has Nits
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
co
--
COMMENT:
--
The document reads like a BCP to me. Was it discussed in the group to go for
BCP? If yes, why was it decided to go not for BCP? If no, I would str
--
COMMENT:
--
Balloting "Yes" because I think this is a very welcome and important update to
its antecedent documents -- but I think there are a few simple chan
(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 want to say RECOMMENDED?
Lower case "recommends" (n
--
COMMENT:
--
I am balloting YES because I believe it is important to publish this. But there
are a few issues I think should be resolved first:
Substantive
On 10/25/2017 06:29 PM, Eric Rescorla wrote:
dh-group = ALPHA *(ALPHA / DIGIT / "_")
I might want to include hyphen here because "P-256"
done.
Line 405
implementation does not know the name of the cipher suite (a
situation that should be re
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 are checking against (which 6186 gets right)
but
> On Oct 27, 2017, at 7:48 AM, Eric Rescorla wrote:
>
> The entire principle here is that (absent DNSSEC) TLS operates on what was
> fed into the client.
Could you elaborate a bit? I feel like I'm missing some context.
Thanks,
Keith
___
Uta mai
I've taken a stab at writing a non-normative appendix explaining this.
-
Appendix. Use of Server Name Indication (SNI) in conjunction with SRV
records
This section attempts to explain the considerations involved when using
SNI in conjunction with SRV records, because
of
Chris's suggestion. I think that's the best we can do in a short time
without additional review cycles.
Keith
On 10/28/2017 06:45 AM, Keith Moore wrote:
I've taken a stab at writing a non-normative appendix explaining this.
-
Appendix
On Jan 29, 2018, at 10:51 AM, Alexey Melnikov wrote:
> 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 th
No. You don't violate 27 years of practice based on any number of tests that
this WG is capable of doing, just to avoid defining two content-types.
Sent from my iPhone
> On Jan 31, 2018, at 2:25 PM, James Cloos wrote:
>
> FWIW, I tried sending myself a gzip(1)ed json file using:
>
> Content
IMO if you want to define application/tlsrpt in such a way that
readers/processors can reliably distinguish between clear text JSON and gzipped
JSON , say by looking at the first few bytes of the content for the header
magic number indicating gzip compression, you're free to do so. You just can
This looks ok to me. I concur with the reasoning in the document.
- Keith
On 11/8/18 12:52 AM, Valery Smyslov wrote:
Hi,
the chairs received a request for adoption of
draft-lvelvindron-tls-for-email-02 [1] as UTA WG document.
The draft seems to be in scope of UTA WG and follows the IETF trend
1. I especially appreciate this document being expressed as deltas to
RFC 8314, as I believe this makes it much easier for a reader
(especially an implementor or mail service operator) to understand
exactly what's being changed.
2. For existing accounts that have already been established bet
body of
recommendations.
Keith
On 11/27/18 9:35 PM, Keith Moore wrote:
1. I especially appreciate this document being expressed as deltas to
RFC 8314, as I believe this makes it much easier for a reader
(especially an implementor or mail service operator) to understand
exactly what's
On 12/2/19 1:57 AM, Valery Smyslov wrote:
Hi,
this message starts a two weeks long Working Group Last Call for
draft-ietf-uta-tls-for-email-03.
The Last Call will end 16 December 2019. Please, send your opinions regarding
publication of the draft to the list before this date (even if you have
On 2/18/20 11:53 PM, Suresh Krishnan via Datatracker wrote:
I think the following text from Section 4.1 of RFC8314 needs to be updated as
well. Is there any reason this is left out?
Transition of users from SSL or TLS 1.0 to later versions of TLS MAY
be accomplished by a means similar t
49 matches
Mail list logo
