[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] AD review of draft-ietf-tls-oob-pubkey
From:       Sean Turner <turners () ieca ! com>
Date:       2013-05-24 17:14:02
Message-ID: 519F9FDA.7080103 () ieca ! com
[Download RAW message or body]

I think I didn't yet respond to some of these.

On 5/7/13 11:11 PM, Joseph Salowey (jsalowey) wrote:
> Most of these look reasonable to me, a few comments inline at the end.
> 
> Thanks,
> 
> Joe
> On Apr 16, 2013, at 7:06 AM, Sean Turner <turners@ieca.com> wrote:

> > 10) s4.2:  Maybe reword this slightly:
> > 
> > OLD:
> > 
> > If the client indicated the support of raw public keys in the
> > 'client_certificate_type' extension in the client hello and the
> > server is able to provide such raw public key then the TLS server
> > MUST place the SubjectPublicKeyInfo structure into the Certificate
> > payload.
> > 
> > NEW:
> > 
> > If the client hello indicates support of raw public keys in the
> > 'client_certificate_type' extension and the
> > server also supports raw public keys then the TLS server
> > MUST place the SubjectPublicKeyInfo structure into the Certificate
> > payload.
> > 
> > But, a more important question is the meaning of that paragraph above. Doesn't \
> > that override the "sorted by client preference" from s3? 
> 
> [Joe]   I think this should probably say something like:
> 
> "If the client hello indicates support of raw public keys in the
> 'client_certificate_type' extension and the
> server chooses to use raw public keys then the TLS server
> MUST place the SubjectPublicKeyInfo structure into the Certificate
> payload.

Yep that's what I was thinking.

> > 11) s6: Got some questions about the following:
> > 
> > This information will be needed to make
> > authorization decisions.  Without a secure binding,
> > man-in-the-middle attacks may be the consequence.
> > 
> > 1st isn't that authentication.  2nd isn't it masquerade attacks?  3rd it's not \
> > really a may it's more an is likely to be? 
> 
> [Joe]  I'm not sure binding a key to a name is exactly authentication.  I'd \
> probably reword it something like: 
> "Without a secure binding between identity and key the protocol will be vulnerable \
> to masquerade and man-in-the-middle attacks."

I could live with that.

> > 13) How are we supposed to check whether key is still considered "good"?  If you \
> > can't that might be okay, but you need to mention that there's no mechanism to \
> > support this yet or that that also needs to be done out-of-band. 
> 
> [Joe] I think we need to state this is done out of band as well.

Yeah all I'm looking for here is a warning that there's currently no 
mechanism to support this.  I was going to go and say that the 
application needs to define who this might be done, but after talking it 
over with a couple of folks what it's going to come down to is asking 
those applications when we see them calling out use of this document if 
they really want status checking.

spt


[prev in list] [next in list] [prev in thread] [next in thread]