headers
Simon Josefsson | 15 Oct 2010 14:12
Favicon
Gravatar

RFC 5929 tls-unique clarification?

I'm implementing an API for RFC 5929 in GnuTLS and I'm having some
troubles with the specification.  Section 3.1 says:

   Description: The first TLS Finished message sent (note: the Finished
   struct, not the TLS record layer message containing it) in the most
   recent TLS handshake of the TLS connection being bound to (note: TLS
   connection, not session, so that the channel binding is specific to
   each connection regardless of whether session resumption is used).

I don't follow the need for a distinction between connection and session
here -- a TLS session resumption consists of a new TLS handshake and it
exchanges new Finished messages.

To be precise, is it the case that, for a resumed TLS session, the
tls-unique CB is

1) the first TLS Finished message sent in the initial full TLS
handshake?

or

2) the first TLS Finished message sent in the abbreviated TLS handshake?

In the former case, the text appears to be wrong because it refers to
the most recent TLS handshake and not the initial full TLS handshake,
and in the second case the distinction between session and connection
does not seem to matter because the tls-unique CB data is always using
the first Finished message exchanged in the latest TLS handshake?

/Simon
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Rex | 15 Oct 2010 19:45
Picon
Favicon

Re: RFC 5929 tls-unique clarification?

Simon Josefsson wrote:
> 
> I'm implementing an API for RFC 5929 in GnuTLS and I'm having some
> troubles with the specification.  Section 3.1 says:
> 
> To be precise, is it the case that, for a resumed TLS session, the
> tls-unique CB is
> 
> 2) the first TLS Finished message sent in the abbreviated TLS handshake?

Without having checked implementations, only 2) makes sense.

Binding to the first Finished message that is exchanged helps in
piggy-backing data onto that Finished message (e.g. TLS false start).

But instead of channel bindings, the published TLS CB is about
"connection state binding", because the binding changes
with every renegotiation on existing channel. 

-Martin
Permalink | Reply | 0 comments |
headers
Nicolas Williams | 15 Oct 2010 20:39
Picon
Favicon

Re: RFC 5929 tls-unique clarification?

On Fri, Oct 15, 2010 at 02:12:43PM +0200, Simon Josefsson wrote:
> I'm implementing an API for RFC 5929 in GnuTLS and I'm having some
> troubles with the specification.  Section 3.1 says:
> 
>    Description: The first TLS Finished message sent (note: the Finished
>    struct, not the TLS record layer message containing it) in the most
>    recent TLS handshake of the TLS connection being bound to (note: TLS
>    connection, not session, so that the channel binding is specific to
>    each connection regardless of whether session resumption is used).
> 
> I don't follow the need for a distinction between connection and session
> here -- a TLS session resumption consists of a new TLS handshake and it
> exchanges new Finished messages.

Some people thought that we needed to be clear about this in case
someone thought that the CB for a TLS connection were those of the
handshake that created the session.  You can see that that would be bad.

> To be precise, is it the case that, for a resumed TLS session, the
> tls-unique CB is
> 
> 1) the first TLS Finished message sent in the initial full TLS
> handshake?
> 
> or
> 
> 2) the first TLS Finished message sent in the abbreviated TLS handshake?

(2).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 15 Oct 2010 22:25
Favicon
Gravatar

Re: RFC 5929 tls-unique clarification?

Nicolas Williams <Nicolas.Williams <at> oracle.com> writes:

> On Fri, Oct 15, 2010 at 02:12:43PM +0200, Simon Josefsson wrote:
>> I'm implementing an API for RFC 5929 in GnuTLS and I'm having some
>> troubles with the specification.  Section 3.1 says:
>> 
>>    Description: The first TLS Finished message sent (note: the Finished
>>    struct, not the TLS record layer message containing it) in the most
>>    recent TLS handshake of the TLS connection being bound to (note: TLS
>>    connection, not session, so that the channel binding is specific to
>>    each connection regardless of whether session resumption is used).
>> 
>> I don't follow the need for a distinction between connection and session
>> here -- a TLS session resumption consists of a new TLS handshake and it
>> exchanges new Finished messages.
>
> Some people thought that we needed to be clear about this in case
> someone thought that the CB for a TLS connection were those of the
> handshake that created the session.  You can see that that would be bad.

Yes, but even after multiple re-readings I was still confused what the
text really said.

>> To be precise, is it the case that, for a resumed TLS session, the
>> tls-unique CB is
>> 
>> 1) the first TLS Finished message sent in the initial full TLS
>> handshake?
>> 
>> or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Williams | 15 Oct 2010 23:05
Picon
Favicon

Re: RFC 5929 tls-unique clarification?

On Fri, Oct 15, 2010 at 10:25:33PM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams <at> oracle.com> writes:
> 
> > On Fri, Oct 15, 2010 at 02:12:43PM +0200, Simon Josefsson wrote:
> >> I'm implementing an API for RFC 5929 in GnuTLS and I'm having some
> >> troubles with the specification.  Section 3.1 says:
> >> 
> >>    Description: The first TLS Finished message sent (note: the Finished
> >>    struct, not the TLS record layer message containing it) in the most
> >>    recent TLS handshake of the TLS connection being bound to (note: TLS
> >>    connection, not session, so that the channel binding is specific to
> >>    each connection regardless of whether session resumption is used).
> >> 
> >> I don't follow the need for a distinction between connection and session
> >> here -- a TLS session resumption consists of a new TLS handshake and it
> >> exchanges new Finished messages.
> >
> > Some people thought that we needed to be clear about this in case
> > someone thought that the CB for a TLS connection were those of the
> > handshake that created the session.  You can see that that would be bad.
> 
> Yes, but even after multiple re-readings I was still confused what the
> text really said.

Sigh.  It took a lot of negotiation to get text that made everyone
happy.  And it's still not good enough?  But I think it's clear...
Maybe it's just me.

> >> 2) the first TLS Finished message sent in the abbreviated TLS handshake?
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 15 Oct 2010 23:22
Favicon
Gravatar

Re: RFC 5929 tls-unique clarification?

Nicolas Williams <Nicolas.Williams <at> oracle.com> writes:

> On Fri, Oct 15, 2010 at 10:25:33PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <Nicolas.Williams <at> oracle.com> writes:
>> 
>> > On Fri, Oct 15, 2010 at 02:12:43PM +0200, Simon Josefsson wrote:
>> >> I'm implementing an API for RFC 5929 in GnuTLS and I'm having some
>> >> troubles with the specification.  Section 3.1 says:
>> >> 
>> >>    Description: The first TLS Finished message sent (note: the Finished
>> >>    struct, not the TLS record layer message containing it) in the most
>> >>    recent TLS handshake of the TLS connection being bound to (note: TLS
>> >>    connection, not session, so that the channel binding is specific to
>> >>    each connection regardless of whether session resumption is used).
>> >> 
>> >> I don't follow the need for a distinction between connection and session
>> >> here -- a TLS session resumption consists of a new TLS handshake and it
>> >> exchanges new Finished messages.
>> >
>> > Some people thought that we needed to be clear about this in case
>> > someone thought that the CB for a TLS connection were those of the
>> > handshake that created the session.  You can see that that would be bad.
>> 
>> Yes, but even after multiple re-readings I was still confused what the
>> text really said.
>
> Sigh.  It took a lot of negotiation to get text that made everyone
> happy.  And it's still not good enough?  But I think it's clear...
> Maybe it's just me.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Williams | 16 Oct 2010 00:03
Picon
Favicon

Re: RFC 5929 tls-unique clarification?

On Fri, Oct 15, 2010 at 11:22:06PM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams <at> oracle.com> writes:
> > Sigh.  It took a lot of negotiation to get text that made everyone
> > happy.  And it's still not good enough?  But I think it's clear...
> > Maybe it's just me.
> 
> Describing a couple of different TLS flows (e.g., one normal, one
> resumed, one renegotiated) and what the binding should be in each case
> would have helped me.  But the RFC is already published so there is no
> point now.

That would have made it quite lengthy, but, yes, that might have helped.
Brevity, when concise, helps though, and we thought we had both
attributes for the text.

> >> http://www.gnu.org/software/gnutls/devel/manual/html_node/Channel-Bindings.html
> >> http://www.gnu.org/software/gnutls/devel/manual/html_node/Core-functions.html#gnutls_005fsession_005fchannel_005fbinding
> >
> > Awesome!
> >
> > Do you also support tls-server-end-point?
> 
> Nope, but it should be possibly to implement using already existing APIs
> anyway.  Still, it is on my todo list.
> 
> One concern with the tls-server-end-point definition is that I'm not
> sure what to do if the local code don't implement the hash function used
> by the server certificate.  Hopefully this won't be common in practice
> though.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 16 Oct 2010 09:07
Favicon
Gravatar

Re: RFC 5929 tls-unique clarification?

Nicolas Williams <Nicolas.Williams <at> oracle.com> writes:

>> Nope, but it should be possibly to implement using already existing APIs
>> anyway.  Still, it is on my todo list.
>> 
>> One concern with the tls-server-end-point definition is that I'm not
>> sure what to do if the local code don't implement the hash function used
>> by the server certificate.  Hopefully this won't be common in practice
>> though.
>
> How can you verify the server cert if you don't have an implementation
> of the server cert's signature algorithm's hash algorithm??
> (Answer: PKIX and TLS are different layers, and you might not have an
> implementation of that hash alg available to the TLS stack).

Yes, and there are other potential answers too -- e.g., no PKIX
validation at all but instead trust SCRAM with channel binding to
protect against MITM, or validation of PKIX material by a hard coded
fingerprint or through a Keyassure approach.

> Anyways, that brings up another issue: the application may negotiate CB
> types, for all we know, so it's important to know what CB types will be
> available.  You might want to add a function that tells you what CB
> types are available for a given session.  (Well, OK, the app could just
> ask for all CB types and then determine which are available that way.)
>
> Also, you might want an API by which to tell TLS which CB type the app
> will need, that way the TLS library can throw away CB data that won't be
> needed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 17 Oct 2010 07:58
Favicon

Re: RFC 5929 tls-unique clarification?

Simon Josefsson wrote:

>Nicolas Williams <Nicolas.Williams <at> oracle.com> writes:
>
>  
>
>>On Fri, Oct 15, 2010 at 10:25:33PM +0200, Simon Josefsson wrote:
>>    
>>
>>>Nicolas Williams <Nicolas.Williams <at> oracle.com> writes:
>>>
>>>      
>>>
>>>>On Fri, Oct 15, 2010 at 02:12:43PM +0200, Simon Josefsson wrote:
>>>>        
>>>>
>>>>>I'm implementing an API for RFC 5929 in GnuTLS and I'm having some
>>>>>troubles with the specification.  Section 3.1 says:
>>>>>
>>>>>   Description: The first TLS Finished message sent (note: the Finished
>>>>>   struct, not the TLS record layer message containing it) in the most
>>>>>   recent TLS handshake of the TLS connection being bound to (note: TLS
>>>>>   connection, not session, so that the channel binding is specific to
>>>>>   each connection regardless of whether session resumption is used).
>>>>>
>>>>>I don't follow the need for a distinction between connection and session
>>>>>here -- a TLS session resumption consists of a new TLS handshake and it
>>>>>exchanges new Finished messages.
>>>>>          
>>>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 18 Oct 2010 09:18
Favicon

SCRAM (RF 5802) implementation in Java?

Does anybody know of a Java SCRAM-SHA-1 implementation?
Please reply privately.

Thanks,
Alexey
Permalink | Reply | 0 comments |

Gmane