Re: [secdir] review of draft-hollenbeck-rfc4933bis-02

["Polk, William T." <[e-mail]>]

I'm a little late to the party, but I have been quietly mulling over this problem as well.  Now that Sandy has explicitly asked for an AD to step in, I figured I should participate more actively.  I have also added Nico Williams to the CC list (my apologies, Nico) since channel bindings is really his area of expertise.

I think there is a real need for channel bindings with some applications of EPP, but may not always be strictly necessary in other cases.  For example, the e-Automation project for the administration of DNS root zone uses EPP but if I recall correctly most of the objects that are transferred are digitally signed objects.  In this case, channel bindings are perhaps less important since we aren't relying solely on the EPP authentication mechanism.  So, in my opinion we should encourage their use but should not require channel bindings.

However, if the application is relying on EPP in combination with transport for security, channel bindings would provide significantly enhanced security.  That says channel bindings deserves to be mentioned and a little guidance on (1) implementing channel bindings and (2) determining when channel bindings is required.  That begs a new question of course - where does this information go?

I am starting to believe that the security considerations section of 4930bis should note that enhanced security SHOULD be achieved through channel bindings unless the application involves digitally signed objects, and that the TLS usage section of 4934bis (section 9) should include a pointer to techniques for implementing channel bindings with TLS.  I am still mulling this over, and will probably not enter any discuss until tomorrow, but this seems the best approach.  (Hopefully Nico will weigh in before then and keep me straight on this one...)

Tim Polk


On 7/15/09 10:51 AM, "Sandra Murphy" <[e-mail]> wrote:

(Note to all.  I sent multiple secdir related messages yesterday
afternoon, and they all were mangled or ultimately not delivered.  So this
is a repeat that some og the recipients may already have seen.
Apologies for the technology failure.)



On Tue, 7 Jul 2009, Scott Hollenbeck said:


>There was no follow-up, so I remain a little unsure of how to address
>the comment.  Similarly, I need a clarification to know if the text
>change suggested below is best made in 4933bis.

Yes, I am guilty of not following up.  I was unsure of my understanding
of channel binding issues, none of the other reviewers of the rfc493*
suite made any notice of the issue, and, as you note here, the
issue is really in the base spec, not 4933.  I just had no idea
what the right process would be, if any.

Subsequent discussion and review of material make me more confident
that there is, indeed, a channel binding issue here.

The question is what to do about it.  This is an established protocol.
Would a security considerations section in 4930bis that pointed out
that there's a MITM attack possible here, because of the lack of
channel binding, be sufficient?  Or would pointing to the sasl-gs2
work as a protection be mentioned?  suggested?  mandated?

I sure would love to see AD or subject matter experts weigh in here
on the technical and process aspects of this.

--Sandy