Subject: Re: [dane] draft-fanf-dane-smtp
From: Tony Finch <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Sun, 3 Jun 2012 18:08:03 +0100
List-Id: <ietf-smtp.imc.org>

Matt McCutchen <[email-masked]> wrote:

> >     As well as its normal function of providing an association
> >     between a domain name and a certificate, we are also using the
> >     existance of a TLSA record to signal to the client that it can
> >     expect a valid server certificate.
>
> TLSA always signals to the client that *if* it does TLS, it can expect a
> valid server certificate.  The issue is whether to do TLS.  I think you
> mean this:
>
>      As well as its normal function of providing an association
>      between a domain name and a certificate, we are also using the
>      existance of a TLSA record to signal to the client that the SMTP
>      server supports TLS.

There is a load of other text in the intro explaining that in the current
internet a lot of MXs support TLS but don't have valid certificates, and
even if they did the existing specs don't explain how to validate them. So
the point of that text is to explain that we are using TLSA to fix this.
You are right to point out that I had left server support for TLS
implicit; I already improved that between -01 and -02 so the paragraph now
reads:

   As well as its normal function of providing an association between a
   domain name and a certificate, we are also using the existance of a
   TLSA record to signal to the client that it can expect the server to
   offer TLS with a valid certificate.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: North 4 or 5, veering southeast 5 or 6. Moderate, occasionally rough
at first. Occasional rain. Good, occasionally poor.

Subject: Re: [dane] draft-fanf-dane-smtp
From: Paul Hoffman <[email-masked]>
Date: Sat, 2 Jun 2012 08:10:17 -0700
Cc: [email-masked], IETF DANE WG list <[email-masked]>
To: Matt McCutchen <[email-masked]>
Sender: [email-masked]

On Jun 1, 2012, at 8:05 PM, Matt McCutchen wrote:

> I thought (and hoped) that TLSA was a generic protocol for
> authenticating a TLS service at a given (DNS name, transport, port),
> nothing more.  I didn't realize that subsequent documents would attach
> other semantics to TLSA RRsets.  Nothing in the DANE doc anticipates
> this.  (The clause, "Unless there is a protocol-specific specification
> that is different than this one", appears to me to refer to putting TLSA
> RRsets at a different owner name, not giving them different semantics.)
> I would oppose doing this, but it looks like I'm outvoted.

It was discussed on the DANE mailing list off and on over time, particularly with respect to SRV-using protocols. You may disagree with it and hope for different, but it should not be a surprise to you. We all know that a TLS-on-defined-port protocol is not the same as a TLS-after-upgrade protocol when the TLS handshake fails, and DANE by design gives a different way for the TLS handshake to fail.

>> I think HASTLS might be a good idea, but the IETF still needs to have
>> the discussion of layering of these types of announcements.
> 
> I think IETF should have that discussion before the WG commits to Tony's
> proposal for SMTP.

This draft is a great forcing function for the discussion. However, I will be shocked if the discussion comes to a fixed result any time soon.

>>> This approach is not going to work.  
>> 
>> It will work fine for everyone who doesn't do the "cover every port
>> and assume that no future protocol will ever define how specific
>> applications will use TLSA".
> 
> It's true that there was no strong support for ensuring that covering
> every port works.  

s/no strong support/no noticeable support/

> Though, if we intend to break it, section "A.2.1.3.
> Provisioning TLSA Records with Wildcards" of the DANE doc should be
> updated.

Disagree. The text in A.2.1.3 is still correct: it's only your interpretation of "if the port is covered, it must offer TLS" that is wrong.

> It's also true that I can't just expect the standard to support the
> features I want without slogging through the process of building
> consensus.  For now, I can have fun deploying records with the
> private-use certificate usage and implementing them in my client.

By all means let the mailing list know your experiences with that deployment. If DANE is anything like DNSSEC, we have muffed and understated many important features that will only be found by interesting deployment.

--Paul Hoffman

From [email-masked]  Mon Jun 18 08:09:58 2012
From: IETF Secretariat <[email-masked]>
To: IETF Announcement List <[email-masked]>
Date: Mon, 18 Jun 2012 08:09:57 -0700
Cc: [email-masked], [email-masked]
Subject: [ietf-smtp] New Non-WG Mailing List: ietf-smtp -- Discussion of issues related to	Simple Mail Transfer Protocol (SMTP)

A new IETF non-working group email list has been created.

List address:[email-masked]
Archive: http://www.ietf.org/mail-archive/web/ietf-smtp/
To subscribe: https://www.ietf.org/mailman/listinfo/ietf-smtp

Purpose: Discussion of issues related to Simple Mail Transfer Protocol
(SMTP) [RFC 821, RFC 2821, RFC 5321]

Notes: This replaces the existing ietf-smtp list hosted at imc.org, and
subscriptions will be automatically transferred from that list to this.

For additional information, please contact the list administrators.

From [email-masked]  Thu Jun 21 09:25:43 2012
Date: Fri, 22 Jun 2012 01:25:38 +0900
From: Yi EungJun <[email-masked]>
To: [email-masked]
Subject: [ietf-smtp] a protocol to negotiate protocol?

If this is not the right mailing list to ask my question, I apologize 
that. But I failed to find out any mailing list which is better than this.

Configuring MUA, like Thunderbird, iMail or Outlook, is quite annoying 
for me because I have to know many configuration values; protocol, 
hostname, port, username, password, authentication method or more.

If there is a protocol to negotiate the protocol to transport mails 
between mail client and server, based on preferences or capabilities of 
the both side, MUA could configure itself automatically without asking 
to user questions except mail address and password.

For example, mail client asks to server(the domain part of the given 
mail address) which protocol it can use, and mail server replies that 
SMTP and IMAP is acceptable, and then mail client configures itself as 
server replies. Other configuration fields also could be filled in this way.

Does anyone know a protocol such like that?

From [email-masked]  Thu Jun 21 11:20:57 2012
Date: Thu, 21 Jun 2012 19:20:55 +0100
From: Tony Finch <[email-masked]>
To: Yi EungJun <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-smtp] a protocol to negotiate protocol?

Yi EungJun <[email-masked]> wrote:

> Does anyone know a protocol such like that?

RFC 6186

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire, Northeast Forties: Easterly 4 or 5,
increasing 6 or 7, perhaps gale 8 later, except in North Utsire. Slight,
becoming moderate or rough, except in North Utsire. Occasional rain. Moderate
or good.

From [email-masked]  Fri Jun 22 01:24:41 2012
Date: Fri, 22 Jun 2012 10:24:39 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-smtp] a protocol to negotiate protocol?

> RFC 6186

While I greatly applaud that document in every detail, I do wonder... 
why do clients ask the user whether to use TLS? whether to use C=D? 
whether to perform plaintext or SASL authentication?

Arnt

From [email-masked]  Fri Jun 22 04:00:59 2012
Date: Fri, 22 Jun 2012 12:00:56 +0100
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Sender: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-smtp] a protocol to negotiate protocol?

Arnt Gulbrandsen <[email-masked]> wrote:

> > RFC 6186
>
> While I greatly applaud that document in every detail, I do wonder... why do
> clients ask the user whether to use TLS? whether to use C=D? whether to
> perform plaintext or SASL authentication?

I've been wondering that for at least seven years.
http://fanf.livejournal.com/39428.html

I'm currently trying to write draft-fanf-dane-mua which will update RFC
6186 to specify how it is affected by DNSSEC and how to use TLSA records.
It will use TLSA records to indicate that STARTTLS is supported on the
cleartext ports, and encourage MUAs to use that for autoconfiguration.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South German Bight, Humber, Thames, Dover: Southwesterly 6 to gale 8,
occasionally severe gale 9 in Thames and Dover. Moderate or rough. Squally
showers. Moderate.

From [email-masked]  Fri Jun 22 07:54:43 2012
Date: Fri, 22 Jun 2012 10:54:28 -0400
From: John C Klensin <[email-masked]>
To: Tony Finch <[email-masked]>, Yi EungJun <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-smtp] a protocol to negotiate protocol?

--On Thursday, June 21, 2012 19:20 +0100 Tony Finch
<[email-masked]> wrote:

> Yi EungJun <[email-masked]> wrote:
> 
>> Does anyone know a protocol such like that?
> 
> RFC 6186

Or, if you merely need the relevant parameters, RFCs 2244 and
6075.

   john

From [email-masked]  Wed Jun 27 12:15:05 2012
Date: Wed, 27 Jun 2012 20:15:02 +0100
From: Tony Finch <[email-masked]>
To: [email-masked], [email-masked]
Sender: Tony Finch <[email-masked]>
Subject: [ietf-smtp] draft-fanf-dane-mua-00

The below should be of interest to members of these lists too.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames: South or southeast 3 or 4, occasionally 5 later. Slight or
moderate. Thundery showers, fog patches. Moderate, occasionally very poor.

---------- Forwarded message ----------
Date: Wed, 27 Jun 2012 20:09:56 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: [dane] draft-fanf-dane-mua-00

At long last, I have got what I hope is a plausible spec for using DANE
with IMAP, POP3, and message submission. I think my main struggle was
working out what I did not need to put in the document. The compatibility
bits are particularly tricky. The structure owes a fair amount to Matt
Miller and PSA's XMPP draft, and to RFC 6186.

I have also made a minor revision to my other draft which is now
draft-fanf-dane-smt-04. This is mainly to flag up points for discussion
in Vancouver.

All questions / comments / suggestions welcome!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Variable mainly northwesterly 3 or 4, but easterly 5 to 7 at first
in far southeast. Rough at first in far southeast, otherwise slight or
moderate. Showers, fog patches. Moderate or good, occasionally very poor.

---------- Forwarded message ----------
Date: Wed, 27 Jun 2012 11:58:10 -0700
From: [email-masked]
To: [email-masked]
Subject: New Version Notification for draft-fanf-dane-mua-00.txt

A new version of I-D, draft-fanf-dane-mua-00.txt
has been successfully submitted by Tony Finch and posted to the
IETF repository.

Filename:	 draft-fanf-dane-mua
Revision:	 00
Title:		 DNSSEC and TLSA records for IMAP, POP3, and message submission
Creation date:	 2012-06-27
WG ID:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-fanf-dane-mua-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fanf-dane-mua
Htmlized:        http://tools.ietf.org/html/draft-fanf-dane-mua-00

Abstract:
   This specification describes the effect that DNSSEC has on SRV-based
   autoconfiguration and TLS certificate verification in the mail user
   agent protocols IMAP, POP3, and message submission.  It also
   describes how to use TLSA DNS records to provide stronger
   authentication of server TLS certificates.

The IETF Secretariat
_______________________________________________
dane mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dane