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
It appears that Viktor Dukhovni said:
>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
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 6/23/22 11:02 AM, Viktor Dukhovni wrote:
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
It appears that Viktor Dukhovni said:
>- If the question is about the software stack, then:
>
> * Any MTA that supports STARTTLS already supports both inbound.
Almost -- it needs to have a cert that matches its name and is signed
and/or matches the TLSA record. A lot of the default
On Thu, 23 Jun 2022, Peter Saint-Andre 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 John, thanks for sharing these insights. I'll reach out to a few Comcast
colleagues
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
>mailbox.org
>
On 6/23/22 10:44 AM, John Levine wrote:
It appears that Peter Saint-Andre said:
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 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
It appears that Peter Saint-Andre said:
>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 Stephen,
>
>Although these technologies
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 Stephen,
Although these technologies (RFC 8461 and RFC 7672) seem sensible, I
don't think
uthentication.
Cheers,
John
From: Uta on behalf of internet-dra...@ietf.org
Date: Thursday, 26 May 2022 at 23:22
To: i-d-annou...@ietf.org
Cc: uta@ietf.org
Subject: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts
- 7.1. The document should make it clear without Host Name Validation there is
typically no authentication. The TLS handshake only provides
proof-of-possestion of the private key and transfers certificates so that the
application can do authentication.
Cheers,
John
From: Uta on behalf of
Thanks Stephen, opened 4 issues,
https://github.com/yaronf/I-D/issues?q=is%3Aissue+is%3Aopen+label%3ABCP195
Yaron
On 5/27/22, 16:51, "Uta on behalf of Stephen Farrell" wrote:
Hiya,
I had a read of this. Seems to me to be in fine shape but
a couple of comments below. If
Hiya,
I had a read of this. Seems to me to be in fine shape but
a couple of comments below. If those have already been
discussed, apologies, and do ignore 'em.
I don't think any of my comments need addressing before
publication, but figured it was no harm sending 'em
anyway:-)
- section 3.2:
Thanks! Opened https://github.com/yaronf/I-D/issues/350
Yaron
On 5/27/22, 09:21, "Martin Thomson" wrote:
I made some comments in discussion of 6125bis that I think this document
should address.
Basically, the document would benefit from a discussion on multi-server
I made some comments in discussion of 6125bis that I think this document should
address.
Basically, the document would benefit from a discussion on multi-server
deployments in a few arrangements:
* deployments where multiple servers speak for the same names, but with
different protocols.
This version addresses numerous comments, mostly (but not always) editorial, by
Francesca and Paul W.
As a reminder, the document is in IETF LC until May 30.
Thanks,
Yaron
On 5/27/22, 00:22, "uta-boun...@ietf.org on behalf of
internet-dra...@ietf.org" wrote:
A New
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.
Title : Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS)
19 matches
Mail list logo
