Alexey's Apps Area Activity Report for September 2009

Document Status and Progress:

Active documents, my action:
- draft-ietf-tsvwg-iana-ports (BCP) - need to do AD-style review
- draft-gudmundsson-dns-srv-iana-registry - need to discuss with
authors how this relates to draft-ietf-tsvwg-iana-ports
- draft-hethmon-mcmurray-ftp-hosts (Proposed Standard) - deciding if I will
sponsor this document.
- draft-desruisseaux-caldav-sched (Proposed Standard) - need to do AD review
- draft-ietf-webdav-bind (Experimental) - need to address 2 DISCUSSes
(Cullen, Robert), in particular about the document "updating the
base WebDAV spec".

Active documents in IETF LC or IESG review:
- draft-ietf-eai-downgraded-display (Experimental) - In IESG review
- RFC 3839 to Historic - In IETF LC till October 14th (despite ID
tracker saying otherwise)
- draft-reschke-rfc2731bis (Informational) - In IETF LC

In RFC Editor's queue:
- draft-ietf-vcarddav-webdav-mkcol (Proposed Standard) - in AUTH48

Published as RFCs:
- draft-hollenbeck-rfc493*bis (Full Standard) - RFC 5730-5734
- draft-ietf-lemonade-streaming (Informational) - RFC 5616
- draft-ietf-ltru-4645bis (Informational) - RFC 5645
- draft-ietf-ltru-4646bis (BCP) - RFC 5646

Active documents, waiting on others:
- draft-dusseault-http-patch (Unknown) - waiting for shepherding

Lisa's Apps Area Activity Report for Sept 2009

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Server Identity Verification in Application Protocols

A new version of draft-saintandre-tls-server-id-check is available:

http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt

Other than the informational appendix, the diff from the -01 version is
relatively minor. Feedback is welcome.

Peter

--
Peter Saint-Andre
https://stpeter.im/

Off-topic: social event in Hiroshima

Hi,
Instead of emailing people directly, I thought it would be easier to ask 
on the mailing list. For people who are planning to attend the social 
event in Hiroshima, can you please let me know off-list about that. I am 
deciding about whether I should go to the social event, so a good 
company might help to decide in favor.

Regards,
Alexey

Re: Server Identity Verification in Application Protocols

Hi Peter,

--On October 2, 2009 4:02:22 PM -0600 Peter Saint-Andre 
<stpeter <at> stpeter.im> wrote:

> A new version of draft-saintandre-tls-server-id-check is available:
>
> http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt
>
> Other than the informational appendix, the diff from the -01 version is
> relatively minor. Feedback is welcome.

Given the recent debate on the email SRV spec (which finished last call and 
I need to follow up on) should there be more discussion of exactly how a 
client should verify a server when it uses SRV to look it up? It seems to 
me it is not clear what a client should verify. i.e., client looks up the 
server._tcp name first, then connects to the server on the returned 
hostname. Should both the SRV name and the hostname in the SRV be verified 
in the cert?

I would much rather this server identity spec deals with this issue, and 
would prefer to reference it from the email SRV spec and CalDAV one.

--

-- 
Cyrus Daboo

Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02

Hi,

On 2009-9-29, at 17:10, ah <at> tr-sys.de wrote:
> I have followed up and studied the revised Port Number registry
> draft, draft-ietf-tsvwg-iana-ports-02.

thank you! We've been waiting for community feedback.

> (A.1)  Intended expansion of the Port# registry to Service Names
>
> The -02 draft revision has proposed to expand the Port Number
> registry to also cover "Service Names" -- independent of the
> assignment of port numbers to applications/services.
>
> There are lots of reasons to not do that in the proposed form.
>
> After discussions with driving forces from the Applications Area,
> draft-gudmundsson-dns-srv-iana-registry-03.txt has reinforced and
> reconciled the proposal for a dedicated Service Prefix registry.
> Please refer to that draft for distinguishing details.

I'm sorry, but I see little argumentation in draft-gudmunsson on why a  
separate registry is preferable. Yes, the IANA rules for port numbers  
should be stricter than for service names, but that does *not* mean  
that a separate registry is needed - it just means that the rules  
should be different.

The main reason to have one registry is to make it easy for IANA and  
applicants to figure out which names are registered and which aren't.

>
> Here are the primary aspects that come to mind regarding the nature
> and implementation of registration services for Port Numbers and
> Service Prefixes:
>
> (a) Since there is an established and IETF-documented practice
>    for the use of "overlay" / "substrate" SRV Protocol labels,
>    Service Labels making use of these should be registered
>    in a similar manner as others containing proper "transport"
>    Protocols, under the same procedural rules.  The database
>    proposed in draft-tsvwg-iana-ports-02 is neither prepared to,
>    nor suitable for, also accepting the registration of such
>    Service Prefixes not related to IETF transport protocols.

Why do you think that? The unified registry contains service names,  
and is fully agnostic on what protocols those service names are used  
with.

> (b) Most legacy applications with registered port numbers are
>    not prepared to use SRV RRs (yet); it does not make sense
>    to proactively register myriads of labels without having
>    any documentation on the use of service discovery for that
>    service, and without consent and knowledge of the original
>    applicants for port number assignment.

Those labels are *already* registered, in the "keyword" column in the  
current IANA ports registry, and we don't know which ones are used and  
which ones aren't. Which is why we're keeping them defined as they  
currently are (modulo some renaming in very few cases.)

> (c) For compatibility with existing databases and APIs,
>    draft-tsvwg-iana-ports-02 essentially maintains the
>    'classical' size restrictions for Service Names.
>
>    APIs for (dynamic) service discovery will easily admit the use
>    of the common 63-character size for DNS labels (as established
>    by RFCs 1034/1035), for SRV Service labels as well.
>
>    Applications making use of (dynamic) service discovery based
>    on DNS SRV have to be written to use such API, and if existing
>    applications previously bound to an assigned port number are
>    being upgraded to use service discovery, they need to be
>    modified to use such API anyway.
>
>    Therefore, it makes sense to leave existing databases and APIs
>    for Service-Name-to-Port-Number lookup unchanged.

I don't follow. Yes, we want to leave APIs and databases unchanged,  
which is why we're keeping the current size restriction.

> (d) The imminent exhaustion of the port number space is recognized as
>    a reason to encourage the migration to service discovery for new
>    applications; draft-tsvwg-iana-ports-02 also acknowledges that.

There is no danger of "imminent exhaustion" and if our draft leads you  
to believe that there is, we need to change it. System ports are  
somewhat scarce, but even there we have sufficient space left to last  
for years.

>    However, we believe that the procedures envisioned in that draft
>    are much too heavy-weight -- and too burdensome for IANA as
>    well -- for exerting a strong momentum towards service labels.

First, let me point out that Michelle is co-authoring the draft  
*because* we want to make sure that these rules are easier for IANA to  
apply than what currently exists.

Second, the purpose isn't to do an advertisement campaign that creates  
a strong momentum for service names - the purpose is to come up with  
clear and simple registry maintenance rules. If as a secondary effect  
that means that service names become more widely used, great, but  
that's not a primary driver for this draft.

>    The compound database needed for draft-tsvwg-iana-ports-02 and
>    the Expert Review process inadequately address the needs -- of
>    both the prospective applicants and the registry maintainers.

The intent is that no expert review is involved for a service name  
allocation. Expert review only happens for a port number allocation,  
like it does currently. Under the new rules, a service name can be  
allocated FCFS without expert review.

(I just realized that -02 does actually not yet contain this - we need  
to submit -03.)

> (e) The Port Numbers registry and the SRV Service Prefix registry
>    serve very different purposes:
>    i)  registration of and lookup of assigned port numbers
>    ii) registration of Service Prefixes actually defined for
>        service discovery.

(ii) is *your* interpretation. In my reading, the SRV RR RFC makes it  
clear that any service name allocated in the ports registry should be  
usable with SRV RRs.

>    Due to the vastly different sice of the available namespace,
>    both registries need different assignment/registration policies.

True. But that does *not* mean that we need two registries. It just  
means that we need two sets of procedures.

