[TLS] tls-unique

[Simon Josefsson]

The notes from the interim meeting mentions 'tls-unique' and points to
issue #228 on github.  I want to get your attention on the draft below.
Doesn't it do what you are looking for?  There is a little in the way of
a problem statement in the TLS interim meeting notes, so it is hard to
tell what the perceived problem with 'tls-unique' is in this context.
Does my draft need to be updated for TLS 1.3 in any way?  It might serve
as a starting point for future work.

https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03

/Simon


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] tls-unique

[Eric Rescorla]

On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson 
wrote:

> The notes from the interim meeting mentions 'tls-unique' and points to
> issue #228 on github.  I want to get your attention on the draft below.
> Doesn't it do what you are looking for?  There is a little in the way of
> a problem statement in the TLS interim meeting notes, so it is hard to
> tell what the perceived problem with 'tls-unique' is in this context.
> Does my draft need to be updated for TLS 1.3 in any way?  It might serve
> as a starting point for future work.
>
> https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03


Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF.

With that said, I don't really understand the structure of your draft:
Instead of referencing the PRF and session_hash directly, why not instead
use RFC 5705 exporters and require the use of the session_hash extension?
Then TLS 1.3 can just define exporters for 1.3 and we'll be done.

-Ekr


> /Simon
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] tls-unique

[Simon Josefsson]

Eric Rescorla  writes:

> On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson 
> wrote:
>
>> The notes from the interim meeting mentions 'tls-unique' and points to
>> issue #228 on github.  I want to get your attention on the draft below.
>> Doesn't it do what you are looking for?  There is a little in the way of
>> a problem statement in the TLS interim meeting notes, so it is hard to
>> tell what the perceived problem with 'tls-unique' is in this context.
>> Does my draft need to be updated for TLS 1.3 in any way?  It might serve
>> as a starting point for future work.
>>
>> https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03
>
>
> Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF.
>
> With that said, I don't really understand the structure of your draft:
> Instead of referencing the PRF and session_hash directly, why not instead
> use RFC 5705 exporters and require the use of the session_hash
> extension?

The introduction says:

   There exists a TLS extension [I-D.ietf-tls-session-hash] that modify
   TLS so that the definition of 'tls-unique' [RFC5929] has the intended
   properties.  If widely implemented and deployed, the channel binding
   type in this document would not offer any additional protection.  The
   purpose of this document is to provide an alternative channel binding
   that offers the intended properties without requiring TLS protocol
   changes.  However, keep in mind that TLS implementations needs to
   offer the appropriate APIs necessary to be able to implement the
   channel binding described in this document.

I agree that one alternative is to require session_hash for all
connections.  But then what is the problem with use of 'tls-unique'?
The github issue and the interim notes aren't clear on that.

> Then TLS 1.3 can just define exporters for 1.3 and we'll be done.

Right.  My draft intends to use TLS exporters but I see that it isn't
aligned with RFC 5705.

/Simon


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] tls-unique

[Eric Rescorla]

On Thu, Oct 8, 2015 at 12:16 PM, Simon Josefsson 
wrote:

> Eric Rescorla  writes:
>
> > On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson 
> > wrote:
> >
> >> The notes from the interim meeting mentions 'tls-unique' and points to
> >> issue #228 on github.  I want to get your attention on the draft below.
> >> Doesn't it do what you are looking for?  There is a little in the way of
> >> a problem statement in the TLS interim meeting notes, so it is hard to
> >> tell what the perceived problem with 'tls-unique' is in this context.
> >> Does my draft need to be updated for TLS 1.3 in any way?  It might serve
> >> as a starting point for future work.
> >>
> >> https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03
> >
> >
> > Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF.
> >
> > With that said, I don't really understand the structure of your draft:
> > Instead of referencing the PRF and session_hash directly, why not instead
> > use RFC 5705 exporters and require the use of the session_hash
> > extension?
>
> The introduction says:
>
>There exists a TLS extension [I-D.ietf-tls-session-hash] that modify
>TLS so that the definition of 'tls-unique' [RFC5929] has the intended
>properties.  If widely implemented and deployed, the channel binding
>type in this document would not offer any additional protection.  The
>purpose of this document is to provide an alternative channel binding
>that offers the intended properties without requiring TLS protocol
>changes.  However, keep in mind that TLS implementations needs to
>offer the appropriate APIs necessary to be able to implement the
>channel binding described in this document.
>
> I agree that one alternative is to require session_hash for all
> connections.


Given that you need to modify *some* software in any case, it seems
like one ought to adopt session-hash.



>   But then what is the problem with use of 'tls-unique'?
>

The general consensus is that 96 bits is too short.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] tls-unique

[Simon Josefsson]

> > The introduction says:
> >
> >There exists a TLS extension [I-D.ietf-tls-session-hash] that
> > modify TLS so that the definition of 'tls-unique' [RFC5929] has the
> > intended properties.  If widely implemented and deployed, the
> > channel binding type in this document would not offer any
> > additional protection.  The purpose of this document is to provide
> > an alternative channel binding that offers the intended properties
> > without requiring TLS protocol changes.  However, keep in mind that
> > TLS implementations needs to offer the appropriate APIs necessary
> > to be able to implement the channel binding described in this
> > document.
> >
> > I agree that one alternative is to require session_hash for all
> > connections.
> 
> 
> Given that you need to modify *some* software in any case, it seems
> like one ought to adopt session-hash.

The problem is if you want to resolve this at the application level and
don't have sufficient control over the TLS layer to influence it to
negotiate session-hash.  This is the situation for many SASL
applications.

If universal adoption of session-hash is a prio, then there is no
problem.  While RFC 7627 updates 5246 it does not talk a lot about what
it actually updates in 5246, or I missed it, and I haven't seen
session-hash functionality back-ported to deployed code.

My current approach works with or without session-hash negotiated, but
requires that you can get the session_hash value out of the TLS stack.

Another approach is to say that if session-hash is in use, it uses a
simple TLS exporter API call, and if it is not, it has to use TLS
exporter API on the session_hash value.  This would secure all cases.

> >   But then what is the problem with use of 'tls-unique'?
> 
> The general consensus is that 96 bits is too short.

I agree -- I used 256 bits.

/Simon


pgpP0BuKKpBQi.pgp
Description: OpenPGP digital signatur
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] tls-unique

[Eric Rescorla]

On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson  wrote:

> > > The introduction says:
> > >
> > >There exists a TLS extension [I-D.ietf-tls-session-hash] that
> > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the
> > > intended properties.  If widely implemented and deployed, the
> > > channel binding type in this document would not offer any
> > > additional protection.  The purpose of this document is to provide
> > > an alternative channel binding that offers the intended properties
> > > without requiring TLS protocol changes.  However, keep in mind that
> > > TLS implementations needs to offer the appropriate APIs necessary
> > > to be able to implement the channel binding described in this
> > > document.
> > >
> > > I agree that one alternative is to require session_hash for all
> > > connections.
> >
> >
> > Given that you need to modify *some* software in any case, it seems
> > like one ought to adopt session-hash.
>
> The problem is if you want to resolve this at the application level and
> don't have sufficient control over the TLS layer to influence it to
> negotiate session-hash.  This is the situation for many SASL
> applications.
>
> If universal adoption of session-hash is a prio, then there is no
> problem.  While RFC 7627 updates 5246 it does not talk a lot about what
> it actually updates in 5246, or I missed it, and I haven't seen
> session-hash functionality back-ported to deployed code.
>

I'm not sure what you mean by "backported", but I believe that BoringSSL
presently has session-hash, SChannel has it soon or does already, and
the next version of NSS (3.21) will have it.


My current approach works with or without session-hash negotiated, but
> requires that you can get the session_hash value out of the TLS stack.
>

I am not aware of a stack which has this function. Are you?

-Ekr

Another approach is to say that if session-hash is in use, it uses a
> simple TLS exporter API call, and if it is not, it has to use TLS
> exporter API on the session_hash value.  This would secure all cases.
>
> > >   But then what is the problem with use of 'tls-unique'?
> >
> > The general consensus is that 96 bits is too short.
>
> I agree -- I used 256 bits.
>
> /Simon
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] tls-unique

[Simon Josefsson]

Eric Rescorla  writes:

> On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson  wrote:
>
>> > > The introduction says:
>> > >
>> > >There exists a TLS extension [I-D.ietf-tls-session-hash] that
>> > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the
>> > > intended properties.  If widely implemented and deployed, the
>> > > channel binding type in this document would not offer any
>> > > additional protection.  The purpose of this document is to provide
>> > > an alternative channel binding that offers the intended properties
>> > > without requiring TLS protocol changes.  However, keep in mind that
>> > > TLS implementations needs to offer the appropriate APIs necessary
>> > > to be able to implement the channel binding described in this
>> > > document.
>> > >
>> > > I agree that one alternative is to require session_hash for all
>> > > connections.
>> >
>> >
>> > Given that you need to modify *some* software in any case, it seems
>> > like one ought to adopt session-hash.
>>
>> The problem is if you want to resolve this at the application level and
>> don't have sufficient control over the TLS layer to influence it to
>> negotiate session-hash.  This is the situation for many SASL
>> applications.
>>
>> If universal adoption of session-hash is a prio, then there is no
>> problem.  While RFC 7627 updates 5246 it does not talk a lot about what
>> it actually updates in 5246, or I missed it, and I haven't seen
>> session-hash functionality back-ported to deployed code.
>>
>
> I'm not sure what you mean by "backported", but I believe that BoringSSL
> presently has session-hash, SChannel has it soon or does already, and
> the next version of NSS (3.21) will have it.

If session-hash isn't backported to deployed code, like some other
security fixes has been backported (e.g., secure renegotiation), it will
take years until it is deployed.  Using only an TLS exporter interface
will therefor be insecure meanwhile, as far as I understand, since it
doesn't bind the entire handshake messages.

However, you could have a new TLS channel binding based on the TLS
exporter interface that demands use of session-hash, as you suggest.

>> My current approach works with or without session-hash negotiated, but
>> requires that you can get the session_hash value out of the TLS stack.
>
> I am not aware of a stack which has this function. Are you?

No.  Either the application inspects the handshake or code has to be
added.

/Simon


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] tls-unique

[Ilari Liusvaara]

On Thu, Oct 08, 2015 at 12:04:51PM +0200, Eric Rescorla wrote:
> 
> Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF.
> 
> With that said, I don't really understand the structure of your draft:
> Instead of referencing the PRF and session_hash directly, why not instead
> use RFC 5705 exporters and require the use of the session_hash extension?
> Then TLS 1.3 can just define exporters for 1.3 and we'll be done.

TLS 1.3 is different since TLS 1.3 always behaves like session_hash was
negotiated, whereas session_hash was a security fix for earlier versions.


One idea for TLS-unique for TLS 1.3: Invoke TLS-EXPORTER with:

label: "TLS 1.3 tls-unqiue"
context: No context
Length: 256

And define TLS-EXPORTER for TLS 1.3 as (this looks ugly, have some
better way at handling both context and no context cases? In original
RFC, those were different):

tmp = HKDF-Extract(label, exporter_secret)
output = HKDF-Expand(tmp, 0x01 | context, L)

or (no context case)

tmp = HKDF-Extract(label, exporter_secret)
output = HKDF-Expand(tmp, , L)


This is slightly different from other uses of HKDF. I don't mix in
session hash since exporter_secret is already Secret Nonce.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] TRON workshop

[Stephen Farrell]

Hiya,

First, thanks all for all your ongoing work on TLS1.3. I'm sure we're
all aware that this is important stuff that needs to be, and is being,
done carefully with due attention to security analysis.

Early in the process we had some brief discussion of pausing towards
the end of the work to give folks a chance to do analyses of the
security and other properties of TLS1.3 just before publication of
the RFC.

Chatting with the chairs in Prague and with various others since, we
think we've reached the point where we need to start executing that bit
of the plan, since doing such analyses also takes time and we don't
want to add a big delay if we can avoid it. So we're organising a
workshop on just that topic to be co-located with NDSS in San Diego
in late February 2016.

The call for papers is at [1], please read that and circulate to folks
who you think could produce useful analyses that can help the WG get
an even higher quality TLS1.3 out the door.

I'm sure some of you will be wondering about invites to this workshop
etc. We'll have to see how many submissions we get and the level of
interest and figure out logistics etc closer to time, but this clearly
does need a bunch of folks in the room who are important contributors
to the WG but who won't be submitting papers. I'll work with the
workshop programme committee and the WG chairs to figure out how best
to handle that, via invites, remote access if possible etc. More on
that as we figure it out. (Feel free to send me and/or the WG chairs
your thoughts and offers for help on that.)

And just to clarify a possible process question - this workshop will
provide input - we're hoping that'll be very high quality input but
the normal WG consensus process will be used to process that input in
all the usual ways. Think of TRON as being a mega-big design team on
steroids if that helps. (Lousy imagery, I know:-) If the workshop
indicates that TLS1.3 is fine then that's fairly obviously great, if
there are significant new issues identified though, those will need
to be brought to this list, and to meetings at IETF95, for resolution
via our normal process.

Cheers,
S.

[1]
https://www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-call-papers

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Martin Rex]

Eric Rescorla wrote:
> Short, Todd  wrote:
>> 
>> However, for those ClientHello?s that support older versions, the
>> compression_method field may contain other values. This means that if a
>> TLSv1.3 client happened to support compression for TLSv1.2, it would be
>> unable to negotiate that via a single ClientHello. There?s no way to
>> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a
>> single ClientHello.

Yup, that is the problem with the current text.


>
>> In effect, the document is stating that a TLSv1.3 client MUST NOT support
>> compression, regardless of the protocol version that may be negotiated.
> 
> Yes, this is what I believe it says and what I believe the WG had consensus
> on, the reasoning being that we really wished to just remove the feature
> entirely. If the chairs declare consensus on something else, I will of
> course edit it to say something else.

The current text is trying to force a specific policy in a fashion
that is in the worst conceivable violation of rfc2119 section 6 that
is possible.

A ClientHello with

ClientHello.client_version = (3,3)
ClientHello.compression_methods = (1,0)

will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers.


ClientHello.client_version = (3,4)
ClientHello.compression_methods = (1,0)

will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers,
but TLSv1.3 servers that follow the stupid idea will choke and
abort with an "illegal_parameter" alert.

Essentially, the current wording is calling for a newly creating what
must be called a "compression method intolerance" -- but essentially
it is indistinguishable from a "TLS version intolerance"


For a number of years, it seemed to have been consensus in the IETF TLS WG
that TLS version intolerance is an implemenattion defect and a real problem.  
It would be sad if the current TLS WG would confirm that recklessly adding
handshake failure causing new intolerances into TLSv1.3 is the new
engeneering approach.



-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Short, Todd]

Eric specifically clarified it:

On Oct 7, 2015, at 5:15 PM, Eric Rescorla mailto:e...@rtfm.com>> 
wrote:

Sorry, I spoke carelessly. It must contain solely the null method.

-Ekr

So the text needs to be corrected to reflect that. This will avoid the backward 
compatibility issues.

IMHO, the text should also clearly state something along the lines that “A 
TLSv1.3 client MUST NOT support compression, regardless of the protocol version 
that may be negotiated.” This reinforces backwards-compatibility via the use of 
CipherMethod.null, makes it blatantly obvious that compression is not 
supported, and a TLSv1.3 client is a good citizen in avoiding CRIME-type 
attacks.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Oct 8, 2015, at 5:22 PM, Martin Rex mailto:m...@sap.com>> 
wrote:

Eric Rescorla wrote:
Short, Todd mailto:tsh...@akamai.com>> wrote:

However, for those ClientHello?s that support older versions, the
compression_method field may contain other values. This means that if a
TLSv1.3 client happened to support compression for TLSv1.2, it would be
unable to negotiate that via a single ClientHello. There?s no way to
attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a
single ClientHello.

Yup, that is the problem with the current text.



In effect, the document is stating that a TLSv1.3 client MUST NOT support
compression, regardless of the protocol version that may be negotiated.

Yes, this is what I believe it says and what I believe the WG had consensus
on, the reasoning being that we really wished to just remove the feature
entirely. If the chairs declare consensus on something else, I will of
course edit it to say something else.

The current text is trying to force a specific policy in a fashion
that is in the worst conceivable violation of rfc2119 section 6 that
is possible.

A ClientHello with

   ClientHello.client_version = (3,3)
   ClientHello.compression_methods = (1,0)

will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers.


   ClientHello.client_version = (3,4)
   ClientHello.compression_methods = (1,0)

will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers,
but TLSv1.3 servers that follow the stupid idea will choke and
abort with an "illegal_parameter" alert.

Essentially, the current wording is calling for a newly creating what
must be called a "compression method intolerance" -- but essentially
it is indistinguishable from a "TLS version intolerance"


For a number of years, it seemed to have been consensus in the IETF TLS WG
that TLS version intolerance is an implemenattion defect and a real problem.
It would be sad if the current TLS WG would confirm that recklessly adding
handshake failure causing new intolerances into TLSv1.3 is the new
engeneering approach.



-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Eric Rescorla]

On Thu, Oct 8, 2015 at 11:22 PM, Martin Rex  wrote:

> Eric Rescorla wrote:
> > Short, Todd  wrote:
> >>
> >> However, for those ClientHello?s that support older versions, the
> >> compression_method field may contain other values. This means that if a
> >> TLSv1.3 client happened to support compression for TLSv1.2, it would be
> >> unable to negotiate that via a single ClientHello. There?s no way to
> >> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a
> >> single ClientHello.
>
> Yup, that is the problem with the current text.


Thanks for clarifying this.


>
>
> >
> >> In effect, the document is stating that a TLSv1.3 client MUST NOT
> support
> >> compression, regardless of the protocol version that may be negotiated.
> >
> > Yes, this is what I believe it says and what I believe the WG had
> consensus
> > on, the reasoning being that we really wished to just remove the feature
> > entirely. If the chairs declare consensus on something else, I will of
> > course edit it to say something else.
>
> The current text is trying to force a specific policy in a fashion
> that is in the worst conceivable violation of rfc2119 section 6 that
> is possible.
>
> A ClientHello with
>
> ClientHello.client_version = (3,3)
> ClientHello.compression_methods = (1,0)
>
> will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers.
>
>
> ClientHello.client_version = (3,4)
> ClientHello.compression_methods = (1,0)
>
> will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers,
> but TLSv1.3 servers that follow the stupid idea will choke and
> abort with an "illegal_parameter" alert.
>
> Essentially, the current wording is calling for a newly creating what
> must be called a "compression method intolerance" -- but essentially
> it is indistinguishable from a "TLS version intolerance"


Hmm... I'm not sure I follow this argument. We have a bunch of rules for
how TLS 1.3 clients MUST behave and TLS 1.3 servers will choke if
they don't. This doesn't create any present interop problem and only
creates a problem if in future we wish to reintroduce compression.
Is that your concern?



> For a number of years, it seemed to have been consensus in the IETF TLS WG
> that TLS version intolerance is an implemenattion defect and a real
> problem.
> It would be sad if the current TLS WG would confirm that recklessly adding
> handshake failure causing new intolerances into TLSv1.3 is the new
> engeneering approach.


As I said, I edited the document in conformance with what I believed the
chair declaration of WG consensus was. If the WG consensus is to remove
this requirement, then I will of course do so. So, rather than going back
and
forth, I would suggest that the best way for you to proceed here is to:

1. Ask the chairs to re-state the previous consensus. If I misunderstood,
then that's
easy.
2. If you're still not happy, then you could ask the chairs to re-assess
the currnet
consensus.
3. If you're still not happy, and you believe this violates 2119, then you
can of
course appeal.

This of course also goes for people who think we should re-allow
compression.

Best,
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls