Subject: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

From: Robert Sayre <[email-masked]>
Date: Tue, 13 Mar 2007 12:15:14 -0400

From the draft:
>  At a minimum, client and server implementations MUST be capable of
>  being configured to use HTTP Basic Authentication [RFC2617] in
>  conjunction with a TLS connection as specified by [RFC2818].  See
>  [RFC4346] for more information on TLS.

I've discovered a small but potentially critical mistake in the 
references here. RFC2818 is an informative reference, so the text must 
read "as specified by [RFC4346]".

- Rob

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Tue, 13 Mar 2007 13:52:27 -0400

>>>>> "Robert" == Robert Sayre <[email-masked]> writes:

    Robert> From the draft:
    >> At a minimum, client and server implementations MUST be capable
    >> of being configured to use HTTP Basic Authentication [RFC2617]
    >> in conjunction with a TLS connection as specified by [RFC2818].
    >> See [RFC4346] for more information on TLS.

    Robert> I've discovered a small but potentially critical mistake
    Robert> in the references here. RFC2818 is an informative
    Robert> reference, so the text must read "as specified by
    Robert> [RFC4346]".

My preference is to resolve this by making 2818 normative; I believe
we've already 3967'd 2818 so we don't need an additional last call on
this one.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 13 Mar 2007 14:38:09 -0400

> we've already 3967'd 2818 so we don't need an additional last call on

Is RFC 2818 sufficient to ensure interoperability?  It would be quite 
easy for two implementations to claim to implement "TLS" and fail to 
interoperate. RFC 4346 contains mandatory cipher suites. Without those, 
conformant implementations could fail during authentication setup, 
right? The same danger would exist if the draft claimed "HTTP 
Authentication" must be supported without specifying a scheme.

- Rob

---

From: Sam Hartman <[email-masked]>
Date: Tue, 13 Mar 2007 14:47:14 -0400

Robert> Sam Hartman wrote:
    >> My preference is to resolve this by making 2818 normative; I
    >> believe we've already 3967'd 2818 so we don't need an
    >> additional last call on this one.
    >> 

    Robert> Is RFC 2818 sufficient to ensure interoperability?  It
    Robert> would be quite easy for two implementations to claim to
    Robert> implement "TLS" and fail to interoperate. RFC 4346
    Robert> contains mandatory cipher suites. Without those,
    Robert> conformant implementations could fail during
    Robert> authentication setup, right? The same danger would exist

I think both 2818 and 4346 contain important details and need to be
normative.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 13 Mar 2007 15:23:22 -0400

> I think both 2818 and 4346 contain important details and need to be

That makes sense to me. However, I initially thought the references had 
been mistakenly switched around.

>  [RFC4346] for more information on TLS. 

This text is actively misleading, because it suggests RFC 4346 is 
included for informational purposes. The text should read:

"At a minimum, client and server implementations MUST be capable of
 being configured to use HTTP Basic Authentication [RFC2617] in
 conjunction with a TLS connection as specified by [RFC2818] and
 [RFC4346]."

- Rob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Mar 2007 13:35:34 +0100

On 2007-03-13 20:43, Cyrus Daboo wrote:
> Hi Robert,
> 
> --On March 13, 2007 3:23:22 PM -0400 Robert Sayre <[email-masked]> 
> wrote:
> 
> The text that got used in CalDAV (which is about to be published) is:
> 
>   o  MUST support transport over TLS [RFC2246] as defined in [RFC2818]
>      (note that [RFC2246] has been obsoleted by [RFC4346]);
> 
> with 2246, 2818 and 4346 all normative references. These type of 
> "up-references" are not ideal and I believe there was some discussion 
> going on somewhere about how better to deal with this type of situation.

You may be thinking of draft-klensin-norm-ref, which is in Last Call
as BCP through Friday this week.

Just to confirm: 2818 has already been "downrefed" so it can be used in
this way without further formality.

http://www1.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

     Brian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Mar 2007 14:09:16 +0100

Brian E Carpenter schrieb:
> ...

