On Fri, Nov 17, 2023 at 09:11:40PM +0100, Mechiel Lukkien wrote:
> Alex wrote:
> > TLSRPT is going to look for its information at _smtp._tls. > domain>. That same should be the policy-domain in
> > the report. The domain for the MTA-STS/DANE policies may be
> > different such as you mentioned
On Tue, Nov 14, 2023 at 03:39:21PM +0100, Mechiel Lukkien wrote:
> I'm implementing (outgoing) SMTP TLS reporting (RFC 8460) in my mail
> server (https://github.com/mjl-/mox) and am getting confused by
> TLSRPT's use of "domain"/"recipient domain"/"policy domain",
> especially related to DANE. It
On Tue, Sep 19, 2023 at 07:25:51AM -0400, Chris Lonvick wrote:
> I think that the changes to Sections 4 and 5 should be limited to
> replacing "MUST NOT" with "SHOULD NOT". That will provide clear
> guidance for implementers.
>
> I was then thinking of changing the Security Considerations
On Wed, Sep 06, 2023 at 12:53:39PM -0400, Chris Lonvick wrote:
> Hi Viktor and all,
>
> I see your point.
>
> How about if the phrases "MUST NOT offer TLS_RSA_WITH_AES_128_CBC_SHA" in
> Sections 4 and 5 be changed to "SHOULD NOT offer..."?
>
> This seems to be more consistent with Section
On Mon, Aug 21, 2023 at 07:16:01AM -0400, Chris Lonvick wrote:
> We think that this version is ready for WG Last Call. Would the members of
> the WG please review and let us know (on the WG list) if there are any
> objections?
>
The draft looks clear enough. My main concern is not with
On Thu, Jun 22, 2023 at 09:45:30AM +0200, Petr Špaček wrote:
> > I am confused, because I thought an IP address *was* a DNS name.
>
> It is, but the implication works only in one direction.
>
> Here's my reasoning:
>
> - Text representation of an IP address is a syntactically valid text
>
On Wed, Jun 21, 2023 at 08:25:55PM +, Salz, Rich wrote:
> > No, IP addresses are not DNS names. And IP address SANs are octet
> > strings, 4 bytes for IPv4 and 16 bytes for IPv6.
>
> So I tweaked the last part of section 6.4:
> This document does not specify how an SRV-ID reference identity
On Wed, Jun 21, 2023 at 07:46:01PM +, Salz, Rich wrote:
> I have made the other changes, just seeking clarification on one point.
>
> >> 6.4. Matching an IP Address Portion
> >> This document does not specify how an SRV-ID reference identity can include
> >> an IP address.
>
> > I think
On Sun, Mar 26, 2023 at 04:34:15PM -0700, Rob Sayre wrote:
> I think I will not raise any objection to draft-ietf-uta-rfc6125bis. I
> might write a different draft that says "all of the IETF IDNA documents are
> misleading, the internet runs on UTS-46", but that is not specific to this
> draft.
On Thu, Mar 02, 2023 at 11:06:24AM -0700, Peter Saint-Andre wrote:
> The authors hope that this version is now ready to move forward.
Just a quick comment:
As specified in Section 6.3, restricting the presented identifiers in
wildcard character (e.g., \*.example.com but not
On Thu, Feb 16, 2023 at 03:48:30PM +0300, Valery Smyslov wrote:
> But how does this knowledge help implementers to properly implement
> matching IDNs against the names in certificates, which is performed
> using A-labels?
Not at all, because the problems with IDNs don't happen at the
certificate
On Tue, Feb 07, 2023 at 07:31:56PM -0700, Peter Saint-Andre wrote:
> > So I think a better example is to either use the term "delegated"
> > when it really talks about DNS delegation, OR, you use a different
> > term but have an example where you can have:
> >
> > - IMAP server: imap.example.se.
On Wed, Feb 01, 2023 at 11:37:51AM +0300, Valery Smyslov wrote:
> this message starts a one week consensus call for the following
> proposed changes to draft-ietf-uta-rfc6125bis-10. The call
> will end on Thursday, 9 February.
Though I coughed a small part of the suggested text, I am not
On Mon, Jan 30, 2023 at 10:48:42AM -0800, Rob Sayre wrote:
> Current:
> ---
> An "internationalized domain name", i.e., a DNS domain name that includes
> at least one label containing appropriately encoded Unicode code points
> outside the traditional US-ASCII range and conforming to the
On Sun, Jan 29, 2023 at 09:49:55AM -0800, Rob Sayre wrote:
> That all sounds reasonable. But isn't this WG being incredibly intransigent
> by default?
It seems to me that It remains the case that this I-D is not the best
forum to litigate which U-labels are valid candidates for turning into
On Sun, Jan 29, 2023 at 12:19:55PM +1000, Patrik Fältström wrote:
> Because of this, my conclusion is that what we need is not select
> IDNA2008 or UTS#46. We need someone to write down how a conservative
> software developer do use unicode characters in various places of a
> software, protocol
On Sat, Jan 28, 2023 at 05:26:24PM -0500, John C Klensin wrote:
Thanks for the clear and detailed exposition of the status quo.
Just one nit:
> (ii) Special character interpretations given by IDNA2003 but
> removed by IDNA2008, notably including the mapping of Eszett
> (Sharp S, U+00DF) to "ss"
On Sat, Jan 28, 2023 at 10:49:45AM -0800, Rob Sayre wrote:
> Viktor Dukhovni wrote:
> > Finally, it is still unclear why any of this is an issue for this work.
>
> I agree that this is a valid, if somewhat uniformative, way to approach the
> issue. That's why I ment
On Sat, Jan 28, 2023 at 10:12:37AM -0800, Rob Sayre wrote:
> So far we've found Chrome and Postfix, just to name a few examples, using
> UTS-46. I think the draft is overstating the influence of IDNA2008. After
> all, it's 14-15 years old, and things have changed. But, as Orie notes,
> there are
On 26/1/2023 7:58 pm, Rob Sayre wrote:
For instance, ☕.example becomes xn--53h.example and not failure.
[UTS46] [RFC5890]"
Yes, thus, for example, Postfix via libicu (my terminal doesn't actually
display "☕", but it was part of the input argument anyway):
$ posttls-finger "☕.example"
On Tue, Jan 24, 2023 at 10:41:08PM -0800, Rob Sayre wrote:
> Then, I would match any mention of "web browsers" with examples of
> implementations that do things another way. I suspect this approach might
> make for difficult writing, because I don't think anyone diverges from the
> browser
On Tue, Dec 27, 2022 at 03:31:37PM +0300, Valery Smyslov wrote:
> From: John C Klensin [mailto:john-i...@jck.com]
>
> (2) The document makes several references to URIs, but only RFC
> 3986 appears to be referenced. In the real world in which
> certificates are established and used and in which
On Sat, Jul 09, 2022 at 02:30:03PM -0600, Cullen Jennings wrote:
> and there is a section labeled "TLS, old and new” which has a table that
> lists TLS 1.1 at zero.
>
> It also references a more specific file at
> https://crawler.ninja/files/protocols.txt which currently has the following
>
On Thu, Jul 14, 2022 at 10:05:37AM -0700, Rob Sayre wrote:
> > If someone wrote a new app implementation and follows this advise by
> > only implementing TLS 1.3, how well would it interoperate with existing
> > apps/servers it needs to talk to? I feel this would not go well.
>
> It would likely
On Mon, Jun 27, 2022 at 04:31:25PM -0600, Peter Saint-Andre wrote:
> >> I'm not necessarily saying that - I'm saying only that Jeff and I tried
> >> to find a canonical definition of "fully-qualified domain name" and the
> >> best we could do was RFC 1034. Alternative proposals are welcome.
> >
On Mon, Jun 27, 2022 at 02:37:22PM -0600, Peter Saint-Andre wrote:
> > It does for the majority of the certificate usages, but in practice
> > today DANE is primarily used with SMTP, and predominantly with
> > DANE-EE(3) TLSA records, in which case identity questions are settleda
> > at the DNS
On Mon, Jun 27, 2022 at 02:43:43PM -0600, Peter Saint-Andre wrote:
> On 6/27/22 1:08 PM, Viktor Dukhovni wrote:
> > On Mon, Jun 27, 2022 at 12:52:00PM -0600, Peter Saint-Andre wrote:
> >
> >>> Yep, we can punt the definition but then we need to address all the
>
On Mon, Jun 27, 2022 at 12:52:00PM -0600, Peter Saint-Andre wrote:
> > Yep, we can punt the definition but then we need to address all the special
> > cases.
>
> I would prefer to bring back the reference to RFC 1034.
A DNS FQDN is sequence of dot-separated labels each of whose wire forms
is
On Mon, Jun 27, 2022 at 05:15:09PM +, Salz, Rich wrote:
> Does a DANE certificate have the same "name" as a non-DANE
> certificate?
Yes, the name is a DNS name, and for DANE certificate usages PKIX-TA(0),
PKIX-EE(1) and DANE-TA(2) the same logic applies to the EE certificate
as in PKIX with
On Sat, Jun 25, 2022 at 10:13:28PM +0300, Yaron Sheffer wrote:
> My question was about identity validation, which is what 6125bis is
> about. So it's a subset of your second option, "validation of
> certificates". And yes, this boils to, are DANE-based EE certificates
> expected to adhere to the
On Fri, Jun 24, 2022 at 07:04:28PM +0300, Yaron Sheffer wrote:
> * Similarly, it is not clear to me whether certs obtained through DANE
> are in or out of scope.
I may be able to help, but I am struggling to understand the question in
sufficient detail. Can you be more specific about:
-
On Thu, Jun 23, 2022 at 05:33:32PM -0400, John Levine wrote:
> Kind of. I use the same key for all of the certs for the many names
> that each of my mail servers have so I have one TLSA record and a lot
> of CNAMEs. That's probably bad practice for some reason but whatever.
Actually, I'd say
On Thu, Jun 23, 2022 at 01:42:46PM -0400, John R Levine wrote:
> Among the reasons that DANE in e-mail is less common is that it is tricky.
DANE is only "tricky" when you're trying to integrate TLSA record
updates with ACME cert rollovers and don't configure key reuse.
Otherwise the same "3 1
On Thu, Jun 23, 2022 at 01:02:57PM -0400, Viktor Dukhovni wrote:
> * Some are email service providers hosting many users and
>perhaps also customer domains, for example:
>
>web.de
>gmx.de
>protonmail.ch
>
On Sat, Jun 18, 2022 at 11:56:30AM -0600, Peter Saint-Andre wrote:
> On 5/27/22 7:51 AM, Stephen Farrell wrote:
>
> > - section 3.2: I wondered why no mention of MTA-STS or
> > DANE? Could/should we say that MTA implementations
> > SHOULD include support for such strictness?
>
> Hi
On Sun, Jun 19, 2022 at 08:38:26PM +0300, Ilari Liusvaara wrote:
> > Of course both EMS and EtM MUST be a MUST.
>
> I think EtM is only MUST if blockmode (CBC) cipher is supported. And
> clients SHOULD NOT send EtM if not sending any blockmode cipher suites
> (as it is not possible to
On Wed, Apr 27, 2022 at 08:52:42PM +, Salz, Rich wrote:
> Ya got slightly less than 24 hours to complain :)
The pull request uses the term "Server Name Identification",
but the correct term is "Server Name Indication":
https://datatracker.ietf.org/doc/html/rfc6066#section-3
I made
> On 27 Jan 2022, at 4:45 pm, Yaron Sheffer wrote:
>
> So our plan moving forward is to essentially keep the new text on OCSP [1]
> and add a reference to RFC 7633 (the certificate must-staple extension). But
> only as a MAY. In addition, we will add a MUST requirement to perform (some
> kind
On Fri, Jan 21, 2022 at 01:30:38PM -0500, Ryan Sleevi wrote:
> > > Do you think that DNSSEC should be soft-fail for CAA checks, or should
> > > we urge the CAs to be more strict here? Perhaps that would be another
> > > recommendation.
> >
> > CAA lookups must not softfail. This needs to be the
> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor
> wrote:
>
>> Without wanting to detract too much from the core question of the thread,
>> how does this address the routing gap? The adversary at the routing layer
>> just redirects the host being validated to control the key that way, and
>>
> On 19 Jan 2022, at 9:57 am, Yaron Sheffer wrote:
>
> But this raises a larger question: many client-side implementations soft-fail
> if they don’t get an OCSP response within the handshake, i.e. they just
> ignore the problem. As far as we understand, this makes OCSP stapling
> completely
On Sun, Nov 21, 2021 at 04:05:44PM -0500, Ryan Sleevi wrote:
> Using your example here, of a server set to accept any client presented
> identifier in the form *.foo.example, a sharp edge here would be how to
> handle when the presented identifier is also *.foo.example - is that an
> acceptable
On Sun, Nov 21, 2021 at 04:06:35PM +, Salz, Rich wrote:
> I find Viktor's description of the asymmetry between clients and servers to
> be spot-on.
>
> John, could you craft a sample sentence you'd like to see? Something
> like this as a new sentence at the end of the second paragraph of
On Sat, Nov 20, 2021 at 11:57:59AM +, John Mattsson wrote:
> - In some applications using mutually authenticated TLS, e.g., between
> nodes in 5G core networks or in mesh networks there is basically no
> difference between the client and the server. It would be very good if
> the document
On Sat, Nov 20, 2021 at 10:57:01AM +, John Mattsson wrote:
> I expect most TLS stacks to happily continue the connection after
> external PSK (I think those do not even have standard expiry
> times) or certificate expires.
>
> John: Yes, and I think they should. The application has the
>
FWIW, I found nothing in that text to object to...
> On 16 Nov 2021, at 3:14 pm, Salz, Rich
> wrote:
>
> Ryan Sleevi has proposed adding the text below to the security considerations
> section. I’ve posted about this before and had miniscule feedback. Barring
> strong objections, I intend
On Sun, Nov 14, 2021 at 08:27:25AM +, John Mattsson wrote:
> I promised to send some information to the list regarding security
> considerations for long connections. I think the (D)TLS 1.3 is lacking
> considerations on this as well so I made an issue for RFC8446bis.
>
>
On Mon, Sep 27, 2021 at 03:52:44PM +, Salz, Rich wrote:
> John Mattson had pointed out that the document uses client and server,
> when in fact if you use mutual auth or machine-to-machine, that’s not
> really correct.
The client and server roles in TLS are well defined and independent of
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 that whole section.
Works for me, I'd
On Wed, Sep 08, 2021 at 04:45:24PM +, Salz, Rich wrote:
> >Perhaps the text can be made more concise, but I don't think full
> removal is warranted. This is *not* the fragile key pinning from HPKP.
>
> Right now the text has this. Is more needed?
>
> ### Failure: No Match Found
>
On Wed, Sep 08, 2021 at 03:52:23PM +, Salz, Rich wrote:
> I would like to remove the discussion of pinning from 5126bis for the
> following reason:
[ You surely meant 6125, but let your fingers do the talking... ]
>
> * It’s an escape hatch, saying “do all these things but if you
On Wed, Aug 11, 2021 at 05:42:40PM +0200, Hanno Böck wrote:
> We started analyzing STARTTLS implementations in E-Mail servers and
> clients based on the 2011 command injection discovered in Postfix.
Specifically discovered by Wietse Venema, while refactoring some Postfix
code. He observed that
> On 12 Jul 2021, at 5:48 pm, Jim Fenton wrote:
>
> Part of my problem is that I don’t know what the boundaries of RFC 6125 are.
> If there’s further validation that happens elsewhere that this depends upon,
> it should be specific about what other RFCs define that validation.
Not everything
On Mon, Jul 12, 2021 at 02:14:39PM -0700, Brian Smith wrote:
> I think the important point is that RFC 6125 can specify the syntax of a
> wildcard, and we can specify how to match a reference ID against it,
> without having to dive into determining whether the CA should have issued
> that
> On 12 Jul 2021, at 2:06 pm, Jim Fenton wrote:
>
>> A client employing this specification's rules MAY match the reference
>> identifier against a presented identifier whose DNS domain name portion
>> contains the wildcard character "*"
>
> I questioned the MAY in this sentence, because it
On Thu, Jul 08, 2021 at 06:52:15PM -0400, Ryan Sleevi wrote:
> > Can "the industry" (CAs, software vendors, ...) unite behind getting the
> > users to accept the right, but arguably less convenient, tradeoff?
>
> No. I think deprecating wildcards would be a bad outcome for users and for
> server
On Thu, Jul 08, 2021 at 01:52:42PM -0600, Peter Saint-Andre wrote:
> > So the sooner we can get rid of wildcard certificates entirely, the
> > better. They've outlived their usefulness.
>
> Jeff Hodges and I had hoped to push for deprecating wildcard certs when
> working on RFC 6125 10+ years
On Thu, Jul 08, 2021 at 02:12:51PM +, 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. I am about to publish a new draft which
On Wed, Apr 21, 2021 at 01:06:21PM -0400, Viktor Dukhovni wrote:
> On Wed, Apr 21, 2021 at 06:50:56PM +0200, Eliot Lear wrote:
>
> > If this is scoped to dnsNames then I’m fine with it going forward as
> > is. Other names would be problematic.
>
> It was my expectation
On Wed, Apr 21, 2021 at 06:50:56PM +0200, Eliot Lear wrote:
> If this is scoped to dnsNames then I’m fine with it going forward as
> is. Other names would be problematic.
It was my expectation/understanding all along that we're talking about
is deprecation of CN-ID fallback when the reference
> On Mar 17, 2021, at 1:00 PM, Eliot Lear
> wrote:
>
>> See X509_check_host(3). It's behaviour is customisable via the
>> below flags:
>>
>> X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT,
>> X509_CHECK_FLAG_NEVER_CHECK_SUBJECT,
>> X509_CHECK_FLAG_NO_WILDCARDS,
>>
> On Mar 15, 2021, at 5:58 AM, Eliot Lear
> wrote:
>
> For libraries like OpenSSL I wouldn’t mind throwing in a new flag, for
> instance, that would be required to validate a cert based on the subject.
> That would help these other uses get over the hump over time; perhaps even
> with a
> On Mar 15, 2021, at 7:58 AM, Eliot Lear
> wrote:
>
> Architecturally, Rich is nailing it. We should be encouraging the use of
> SANs. However, use of SANs beyond the scope of the web may not be entirely
> ubiquitous, and so we should either be a bit more targeted, or slow roll the
>
On Fri, Jan 08, 2021 at 11:34:44AM +0100, Olle E. Johansson wrote:
> I am working on a project where we issue short term client TLS certs,
> with just a few days lifespan.
>
> I realized that in some protocols, like SIP, MQTT, XMPP, we have quite
> long lived client connections over
On Mon, Dec 02, 2019 at 09:57:07AM +0300, Valery Smyslov wrote:
> 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
> On Sep 11, 2019, at 2:47 AM, internet-dra...@ietf.org wrote:
>
>Title : Use of TLS for Email Submission and Access
>Authors : Loganaden Velvindron
> Stephen Farrell
> Filename: draft-ietf-uta-tls-for-email-02.txt
>
On Mon, Aug 26, 2019 at 06:00:07PM +0200, Daniel Margolis wrote:
> I think it's reasonable for someone just deploying a policy to set a
> max_age that's very small--like, a day or less. (They of course should also
> use report-only mode to try to ensure things work during launch, but this
> would
On Jul 31, 2019, at 7:05 PM, Benjamin Kaduk wrote:
> That seems likely; I don't feel a particular need to introduce skew between
> reality and the text of the specification. I guess, if the WG wants, we
> could recommend SRV-ID but still allow CN-ID (but this really is up to the
> WG and it is
On Tue, Jul 30, 2019 at 11:16:25PM -0700, Jim Fenton wrote:
> The RFC 7672 definition of Reference Identifier includes the CN-ID, so it
> would be more consistent to include it when referencing 6125 as well.
For the record, RFC7672 has aged a bit since ~2014 when most of it
was written, so at
On Tue, Jul 30, 2019 at 07:02:23PM -0500, Benjamin Kaduk wrote:
> > This work was inspired by a paper, "Neither Snow Nor Rain Nor MITM ...An
> > Empirical Analysis of Email Delivery Security"
> > http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf that there was a
> > presentation about at an
> On Apr 26, 2019, at 1:39 PM, Grant Taylor
> wrote:
>
> Is anyone else seeing policy type of "no-policy-found" in the TLSRPTs that
> they are receiving from Google?
>
> I'm seeing said policy with a "total-successful-session-count" of exactly one
> each day in addition to the other
> On Apr 14, 2019, at 2:59 PM, Grant Taylor
> wrote:
>
> I think I actually prefer the XML reports as they have not had all their
> white space removed. As such, I think they are easier to parse.
For me, it is JSON by large margin. Largely because I can use "jq", and
don't have to go near
Oops, second paragraph should read: The header does *not* ...
> On Mar 30, 2019, at 3:05 PM, Viktor Dukhovni wrote:
>
> Essentially, all MTAs are intermediate MTAs. The header is added to the
> message via the sender's *MUA*, and conveys the same sender preference to
> every
> On Mar 30, 2019, at 2:44 PM, Benjamin Kaduk wrote:
>
> This doesn't really say anything about or give guidance to intermediate
> MTAs. (Do we want to differentiate between initial and intermediate MTAs,
> too?)
Essentially, all MTAs are intermediate MTAs. The header is added to the
message
Reposted without asking permission, but I don't think Phillip Hallam-Baker will
mind:
... if security is going to be any use to people it has to be easy enough
that a
60+ year old grandmother who left school before the Internet arrived can use
it
because she is the US Secretary of
On Mon, Mar 18, 2019 at 02:34:30PM +0300, Valery Smyslov wrote:
> https://datatracker.ietf.org/meeting/104/materials/agenda-104-uta-01
>
> We scheduled a 20-min discussion around the IESG evaluation of
> draft-ietf-uta-smtp-require-tls-07. We hope F2F discussion will be
> productive and invite
> On Mar 14, 2019, at 1:31 PM, Eric Rescorla wrote:
>
> It's allowed to not *generally* honor STS, but this text does not
> have any provision for just ignoring it for some messages.
In MTAs (e.g. Postfix), the delivery policy is *always* per message,
or more precisely per message recipient.
On Thu, Mar 14, 2019 at 09:43:35AM -0700, Eric Rescorla wrote:
> > Think "Happy Birthday Grandma" (ideally not belated) postcard (i.e.
> > cleartext OK).
>
> Well, my point is that this use case is in direct conflict with the plain
> text of the semantics of MTA-STS.
Neither MTA-STS nor DANE
> On Mar 14, 2019, at 11:53 AM, Eric Rescorla wrote:
>
> We had a bunch more discussion on this on the IESG call. It seems like
> the primary use case for TLS-Required=no may be to exempt what's basically
> the control channel from the requirement to use TLS. So, for instance,
> I am getting
> On Mar 14, 2019, at 11:53 AM, Eric Rescorla wrote:
>
> We had a bunch more discussion on this on the IESG call. It seems like
> the primary use case for TLS-Required=no may be to exempt what's basically
> the control channel from the requirement to use TLS. So, for instance,
> I am getting
> On Mar 13, 2019, at 5:13 PM, Eric Rescorla wrote:
>
> Well, I think this field should only override the outgoing and not incoming
> policies (or be removed).
To be clear, let's imagine a company (say a bank) with the following TLS
policies (written roughly Postfix-style, but should be clear
> On Mar 12, 2019, at 11:00 PM, Eric Rescorla wrote:
>
>> My perspective on the SMTP security landscape is based on 18 years of
>> Postfix development and a decade as Postmaster at Morgan Stanley where
>> among other activities (email for the Google IPO) I managed mandatory
>> TLS peering with
> On Mar 12, 2019, at 8:01 PM, Eric Rescorla wrote:
>
> I'm sorry, but I don't see how any of this is meaningfully different from the
> situation with HSTS. In both cases, the receiving system indicates that
> the sending system ought to use secure transport, and if the sending
> system conforms
> On Feb 28, 2019, at 9:11 PM, Benjamin Kaduk wrote:
>
>> The primary motivation for "Require TLS = no" is to allow the user
>> to *resend" a message that is not getting through, or to reach the
>> destination domain's postmaster because of downstream (receiving
>> system misconfiguration), to
> On Feb 28, 2019, at 5:49 PM, Jim Fenton wrote:
>
>> I'm complaining more about the transition from (3) to (4) than either one
>> per se. If I open a connection and then establish a (new?) TLS-protected
>> session, that seems to mostly be STARTTLS. But if I use implicit TLS, why
>> do I need
On Thu, Feb 28, 2019 at 01:35:53PM -0500, Viktor Dukhovni wrote:
> We should keep in mind that email is often the medium used to
> communicate about operational failures. And that not infrequently,
> insecure email is the medium through which more essential security
> is
On Thu, Feb 28, 2019 at 09:42:31AM -0800, Eric Rescorla wrote:
> > The preferences we're talking about here (MTA-STS and DANE) are basically
> > advertisements saying, "if you send mail to this domain, you should expect
> > to use TLS when doing so."
>
> and "if you recognize this indicator, you
> On Feb 28, 2019, at 11:01 AM, Barry Leiba wrote:
>
> I have to agree with EKR about it not completely being the sender's
> decision, though for a rather different reason. I really doubt that
> in the vast majority of cases any human user will actively choose or
> not choose this option on
On Wed, Feb 27, 2019 at 08:18:19PM -0600, Benjamin Kaduk wrote:
> > With MTA-STS, yes, the name would have to match the certificate.
> > (Which makes deployment more difficult in some use-cases, but
> > c'est la vie).
>
> Section 2 has this nice note about "MUST verify successfully using DANE as
> On Feb 27, 2019, at 5:00 PM, Spencer Dawkins at IETF
> wrote:
>
> Not my ballot thread, but "TLS Required: no" is a LOT clearer to me. I'm not
> the target audience, but the original order screws me up every time I see it
> in a ballot e-mail.
That's a bike-shed colour I for one can
On Wed, Feb 27, 2019 at 02:11:38PM -0600, Benjamin Kaduk wrote:
> > > I'm also unsure exactly how tightly nailed down the (non-DANE) TLS
> > > certificate validation process is supposed to be as a result of this
> > > document; more in the COMMENT section. It seems that without some form
> > >
On Wed, Feb 27, 2019 at 01:35:42PM -0600, Benjamin Kaduk wrote:
> It seems like implicit in this stance is a belief that DANE and/or MTA-STS
> as currently specified are flawed, in that they do not have a reasonable
> path to substantial deployment (in bounded time).
REQUIRETLS "no", is
On Tue, Feb 26, 2019 at 03:26:05PM -0800, Jim Fenton wrote:
> >If a REQUIRETLS message is bounced, the server MUST behave as if
> >RET=HDRS was present as described in [RFC3461]. If both RET=FULL and
> >REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be
> >
On Fri, Feb 22, 2019 at 10:43:34AM -0800, Yaron Sheffer wrote:
> I would have expected a parameter to be associated with REQUIRETLS to indicate
> whether DANE is required throughout the forwarding path, or MTA-STS, or either
> one will do.
Leaving the security mechanism unspecified was a
> On Feb 21, 2019, at 3:52 PM, Eric Rescorla wrote:
>
> I am not aware of any such right. The receiving system is announcing
> a capability, and the sending system does its best to achieve the
> highest common security level.
>
> No, it's saying "don't deliver this at all, if you can't do
On Thu, Feb 21, 2019 at 12:22:32PM -0800, Eric Rescorla wrote:
> > A recipient has no expectation that the sending MTA supports any of
> > DANE, MTA-STS, REQUIRETLS, or even STARTTLS.
>
> Nor do Web servers have any expectation that clients support HSTS, but we
> still don't allow it to be
> On Feb 20, 2019, at 11:55 PM, Benjamin Kaduk wrote:
>
> While I understand that there can be cases where it is desired to ignore
> recipient-domain indications to use TLS, such as to report problems with
> the TLS capabilities of those domains, I have strong qualms about
> describing this
> On Jan 26, 2019, at 12:40 PM, John R Levine wrote:
>
> After reading all the discussion I posted an -02 which takes out all mention
> of ESNI. Here's why.
>
> More substantively, I would be surprised if any MTA ever implements ESNI
> because it makes no sense for mail. On the web,
> On Jan 25, 2019, at 4:38 PM, Stephen Farrell
> wrote:
>
> 2. The new text in s4 is wrong, a mail server will generally
> have access to the value from ESNI or the h/s will likely fail,
> and the TLS server will treat that as the SNI to use for server
> certificate selection. The issue isn't
> On Jan 15, 2019, at 5:21 PM, Stephen Farrell
> wrote:
>
> Well, not until you get to ESNI and fingerprinting different
> handshake instances as a way to track a message down a chain
> of MTAs.
This is mail, not HTTP. If you get to read the resulting
headers, the trace headers are all
1 - 100 of 384 matches
Mail list logo
