Subject: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 13 Apr 2009 08:37:25 -0400

Some feedback from Alexey on the new TLS Usage Profile text in 4934bis.
I now need implementer feedback.

>>  A client MUST close the associated TLS connection if the connection
>>  is not expected to deliver any EPP messages later.  It MUST send a
>>  TLS close_notify alert before closing the connection.
>>
> As an implementor I remain skeptical that existing implementations do 
> that. At least I doubt many IMAP or SMTP servers do that. So maybe you

> should check how existing EPP implementations handle connection
closure.

What are you implementers doing?

> I think the text about how to extract and verify domain information
from 
> X.509 certificates is still missing from your draft. I think that what

> Chris wanted you to do and I am in agreement with him on this.
> I see some text on this in Section 8, but I think it is a bit too
short. 
> Check section 2.2.1 of draft-ietf-sieve-managesieve-09.txt. It
probably 
> contains 80% of what EPP should use.

Comments, please.  I've sent a note to Alexey pushing back on this
because (in my opinion) this puts mandates on client and server
certificate validation behavior that don't affect EPP interoperability.
If I'm wrong, I'd prefer to cite an existing mature reference instead of
cloning text from an unapproved I-D.  Does anybody know of one?

-Scott-

---

From: James Gould <[email-masked]>
Date: Mon, 13 Apr 2009 17:43:22 -0400

Scott,

We¹re implementing SSL using JSSE in our Java EPP SDK, but I¹m not sure if
JSSE sends a TLS_close_notify alert before the connection is closed.

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 13 Apr 2009 08:37:25 -0400
To: EPP Provreg <[email-masked]>
Subject: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00

closure.

from

short.
probably

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 14 Apr 2009 07:14:58 -0400

According to this reference:
 
http://download.java.net/jdk7/docs/technotes/guides/security/jsse/JSSERe
fGuide.html
 
it should, but I can't confirm that it does.  I'm reasonably certain
that this is behavior that's typically buried in a toolkit instead of
being implemented by an EPP developer, so perhaps that new text should
be removed from the document.

-Scott- 

________________________________

	From: Gould, James 
	Sent: Monday, April 13, 2009 5:43 PM
	To: Hollenbeck, Scott; EPP Provreg
	Subject: Re: [ietf-provreg] AD Review Comments:
draft-hollenbeck-rfc4934bis-00

	Scott,
	
	We're implementing SSL using JSSE in our Java EPP SDK, but I'm
not sure if JSSE sends a TLS_close_notify alert before the connection is
closed.   
	
	-- 

	JG 

	21345 Ridgetop Circle
	LS2-2-1
	Dulles, VA 20166
	
	Notice to Recipient:  This e-mail contains confidential,
proprietary and/or Registry  Sensitive information intended solely for
the recipient and, thus may not be  retransmitted, reproduced or
disclosed without the prior written consent of  VeriSign Naming and
Directory Services.  If you have received  this e-mail message in error,
please notify the sender immediately by  telephone or reply e-mail and
destroy the original message without making a  copy.  Thank you.

________________________________

	From: "Hollenbeck, Scott" <[email-masked]>
	Date: Mon, 13 Apr 2009 08:37:25 -0400
	To: EPP Provreg <[email-masked]>
	Subject: [ietf-provreg] AD Review Comments:
draft-hollenbeck-rfc4934bis-00
	
	Some feedback from Alexey on the new TLS Usage Profile text in
4934bis.
	I now need implementer feedback.

	closure.

	from
	
	short.
	probably
	> contains 80% of what EPP should use.
	
	Comments, please.  I've sent a note to Alexey pushing back on
this
	because (in my opinion) this puts mandates on client and server
	certificate validation behavior that don't affect EPP
interoperability.
	If I'm wrong, I'd prefer to cite an existing mature reference
instead of
	cloning text from an unapproved I-D.  Does anybody know of one?
	
	-Scott-

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 14 Apr 2009 15:11:05 +0200

[about TLS & close_notify]

Hollenbeck, Scott <[email-masked]> 2009-04-14 14:14
> I'm reasonably certain
 
I agree with you on that.

As James, I'm using a toolkit to deal with SSL stuff (a wrapper
around openssl called IO::Socket::SSL under Perl), 
I do not know if it does a TLS_close_notify.
Per its documentation, it does do it properly, even warning not to do
a shutdown before a close has it needs to send this TLS notification
on proper shutdown.

Also, most of the time, the connection is first closed by the
server, after the client <logout/> message.
A quick ssldump gives me:

1 8  0.2824 (0.0000)  S>CV3.1(992)  application_data
1 9  0.2967 (0.0142)  C>SV3.1(768)  application_data
1 10 0.3632 (0.0664)  S>CV3.1(576)  application_data
1 11 1.2652 (0.9020)  C>SV3.1(336)  application_data
1 12 1.3261 (0.0608)  S>CV3.1(368)  application_data
1 13 1.3261 (0.0000)  S>CV3.1(32)  Alert
1    1.3261 (0.0000)  S>C  TCP FIN
1 14 1.3275 (0.0013)  C>SV3.1(32)  Alert
1    1.3279 (0.0004)  C>S  TCP RST

The alerts are probably the close_notify.

-- 
Patrick Mevzek
Dot and Co <http://www.dotandco.com/> <http://www.dotandco.net/>

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 14 Apr 2009 15:23:30 +0200

Hollenbeck, Scott <[email-masked]> 2009-04-13 15:00
> certificate validation behavior that don't affect EPP interoperability.

I may be totally blunt, but as I said before there is nothing in the
EPP use of TLS that is specific of EPP, it is just basic
client/server communication.
Some registries are not using TLS at all, specifically on test
servers.
Some registries do use TLS without mandating a specific client
certificate/certification path (that is autogenerated certificates are
accepted).
And I doubt that all clients check the server certificate credentials
(which are not necessarily changed often).
So the specifications should not put too much things on these points.

I may be silly but in my mind few MUST in RFC4934 related to
TLS authentication could be only SHOULD (in section 8), and the whole
part trimmed to say something along the line of 'standard TLS
shortcomings/best practices apply'

In all cases, I agree with the fact that this whole discussion has
nothing to do with EPP interoperability. In that sense, TLS is really
the last worry.

---

From: James Gould <[email-masked]>
Date: Tue, 14 Apr 2009 09:27:20 -0400

Scott,

I agree since the SSL details are typically handled by the toolkit,
language, or SSL provider with no explicit control by the EPP developer.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 14 Apr 2009 07:14:58 -0400
To: James Gould <[email-masked]>, EPP Provreg <[email-masked]>
Subject: RE: [ietf-provreg] AD Review Comments:
draft-hollenbeck-rfc4934bis-00

http://download.java.net/jdk7/docs/technotes/guides/security/jsse/JSSERefGui
de.html
 
it should, but I can't confirm that it does.  I'm reasonably certain that
this is behavior that's typically buried in a toolkit instead of being
implemented by an EPP developer, so perhaps that new text should be removed
from the document.
-Scott-