>    For the Service Prefixes (with the exception of the establishment
>    of new Protocol Labels), an extremely lightweight procedure is
>    needed where the role of the IANA is confined to checking
>    uniqueness (avoiding registry-internal collisions and collisions
>    of new Service Labels with Service Names already registered in
>    the Port Numbers registry for other services

Correct. The intent is FCFS.

>    The Port Number registry is heavily constrained by the 16-bit
>    namespace available, with the additional pressure resulting
>    from the security critical need for client port randomization
>    to only assign as few as possible additional port numbers.

Randomization doesn't come into play here, because it's used for the  
source ports, whereas the registry is for destination ports.

>    It is the basic nature of such restricted namespace that the
>    IANA registry for it needs to be under *assignment* paradigm.
>    The port number registry should be regarded as "almost closed"
>    (reserved for cases where service discovery is impossible),
>    and it needs rigid and tight management and strict IANA policy.

No, this is MUCH to restrictive. We're NOT trying to make it harder to  
get a port number than it is currently. Port numbers remain the  
primary service identification method in the Internet. And yes, I  
agree that SRV RRs should be something that should be used more often.  
But making it harder to get port numbers only means more squatting.  
SRV RRs need to become attractive based on their own merits, and not  
because port number are hard to get.

>    Merging such different registries appears as a nightmare for IANA
>    and prospective applicants, and all 'consumers' of the registry.
>    The complicated amalgamated specification needed for the IANA
>    procedures for such registry is contrary to the principles of
>    clarity and simplicity.

FUD. IANA seems to like our proposal. For port number registrants,  
nothing changes much (except that the rules are now documented.) For  
service name registrants, nothing changes much.

> (f) The management of a narrow/scarce namespace (port numbers)
>    should not be conflated with the management of an ample
>    namespace; hence the need to have two independent registries,
>    with existing service names in the Port Numbers registry
>    implicitly reserved for use as Service Labels as well
>    (for all Protocols) for the same application.

See above, you repeated this point for the third time now.

> (g) New applications/services initially registering a SRV Service
>    Prefix but not applying for the assignment of a dedicated
>    port number are very unlikely to do that later.

Maybe yes, maybe no. In our scheme, it's possible, which is nice  
because it leaves the option.

I'm skipping your editorial comments for now.

Thanks,
Lars

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02

On 5 okt 2009, at 11:53, Fernando Gont wrote:

> However, one
> would expect that if a port is allocated by IANA, it is because some
> server app will use it. At that point, for the reasons stated in the
> CPNI document, you should avoid using that port for the ephemeral
> ports.

First of all, server apps may use unallocated ports, too.

Second, how are TCP stacks supposed to know that a port has been  
allocated?

As far as I know, there are no issues with the normal practice of not  
caring about this.

RE: fodder for the proposed FTP feature/cmd registry

I'm not sure if the attached file helps, but I put it together some months ago as a quick reference to the list
of FTP commands, their syntax, and any possible reply codes that I could find. The introduction lists the
RFCs that I used to gather the information.

Thanks!

Robert McMurray
US-IIS Product Unit
Email: robmcm <at> microsoft.com

-----Original Message-----
From: ah <at> TR-Sys.de [mailto:ah <at> TR-Sys.de] 
Sent: Friday, September 25, 2009 10:01 AM
To: john+ietf <at> jck.com
Cc: apps-discuss <at> ietf.org
Subject: fodder for the proposed FTP feature/cmd registry

John,
as promised recently, I have performed some harvesting of RFCs and I-Ds to collect material for the initial
content of the IANA registry proposed in your I-D, draft-klensin-ftp-registry.

Enclosed is a (still rough) tabulation of my results, listing all FTP commands and FTP Features I found
specified in RFCs (since roughly RFC 600, but excluding gravestone dead FTP Mail
stuff) and recent I-Ds.

Kind regards,
  Alfred.

--

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah <at> TR-Sys.de                     |
+------------------------+--------------------------------------------+

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

* was Re: Server Identity Verification in Application Protocols

This specification disallows the use of * to wildcard the reference identity.

syslog over TLS not only uses this, but also allows the use of a wildcard
where it would not be allowed in the subjectAltName.

I would see this as quite common in networking scenarios, where the access
is many to many, and so would like a less severe prescription against it.

Tom Petch

----- Original Message ----- 
From: "Peter Saint-Andre" <stpeter <at> stpeter.im>
To: <apps-discuss <at> ietf.org>
Sent: Saturday, October 03, 2009 12:02 AM
Subject: Server Identity Verification in Application Protocols

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> A new version of draft-saintandre-tls-server-id-check is available:
> 
> http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt
> 
> Other than the informational appendix, the diff from the -01 version is
> relatively minor. Feedback is welcome.
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkrGeG4ACgkQNL8k5A2w/vzsrQCgzyFjxSkoQBp3PVqUmC4/p741
> 0HgAniMwjH+eUXwpokRKU8ZXcIJlEDLu
> =7pso
> -----END PGP SIGNATURE-----
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss <at> ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

client was Re: Server Identity Verification in Application Protocols

This I-D is very hot on the fact that it is about Server Identity, yet
technically, I see no reason why the logic does not also apply equally 
to client identity.

In networking, with the networking box as server, and the client
being the one that wants to change the configuration, then client
identity is the one that matters, not server.

I would like to add an initial paragraph to the effect that although
the memo is written in terms of Server Identity, there is no 
technical reason why the processes described cannot be applied
to verifying the Client Identity.

Tom Petch

----- Original Message ----- 
From: "Peter Saint-Andre" <stpeter <at> stpeter.im>
To: <apps-discuss <at> ietf.org>
Sent: Saturday, October 03, 2009 12:02 AM
Subject: Server Identity Verification in Application Protocols

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> A new version of draft-saintandre-tls-server-id-check is available:
> 
> http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt
> 
> Other than the informational appendix, the diff from the -01 version is
> relatively minor. Feedback is welcome.
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkrGeG4ACgkQNL8k5A2w/vzsrQCgzyFjxSkoQBp3PVqUmC4/p741
> 0HgAniMwjH+eUXwpokRKU8ZXcIJlEDLu
> =7pso
> -----END PGP SIGNATURE-----
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss <at> ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss