Subject: [RAI] Request for Review: Default Port for IRC via TLS/SSL

From: Richard Hartmann <[email-masked]>
Date: Sun, 3 Oct 2010 03:05:32 +0200

Hi all,

I have written a short I-D to document the practice of using port 6697
for using IRC via TLS/SSL [1].

I already asked the TLS WG [2] and the Application Area [3],[4] to
review this I-D.

It has been suggested that I contact the RAI Area as well. Also, it has
been suggested that I move this I-D from Informational to the
Standards Track as it describes an Established Best Practice. I feel I
can not make this decision myself, but I did not get any authoritative
answer on the subject, yet.

In any case, I would welcome any and all feedback,
thanks a lot,
Richard

[1] http://datatracker.ietf.org/doc/draft-hartmann-default-port-for-irc-via-tls-ssl/
[2] http://www.ietf.org/mail-archive/web/tls/current/msg07029.html
[3] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01799.html
[4] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01808.html

---

From: Adam Roach <[email-masked]>
Date: Sat, 02 Oct 2010 20:52:12 -0500

By my reading, this is simply a document to formally request 
registration of an additional port in the non-reserved range for 
TLS-secured IRC. If that's your only purpose, I think what you're doing 
it overkill. On the other hand, if you really want this published as an 
RFC, I think you have a ton of work left to do.

*deep sigh*

Every time I look at the published information on IRC, I find it very 
underspecified. Relevant to your document: the TLS certificate matching 
rules don't seem to be spelled out anywhere. In fact, the only mention 
of TLS at all seems to be in RFC 2813, which says (and this is an entire 
section):

    Since the PASS and OPER messages of the IRC protocol are sent in
    clear text, a stream layer encryption mechanism (like "The TLS
    Protocol" [TLS]) could be used to protect these transactions.

So. Um. Are wildcards allowed? Is there any way to use TLS between relay 
servers, or is it just a client-to-server thing? I assume the idea is 
that we just open up the TCP connection and start the TLS negotiation, 
as opposed to (say) performing some kind of capabilities exchange 
followed by an indication to start TLS. There is no analysis of the 
security properties of the system. There is no meaningful discussion of 
confidentiality. The whole IRC specification set is very sloppy about 
the kinds of things we like to make sure are carefully analyzed in the IETF.

I know all of this isn't exactly your problem, but it does make me 
wonder why you're submitting an internet-draft for wider distribution. 
Everything that has ever been published through the RFC editor regarding 
IRC is informational (as opposed to standards track). As far as I can 
tell, all of the IRC port assignments that have been made by IANA were 
done via simple request without any accompanying document.

While I appreciate that you're trying to "do the right thing" to get 
this port registered, I think you're making it much more difficult on 
yourself than it needs to be. If you want to get this draft published as 
an RFC, you probably have a long uphill battle on your hands, dealing 
with addressing the kinds of issues I point out above.

If, on the other hand, you simply want to get port 6697 reserved for 
IRC/TLS so that no other application grabs it, you can do that without a 
document of any kind. You simply fill out the form at 
<http://www.iana.org/cgi-bin/usr-port-number.pl>. Your application is 
reviewed by a dedicated port assignment expert, and then is either 
accepted or declined.

/a

On 10/2/10 20:05, Oct 2, Richard Hartmann wrote:
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 3 Oct 2010 23:39:21 -0400

Adam: I think you might be over-reading the requirements here.  What  
you're describing would be a requirement for an IETF draft, but...

Richard: This sounds to me like it might be a job for the independent  
stream:
<http://tools.ietf.org/html/rfc5742>
<http://www.rfc-editor.org/pipermail/rfc-interest/2010-February/001729.html 

On Oct 2, 2010, at 9:52 PM, Adam Roach wrote:

> registration of an additional port in the non-reserved range for TLS- 
> secured IRC. If that's your only purpose, I think what you're doing  
> it overkill. On the other hand, if you really want this published as  
> an RFC, I think you have a ton of work left to do.
>
> *deep sigh*
>
> Every time I look at the published information on IRC, I find it  
> very underspecified. Relevant to your document: the TLS certificate  
> matching rules don't seem to be spelled out anywhere. In fact, the  
> only mention of TLS at all seems to be in RFC 2813, which says (and  
> this is an entire section):
>
> So. Um. Are wildcards allowed? Is there any way to use TLS between  
> relay servers, or is it just a client-to-server thing? I assume the  
> idea is that we just open up the TCP connection and start the TLS  
> negotiation, as opposed to (say) performing some kind of  
> capabilities exchange followed by an indication to start TLS. There  
> is no analysis of the security properties of the system. There is no  
> meaningful discussion of confidentiality. The whole IRC  
> specification set is very sloppy about the kinds of things we like  
> to make sure are carefully analyzed in the IETF.
>
> wonder why you're submitting an internet-draft for wider  
> distribution. Everything that has ever been published through the  
> RFC editor regarding IRC is informational (as opposed to standards  
> track). As far as I can tell, all of the IRC port assignments that  
> have been made by IANA were done via simple request without any  
> accompanying document.
>
> this port registered, I think you're making it much more difficult  
> on yourself than it needs to be. If you want to get this draft  
> published as an RFC, you probably have a long uphill battle on your  
> hands, dealing with addressing the kinds of issues I point out above.
>
> IRC/TLS so that no other application grabs it, you can do that  
> without a document of any kind. You simply fill out the form at <http://www.iana.org/cgi-bin/usr-port-number.pl 
> >. Your application is reviewed by a dedicated port assignment  
> expert, and then is either accepted or declined.
>
> /a
>

---

From: Adam Roach <[email-masked]>
Date: Sun, 03 Oct 2010 23:54:52 -0500

Okay, so, yes, this could be published as an independent stream 
submission. I still think that's overkill if all Richard wants is a port 
assignment. IANA requires no document for the port range 1024-49151 -- 
IETF, independent stream, or otherwise.

/a

On 10/3/10 22:39, Oct 3, Richard L. Barnes wrote:
> <http://www.rfc-editor.org/pipermail/rfc-interest/2010-February/001729.html> 
>
>
>
>> TLS-secured IRC. If that's your only purpose, I think what you're 
>> doing it overkill. On the other hand, if you really want this 
>> published as an RFC, I think you have a ton of work left to do.
>>
>> *deep sigh*
>>
>> underspecified. Relevant to your document: the TLS certificate 
>> negotiation, as opposed to (say) performing some kind of capabilities 
>> exchange followed by an indication to start TLS. There is no analysis 
>> of the security properties of the system. There is no meaningful 
>> discussion of confidentiality. The whole IRC specification set is 
>> very sloppy about the kinds of things we like to make sure are 
>> carefully analyzed in the IETF.
>>
>> distribution. Everything that has ever been published through the RFC 
>> editor regarding IRC is informational (as opposed to standards 
>> yourself than it needs to be. If you want to get this draft published 
>> as an RFC, you probably have a long uphill battle on your hands, 
>> dealing with addressing the kinds of issues I point out above.
>>
>> without a document of any kind. You simply fill out the form at 
>>> [1] 
>>> http://datatracker.ietf.org/doc/draft-hartmann-default-port-for-irc-via-tls-ssl/
>>> [3] 
>>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01799.html
>>> [4] 
>>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01808.html

---

From: Lars Eggert <[email-masked]>
Date: Mon, 4 Oct 2010 14:40:17 +0200

Hi,

> IETF, independent stream, or otherwise.

I agree with you that a request to IANA is sufficient here.

But IANA does require some documentation, even for the 1024-49151 range. It doesn't need to be an ID or RFC, but there needs to be enough material so that the Expert Reviewer can come to a decision.

Lars

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 4 Oct 2010 09:07:11 -0600

Richard, I really don't think you need an RFC for this. You just need to make the request to IANA. I've done some of these in the past and would be glad to help you. 

PS - I think it great you are registering this port. That needs to be done and I strongly support that. 

Cullen

---

From: Richard Hartmann <[email-masked]>
Date: Wed, 6 Oct 2010 14:55:01 +0200

On Sun, Oct 3, 2010 at 03:52, Adam Roach <[email-masked]> wrote:

>  By my reading, this is simply a document to formally request registration
> of an additional port in the non-reserved range for TLS-secured IRC. If
> that's your only purpose, I think what you're doing it overkill. On the
> other hand, if you really want this published as an RFC, I think you have a
> ton of work left to do.

> underspecified.

Agreed. The problem is that, realistically speaking, implementations
are too far from each other in ways of what and how to do it that,
there is no chance left to bring IRC into a common form.

We, or I, can merely try to salvage what can be salvaged.

> So. Um. Are wildcards allowed?

Nothing is specified, but at least irssi allows them. This is something
that might be good to specify in the hope that everyone will agree.

> Is there any way to use TLS between relay
> servers, or is it just a client-to-server thing?

This is strictly client-server. If you think there are too many ways to
do things in client-server IRC, don't look at the server interconnects.

> I assume the idea is that
> we just open up the TCP connection and start the TLS negotiation, as opposed
> to (say) performing some kind of capabilities exchange followed by an
> indication to start TLS.

Yes. Handshake and then normal IRC via the encrypted session.

> There is no analysis of the security properties of
> the system. There is no meaningful discussion of confidentiality.

If that should be elaborated, that's no problem. I know the ins and outs
of what TLS/SSL can do for IRC and what it can't do.

> The whole
> IRC specification set is very sloppy about the kinds of things we like to
> make sure are carefully analyzed in the IETF.

Agreed, but that is way outside of what this I-D aims to achieve. Unless
there is an explicit requirement that I fix that situation first, I do not aim
to change anything about that. Imo, it's simply impossible.

> I know all of this isn't exactly your problem, but it does make me wonder
> why you're submitting an internet-draft for wider distribution. Everything
> that has ever been published through the RFC editor regarding IRC is
> informational (as opposed to standards track). As far as I can tell, all of
> the IRC port assignments that have been made by IANA were done via simple
> request without any accompanying document.

I wanted to Do It Right. While I know that I don't need to submit an I-D, it
is the cleanest path, imo.

> While I appreciate that you're trying to "do the right thing" to get this
> port registered, I think you're making it much more difficult on yourself
> than it needs to be. If you want to get this draft published as an RFC, you
> probably have a long uphill battle on your hands, dealing with addressing
> the kinds of issues I point out above.

Given the short answers above, what do you and others think about my
situation? Should I just go with Independent Submission &
Informational/Experimental or try for Individual Submission & BCG?

> If, on the other hand, you simply want to get port 6697 reserved for IRC/TLS
> so that no other application grabs it, you can do that without a document of
> any kind. You simply fill out the form at
> reviewed by a dedicated port assignment expert, and then is either accepted
> or declined.

I know. I did that in parallel to submitting the I-D as I thought that
was the way
to go. IANA has asked me do retract my application until the I-D has become
a RFC.

Thanks a lot for your feedback,
Richard

---

From: Richard Hartmann <[email-masked]>
Date: Wed, 6 Oct 2010 14:58:40 +0200

> Richard: This sounds to me like it might be a job for the independent

That is what I am trying to decide myself. If RAI is willing to accept the
I-D as Individual Submission and there is a realistic expectation of the
I-D not needing to fix IRC as a whole (from the IETF pov), I would gladly
try to improve it until it's fit for official review.

If RAI is not willing to accept the I-D as Individual Submission and/or
I need to expect doing Sisyphos' work, I would obviously prefer to
go the Independent route.

Thanks,
Richard

---

From: Richard Hartmann <[email-masked]>
Date: Wed, 6 Oct 2010 15:01:05 +0200

> But IANA does require some documentation, even for the 1024-49151 range. It doesn't need to be an ID or RFC, but there needs to be enough material so that the Expert Reviewer can come to a decision.

That is my main motivation of pursuing a RFC. It makes the IANA
assignment certain and is the cleanest & most open way to go
about it.

Richard

---

From: Adam Roach <[email-masked]>
Date: Wed, 06 Oct 2010 08:35:34 -0500

> go the Independent route.

Well, Sisyphus never actually finished. Very little work in RAI is 
actually interminable -- it just takes a lot of time and effort. I think 
perhaps Heracles is a better character for your analogy.

/a