As pointed out before, that text really is confusing. As a reader. I'm 
left wondering whether I need to implement RFC2246 or RFC4346. Or both?

Best regards, Julian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 14 Mar 2007 16:17:09 +0200 (EET)

> http://www1.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

There appear to have been two kinds of Last Calls:
  1) Last Call for document X which also last calls that document's 
downrefs, and
  2) Separate Last Call about downrefs to document Y (rare, see 31 Jan 
2007 example below)

Which one(s) are you referring to?

If 1), there seems to be an assumption that if document X downrefs 
document Y, and that downref is last-called, there is no need to Last 
Call any downref to document Y.

There is no text in the Last Call message to suggests the downref 
should be considered in a 'global' sense (more like 2) above), instead 
of in the context of the referencing document.

I certainly wouldn't go as far as to say that if it's OK for 
draft-dusseault-caldav to use RFC2818 in a normative sense, it would 
automatically make it OK in every other protocol as well.

RFC 3967 says:
=====
    Once a specific down reference to a particular document has been
    accepted by the community (e.g., has been mentioned in several Last
    Calls), an Area Director may waive subsequent notices in the Last
    Call of down references to it.  This should only occur when the same
    document (and version) are being referenced and when the AD believes
    that the document's use is an accepted part of the community's
    understanding of the relevant technical area.  For example, the use
    of MD5 [RFC1321] and HMAC [RFC2104] is well known among
    cryptographers.
=====

And I'm not sure if those requirements have been fulfilled yet. Am I 
missing something?

FWIW, there appear to be errors in the DownrefRegistry above.  For 
example, draft-ietf-lemonade-compress has not been Last Called this 
year, and when -06 version was in Dec 2006, it had no mention of 
downref.  There is a 'global'-like Last Call on 31 Jan 2007 but it 
seems to be about RFC 1951, not 1531.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: EKR <[email-masked]>
Date: Wed, 14 Mar 2007 07:49:26 -0700

Julian Reschke <[email-masked]> writes:

>>> "up-references" are not ideal and I believe there was some
>>> discussion going on somewhere about how better to deal with this
>>> type of situation.
>> ...
>

I wish I knew the answer to this question as well... :)

Seriously, we're shortly going three separate versions of TLS 
standardized, 1.0, 1.1, and 1.2, plus SSLv3. So, the question
of what to require implementors to do is a tricky one that
actually doesn't have that much to do with TLS :)

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Mar 2007 16:32:33 +0100

>  2) Separate Last Call about downrefs to document Y (rare, see 31 Jan 

2) is a special case of 1) in which the downref was initially
overlooked but was detected during the initial Last Call.

> There is no text in the Last Call message to suggests the downref should 
> be considered in a 'global' sense (more like 2) above), instead of in 
> the context of the referencing document.

No, that text is in RFC 3967.
> And I'm not sure if those requirements have been fulfilled yet. Am I 

The IESG is working on the basis that those requirements have been
met in this case. If not, the downref would need to be mentioned
in a Last Call.

This is one of the reasons draft-klensin-norm-ref is in Last Call;
although it doesn't remove the RFC 3967 procedure, it will make
things a lot clearer to anyone reviewing a draft that makes a
downref.

> downref.  There is a 'global'-like Last Call on 31 Jan 2007 but it seems 
> to be about RFC 1951, not 1531.)
> 

Yes, this seems odd. In fact -compress-07 cites 1951 and not 1531.

But on the other hand
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg03396.html
mentions a downref to 3576 which is not yet listed. And
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg03388.html
mentions a downref to 35985 which is not yet listed. There's
clearly some work to do to get this running smoothly.

     Brian

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 13 Mar 2007 15:43:30 -0400

Hi Robert,

with 2246, 2818 and 4346 all normative references. These type of 
"up-references" are not ideal and I believe there was some discussion going 
on somewhere about how better to deal with this type of situation.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 13 Mar 2007 15:43:30 -0400

Hi Robert,

-- 
Cyrus Daboo