Subject: Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211

From: [email-masked]
Date: Fri, 1 Jun 2012 09:24:13 +0200

First of all, thank you for both of you for your fast response.

I am not arguing there is an RFC 5742 conflict with this document.

Since you said that is an attempt to document an existing deployed 
protocol, we cannot change it.

Since you said that designing a better protocol is an expected follow-on 
work, I raise the question to both the editors and the WG chairs 
whether the document should be on the experimental track rather than on 
the informational track.

Clearly, I believe that only changes to the security consideration 
sections should be made, keeping in mind that 
confidentiality an integrity protection can be done at lower layers. This 
is what the security considerations section should recommend.

Finally, I believe an errata on RFC 4211 should be prepared, but this is a 
separate concern with Jim.

Denis

De :    Russ Allbery <[email-masked]>
A :     [email-masked]
Cc :    [email-masked], Jim Schaad <[email-masked]>, pkix 
<[email-masked]>
Date :  01/06/2012 07:20
Objet : Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211

[email-masked] writes:

> I skimmed through the document and read the following two sentences:

>    The public key in the request is sent in the clear, and without any
>    guarantees that the requestor actually possesses the corresponding
>    private key.

>    [RFC4211], Appendix C contains a more detailed discussion of why 
>    proof-of-possession is important.

> I have concerns with both sentences.

> [RFC4211] is incorrect and this has security implications on the
> proposed protocol.

Hi Denis,

As Henry has mentioned, we have the limitation with this particular
document that we're attempting to document an existing, deployed protocol
sufficiently that interoperable implementations can be created.  This
protocol is deficient in multiple ways, and designing a better protocol is
expected follow-on work.  Changing something fundamental, such as
requiring confidentiality in this protocol exchange, would defeat the
point of the current work.

Therefore, I think that any remedy here should be limited to clearly
documenting the issue in the Security Considerations section rather than
changing the protocol.

If I'm understanding your message properly, you're saying that there is a
partial defense against the lack of proof-of-possession by adding
confidentiality protection to the exchange.  I'm not sure in this context
whether this really changes the security analysis of this protocol, given
that no confidentiality is used.  But if I'm missing something, could you
suggest something that we could add to Security Considerations?

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 1 Jun 2012 01:17:02 -0700

> First of all, thank you for both of you for your fast response. 

No prob.

> I am not arguing there is an RFC 5742 conflict with this document. 

OK.  Thanks.

> Since you said that is an attempt to document an existing deployed protocol, we cannot change it. 
> 
> Since you said that designing a better protocol is an expected follow-on work, I raise the question to both the editors and the WG chairs whether the document should be on the experimental track rather than on the informational track. 

The question has come up before, at least generically.  (With Steve Kent IIRC.)  I don't think it should be standards track because we want to fix it.  I don't think it's actually experimental because it's somewhat widely deployed.  I don't think it's historic because it's currently in use and we don't have a replacement designed yet.  I do think it's informational because, well, the document is providing useful information about a real internet protocol.

> Clearly, I believe that only changes to the security consideration sections should be made, keeping in mind that confidentiality an integrity protection can be done at lower layers. This is what the security considerations section should recommend. 

As I said in other email, adding confidentiality will probably be done in a future, incompatible version.  Integrity protection is already provided (though without algorithm agility which will also be added in a future, incompatible version).  The existing deployments are over bare UDP.

> Finally, I believe an errata on RFC 4211 should be prepared, but this is a separate concern with Jim. 
> 
> Denis 
> 
> 
> 
> Cc :        [email-masked], Jim Schaad <[email-masked]>, pkix <[email-masked]> 
> Date :        01/06/2012 07:20 

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Jun 2012 17:22:14 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

Hi.  I believe that this issue has been discussion in the Kerberos
working group and we asked the author to document the existing KX509
protocol and publish that so we'd have a historical record of what is
done today.  It's likely we'll do work in this space in the future but
it's our desire that work be informed by an existing historical record
and the current draft will help us with that.

So, with my chair hat on, I believe this has already been discussed in
Kerberos and we support publication. Which is to say, no conflict here.

    Stephen> I'll take silence as meaning that nobody thinks that
    Stephen> there's a conflict. If someone thinks there is a conflict
    Stephen> let me, the list, or the wg chairs know. In due course,
    Stephen> I'll be doing my own evaluation as well of course, as will
    Stephen> other IESG members.

    Stephen> Thanks, Stephen.

    Stephen> [1] http://tools.ietf.org/html/draft-hotz-kx509-04 [2]
    Stephen> http://tools.ietf.org/html/rfc5742

    Stephen> _______________________________________________ ietf-krb-wg
    Stephen> mailing list [email-masked]
    Stephen> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Jun 2012 15:06:36 -0400

At 9:24 AM +0200 6/1/12, [email-masked] wrote:
>Since you said that designing a better protocol is an expected 
>follow-on work, I raise the question to both the editors and the WG 
>chairs
>whether the document should be on the experimental track rather than 
>on the informational track.

Necause this is documenting an extant protocol, informational seems more
appropriate than experimental.

Steve