Subject: IPP> Area Directors' comments on IPP

From: Carl-Uno Manros <[email-masked]>
Date: Sun, 7 Dec 1997 18:29:18 PST

Hi all,

I had a short chat with Harald and Keith this evening (Sunday) about a
couple of IPP subjects:

1) Support for SSL3 in TLS. Harald and Keith wanted to make sure that our
specs say that we MUST support the mandatory features that are minimum
requirements for TLS, such as the cypher suite. They seemed a bit uncertain
whether it was wise to also require mandatory support for SSL3 (due to the
RSA licencing). Maybe we should change that to a strong recommendation
rather than the conditional SHALL that we now have? I think that as the TLS
minimum alone really doesn't do the job, so we need to keep at least that
recommendation in the IPP spec. I expect this to come up during the IPP
meeting on Wednesday, so stay tuned. 

2) Alignment with Harald's I-D on IANA registration procedures
<draft-iesg-iana-considerations-01.txt>. We should be in reasonable shape
here already, as Harald said that he had actually used our IPP Model
document as partial input for his I-D on the subject. There is no formal
requirement to adhere to Harald's I-D at this stage.

Regards,

Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 08 Dec 1997 13:22:48 -0500

> requirements for TLS, such as the cypher suite. 

1. IESG has not allowed other groups to reference SSL, and it unlikely
that an exception would be made for IPP.  If IPP uses SSL-like
technology, the reference should be to the TLS RFC.

2. If IPP specifies TLS authentication, IPP must either implicitly use
the mandatory ciphersuite from the TLS spec, or specify at least one
mandatory TLS ciphersuite.

3. It will be very difficult for IPP to convince IESG to accept any
mandatory TLS ciphersuite that uses encumbered algorithms, especially
given that adequate unencumbered algorithms seem to be available.

Suggestion: specify MUST implement ciphersuite
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, and MAY (or SHOULD?) implement one
or more of the ciphersuites commonly used with SSL3.

Keith

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 9 Dec 1997 05:46:23 PST

Keith and Harold,

I think that the Application Area in general has a serious process problem.

We have spent considerable time and effort in the IPP project studying and
evaluating security services and security options. In parallell, the
Security Area seems to contuinually change the rules of the game. As I have
stated before, I think that we, the Application Area standards developers
are the main customers of the Security Area and they seem to ignore us
totally. We are getting tired of trying to predict what may or may not fly
in the IESG, when it comes to security options.

If the security people are going to dictate in every detail what we can or
cannot do, then I think it is their responsibility to make sure that they
participate in our WGs to give advice us advice in the context of our needs
and discussions, rather than come down and criticize what we have done
every time we think we have found an acceptable solution. 

Keith and Harald, with all due respect, your advice in th area of security
has not been very reliable either; we need the advice directly from the
people who is going to review this aspect of our work in the IESG. 

Yesterday's Application Area WG meetings in the IETF showed very clearly to
me that several other Application Area WGs are in the same boat as we are
here. I pointed out these problems in the Application Area WG Chair
meetings during the previous two IETF meetings, but the situation has not
improved. Action, please!

My 2 cents,

Carl-Uno Manros

In my role as co-chair if the IPP WG

Carl-Uno Manros

---

From: [email-masked]
Date: Tue, 09 Dec 1997 16:19:52 -0500

Carl-Uno,

you say:
> If the security people are going to dictate in every detail what we
> can or cannot do, then I think it is their responsibility to make sure
> that they participate in our WGs to give advice us advice in the
> context of our needs and discussions, rather than come down and
> criticize what we have done every time we think we have found an
> acceptable solution.

I would say that the foot is definitely in the other shoe:
If you see that protocol development is being done which will
impact your product, it is definitely in your interest to make
sure that the people doing that development know your requirements.

It is 100% obvious to you that when you consider using TLS, the
TLS group is an interesting forum for you.
It is not at all obvious to the TLS group that there is anything
going on in Internet printing that impacts requirements for TLS.
That group too is an open forum; the reason you are not a member is
because you have chosen not to be.
Most of the people working on TLS are there because they need TLS in
*other* projects; their own requirements are obvious to them, yours
are not.
And remember: this is not something they do for a hobby; anything
we ask them to do above what they already do usually comes straight
out of their spare time.

The security requirements are really, really simple:
- THINK about what security your application needs, and provide that
- No plaintext passwords
The requirements that apply to ALL protocols, in ALL aspects are:
- Enough requirements to ensure interoperability
- Avoid use of IPR-tainted technology whenever reasonable.
The last two are NOT security requirements, it's just that the
security area, thanks to RSA, has one of the nastiest examples of this
being a problem.

BTW, I consulted with the security AD about ciphersuites in TLS; he
was quite surprised that anyone would consider using TLS without
security, since this adds quite a bit of overhead over raw TCP.
Ciphersuites are "numbered items", but the intent of the TLS group
is that it should be simple to add new ones; the reason for using
suites rather than feature combinations is that some combinations
of features have non-obvious but serious security flaws.
If you want a ciphersuite with different properties than the existing
set, take this up with the TLS group. [email-masked]; use the
-request convention to subscribe.

            Harald A

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 9 Dec 1997 19:05:57 PST

Harald,

We have been following the TLS activities for some time and have also held
discussions with individual members of the WG. We were happy to use the TLS
functionality as documented up to their last draft but one, but in the
final version that was passed by the IESG they suddenly introduced some new
mandatory stuff, for which we have so far seen little or no rationale or
explanation.

Just now I am only interested to get a recommendation, from whoever
consider themselves qualified, about a "politically correct" combination of
TLS security features that provides the same functionality as SSL3. Is this
concrete enough?

Carl-Uno

Carl-Uno Manros

---

From: [email-masked]
Date: Wed, 10 Dec 1997 09:29:07 -0500

Carl-Uno said:

> We were happy to use the TLS functionality as documented up to their
> last draft but one, but in the final version that was passed by the
> IESG they suddenly introduced some new mandatory stuff, for which we
> have so far seen little or no rationale or explanation.

The mandatory stuff (section 9 of the TLS document) was added by
the TLS WG after explicit instructions from the Security AD, with
explicit backing from the plenary at the Munich IETF.

It was added in order to satisfy the requirements for interoperability
and avoidance of IPR issues that are common to all IETF protocols.

I don't know of any other last-minute changes, but this particular
section of the TLS spec should hardly come as a surprise to anyone;
it was the subject of great debate over the last 6 months.

Was this the only change you had problems with?

              Harald A