Re: [TLS] Thoughts on Version Intolerance

[Dave Garrett]

On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote:
> On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote:
> > Any ClientHello with > 200 Cipher suite code points indicates fairly insane
> > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.
> 
> and which part of the standard says that it is "_perfectly_sane_" server 
> behaviour?

On this specific type of issue, I agree with Martin here that sanity checks for 
over-the-top configurations are reasonable, however we should be standardizing 
this, not having every implementation do this ad hoc. We really should go 
through a list of these sort of implementation break points and start picking 
arbitrary lines to add to the spec. They don't have to be ideal numbers; just 
something better than an upper limit of 2^15-2 suites (2 bytes each; 2^16-2 max 
sized vector) would be nice, for this example. Yes, certain fields have to stay 
open-ended, namely extensions, but reasonable limits should be added where 
appropriate.


Dave

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

Re: [TLS] HTTP, Certificates, and TLS

[Ilari Liusvaara]

On Thu, Jul 21, 2016 at 07:08:04PM +0200, Martin Rex wrote:
> Martin Thomson wrote:
> > On 21 July 2016 at 18:41, Martin Rex  wrote:
> >>A server that implements this extension MUST NOT accept the request
> >>to resume the session if the server_name extension contains a
> >>different name.  Instead, it proceeds with a full handshake to
> >>establish a new session.
> > 
> > If that's the only barrier to doing this, I'd be surprised.  The
> > prospect of having to overcome this is not at all daunting.
> 
> No, that is only the tip of an iceberg, and you're going Titanic here.
> 
> Really, this is about TLS session cache management (which is something
> very close to TLS) vs. Endpoint identification, i.e. interpreting
> end-entity certificates -- which is something that is explicitly
> outside of the scope of TLS (e.g. rfc2818 and rfc6125).
> 
> 
> Could you please describe the approach to session cache management that
> you're conceiving here? 

Well, I guess it would be reasonable to remember the server identites
on client side, but clear client identities on server side.

Especially the client identies are highly important: If the server
thinks any identity is valid that client thinks is invalid, that will
lead to attacks.

> In the original TLS architecture (up to TLSv1.2)
> TLS sessions are read-only after creation, and identities (certificates)
> are locked down.  Forgetting to cryptographically bind the communication
> identities into the session properties allowed the triple-handshake-attack.

No, THS was caused by failing to bind the exchange keys (I consider the
abstract of EMS RFC to be quite misleading).

> If you want to change any session properties (including certificates),
> you MUST perform a new full handshake, which creates a new session with
> new properties and a new session ID / session cache entry.

And thanks to all sorts of crypto restrictions, exchange keys have
nothing to do with certificates of any kind (all modes where they
have anything to do are banned), and that the exchange keys are properly
bound.

> Session resumption (and session resumption proposal) should operate
> based on requested properties (is there an existing session with the
> requested properties?) and this is conceptually independent from the
> app-level endpoint identification (such as rfc2818/rfc6125).
> 
> The wording in rfc6066 is not optimal.  It should have better said:
> whenever a full handshake would result in selection of a different
> server certificate, then the server MUST perform a full handshake,
> in order to produce predictable/deterministic behaviour that is
> not side-effected by session cache management / session cache lifetime
> effects.  The principle of least surprise.

Within context of HTTP, the server authentication is about what
authorities the server is allowed to assert. And in responses, the
server always needs to pick the authority it asserts.

As long as one takes care that no authorities get lost, or that lost
authorities can be recovered if needed (and authroized), then the
behaviour will remain deterministic (modulo possibly few extra RTTs
to recover the lost authroties).


Now, client authentication is entierely different beast. The client
won't inherently assert its authority in HTTP, so the server view
of client authority damn better be subset of what client intended,
or you WILL get privilege escalation attacks.

>From that it follows that the client needs per-request control of
authorities it holds (if to assert them or to disclaim them).



-Ilari

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

Re: [TLS] HTTP, Certificates, and TLS

[Mike Bishop]

That argument seems like it would apply to all post-handshake authentication, 
unless there's something different about that.

-Original Message-
From: Martin Rex [mailto:m...@sap.com] 
Sent: Thursday, July 21, 2016 7:08 PM
To: Martin Thomson 
Cc: m...@sap.com; Mike Bishop ; tls@ietf.org
Subject: Re: [TLS] HTTP, Certificates, and TLS

Martin Thomson wrote:
> On 21 July 2016 at 18:41, Martin Rex  wrote:
>>A server that implements this extension MUST NOT accept the request
>>to resume the session if the server_name extension contains a
>>different name.  Instead, it proceeds with a full handshake to
>>establish a new session.
> 
> If that's the only barrier to doing this, I'd be surprised.  The 
> prospect of having to overcome this is not at all daunting.

No, that is only the tip of an iceberg, and you're going Titanic here.

Really, this is about TLS session cache management (which is something very 
close to TLS) vs. Endpoint identification, i.e. interpreting end-entity 
certificates -- which is something that is explicitly outside of the scope of 
TLS (e.g. rfc2818 and rfc6125).


Could you please describe the approach to session cache management that you're 
conceiving here?  In the original TLS architecture (up to TLSv1.2) TLS sessions 
are read-only after creation, and identities (certificates) are locked down.  
Forgetting to cryptographically bind the communication identities into the 
session properties allowed the triple-handshake-attack.


If you want to change any session properties (including certificates), you MUST 
perform a new full handshake, which creates a new session with new properties 
and a new session ID / session cache entry.

Session resumption (and session resumption proposal) should operate based on 
requested properties (is there an existing session with the requested 
properties?) and this is conceptually independent from the app-level endpoint 
identification (such as rfc2818/rfc6125).


The wording in rfc6066 is not optimal.  It should have better said:
whenever a full handshake would result in selection of a different server 
certificate, then the server MUST perform a full handshake, in order to produce 
predictable/deterministic behaviour that is not side-effected by session cache 
management / session cache lifetime effects.  The principle of least surprise.


-Martin

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

Re: [TLS] HTTP, Certificates, and TLS

[Martin Rex]

Martin Thomson wrote:
> On 21 July 2016 at 18:41, Martin Rex  wrote:
>>A server that implements this extension MUST NOT accept the request
>>to resume the session if the server_name extension contains a
>>different name.  Instead, it proceeds with a full handshake to
>>establish a new session.
> 
> If that's the only barrier to doing this, I'd be surprised.  The
> prospect of having to overcome this is not at all daunting.

No, that is only the tip of an iceberg, and you're going Titanic here.

Really, this is about TLS session cache management (which is something
very close to TLS) vs. Endpoint identification, i.e. interpreting
end-entity certificates -- which is something that is explicitly
outside of the scope of TLS (e.g. rfc2818 and rfc6125).


Could you please describe the approach to session cache management that
you're conceiving here?  In the original TLS architecture (up to TLSv1.2)
TLS sessions are read-only after creation, and identities (certificates)
are locked down.  Forgetting to cryptographically bind the communication
identities into the session properties allowed the triple-handshake-attack.


If you want to change any session properties (including certificates),
you MUST perform a new full handshake, which creates a new session with
new properties and a new session ID / session cache entry.

Session resumption (and session resumption proposal) should operate
based on requested properties (is there an existing session with the
requested properties?) and this is conceptually independent from the
app-level endpoint identification (such as rfc2818/rfc6125).


The wording in rfc6066 is not optimal.  It should have better said:
whenever a full handshake would result in selection of a different
server certificate, then the server MUST perform a full handshake,
in order to produce predictable/deterministic behaviour that is
not side-effected by session cache management / session cache lifetime
effects.  The principle of least surprise.


-Martin

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

Re: [TLS] HTTP, Certificates, and TLS

[Mike Bishop]

Ah, I was seeing the lower-case version in Appendix A from a quick search.  
Yes, that one is upper-case.

Still, that seems simple enough to handle in whatever discussion of how 
resumption affects this.  If they remain in effect across a resumption, any 
name in that set could reasonably be valid; if not, then only the name on the 
certificate is originally valid.

>From an HTTP layer, we see this as analogous to a certificate with multiple 
>SANs present -- if the original connection asked for one name on the cert, but 
>a resumption asked for a different SAN, is resumption permitted?  This seems 
>to suggest that it's not, and to strictly obey that requires that the server 
>remember which of several hostnames tied to that certificate was actually used 
>to establish the connection.

-Original Message-
From: Martin Rex [mailto:m...@sap.com] 
Sent: Thursday, July 21, 2016 6:42 PM
To: Mike Bishop 
Cc: m...@sap.com; tls@ietf.org
Subject: Re: [TLS] HTTP, Certificates, and TLS

Mike Bishop wrote:
>
> I assume you're referring to Section 3, SNI's ServerNameList MUST NOT 
> contain more than one name of a given type?
>
> Or are you referring to the (lower-case) must not resume if SNI and 
> the certificate used in the resumed session differ?

My (online) copy of rfc6066 has a (fully reasonable) upper-case MUST NOT.


Last paragraph on page 7, rfc6066 (TLS extension server_name_indication)

https://tools.ietf.org/html/rfc6066#page-7

   A server that implements this extension MUST NOT accept the request
   to resume the session if the server_name extension contains a
   different name.  Instead, it proceeds with a full handshake to
   establish a new session.


-Martin

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

Re: [TLS] HTTP, Certificates, and TLS

[Mike Bishop]

I assume you're referring to Section 3, SNI's ServerNameList MUST NOT contain 
more than one name of a given type?  Technically, we're not violating that, 
since we're not changing SNI.  The client requests a single identity in the TLS 
handshake, which the server provides.  Additional identities can be 
demonstrated later, regardless of where.



Or are you referring to the (lower-case) must not resume if SNI and the 
certificate used in the resumed session differ?  For HTTP, we're leaving 
resumption out of the picture, requiring that any secondary certificates be 
proved anew for each connection.  You're certainly correct that if the logic 
were moved to TLS, the semantics of resumption would have to be defined.  That 
may be a solid argument on why it should remain at the application layer.



-Original Message-
From: Martin Rex [mailto:m...@sap.com]
Sent: Thursday, July 21, 2016 5:57 PM
To: Mike Bishop 
Cc: tls@ietf.org
Subject: Re: [TLS] HTTP, Certificates, and TLS



Mike Bishop wrote:

>

> That means we now have a proposal for carrying both client and server

> certificates above TLS, found at

> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.

>

> We have also discussed that it might be preferable to pull part of

> this capability back into TLS,



You are facing a MUST NOT in rfc6066 for this particularly bad idea.



I'm currently wondering what kind of (weird) TLS session caching strategy would 
actually allow you to create such client or server behaviour.

You're definitely in severe conflict with the "principle of least surprise"

in respect to deterministic behaviour of your TLS clients and TLS servers.



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

Re: [TLS] HTTP, Certificates, and TLS

[Martin Rex]

Mike Bishop wrote:
> 
> That means we now have a proposal for carrying both client and server
> certificates above TLS, found at
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.
> 
> We have also discussed that it might be preferable to pull part of this
> capability back into TLS,

You are facing a MUST NOT in rfc6066 for this particularly bad idea.

I'm currently wondering what kind of (weird) TLS session caching strategy
would actually allow you to create such client or server behaviour.
You're definitely in severe conflict with the "principle of least surprise"
in respect to deterministic behaviour of your TLS clients and TLS servers.

-Martin

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

Re: [TLS] Thoughts on Version Intolerance

[Hubert Kario]

On Thursday, 21 July 2016 12:25:48 CEST Peter Gutmann wrote:
> Martin Rex  writes:
> >Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour.
> >X.509v3 certificates can theoretically include CAT MPEGs and amount to
> >megabytes.
> 
> We really need a TLS scanner that does this just to see what happens.  When
> I created that cat-MPEG cert, I fed it to both MSIE and Netscape.  Both
> happily accepted it, and then essentially become nonfunctional because
> although they saw nothing wrong with accepting a cert of that size, they
> couldn't actually deal with it.  In Netscape's case I had to delete the .db
> file before it could be used again.  I wouldn't be surprised if you can
> quite effectively DoS assorted TLS implementations with stuff like this.

if you have such certificate, you can use this script from tlsfuzzer to test 
if server won't explode by processing it:
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-rsa-sigs-on-certificate-verify.py

(I haven't tested if it actually can send a 2MiB large certificate, but in 
general there are no limits in tlslite-ng or tlsfuzzer, so it should work just 
fine, bugreports welcome if that is not the case).

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Thoughts on Version Intolerance

[Peter Gutmann]

Martin Rex  writes:

>Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour.
>X.509v3 certificates can theoretically include CAT MPEGs and amount to
>megabytes.

We really need a TLS scanner that does this just to see what happens.  When I
created that cat-MPEG cert, I fed it to both MSIE and Netscape.  Both happily
accepted it, and then essentially become nonfunctional because although they
saw nothing wrong with accepting a cert of that size, they couldn't actually
deal with it.  In Netscape's case I had to delete the .db file before it could
be used again.  I wouldn't be surprised if you can quite effectively DoS
assorted TLS implementations with stuff like this.

(This is one of the design features of TLS-LTS, if both sides do -LTS then the
Hello only needs a single extension to specify everything.  Combine that with
PSK, so no certs, and you get quite an efficient protocol, the only thing of
any size is the keyex and server signature).

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

Re: [TLS] Thoughts on Version Intolerance

[Ilari Liusvaara]

On Thu, Jul 21, 2016 at 10:19:34AM +, David Benjamin wrote:
> On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk  wrote:
> 
> > On 07/20/2016 05:01 AM, Hanno Böck wrote:
> > > On Wed, 20 Jul 2016 11:20:46 +0200
> > > Hubert Kario  wrote:
> > >

> And as Hubert notes, there may well be other intolerance triggers to clear
> through. 1.3 has a larger ClientHello. We have also never added a new
> signature algorithm before. But I think that just means we have more rusted
> protocol joints fix rather than just the one.

Could be useful to scan for SignatureScheme. I think the most worthwhile 6
to scan would be:

0x0003 (ECDSA-NONE in TLS 1.2)
0x0004 (UNKNOWN4-NONE in TLS 1.2)
0x0404 (UNKNOWN4-SHA256 in TLS 1.2)
0x0700 (ANON-UNKNOWN7 in TLS 1.2)
0x0703 (ECDSA-UNKNOWN7 in TLS 1.2)
0x0704 (UNKNOWN4-UNKNOWN7 in TLS 1.2)

And then see how many servers do anything retarded with these...


-Ilari

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

Re: [TLS] Thoughts on Version Intolerance

[Hubert Kario]

On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote:
> Hubert Kario wrote:
> > Martin Rex wrote:
> >> Forget TLS extensions, forget ClientHello.client_version.
> >> Both in fundamentally broken, and led to Web Browsers coming up
> >> with the "downgrade dance" that is target of the POODLE attack.
> >> 
> >> We know fairly reliably what kind of negotiation works just fine:
> >> TLS cipher suite codepoints.
> > 
> > please re-read my mail, they don't:
> > 
> > 49% (6240) are intolerant to a Client Hello with no extensions but
> > big number of ciphers that bring its size to 16388 bytes)
> > 91.5% (11539) are intolerant to a Client Hello with no extensions
> > but a number of ciphers that bring it well above single record layer limit
> > (16.5KiB)
> 
> You're seriously confusing things here.
> 
> Any ClientHello with > 200 Cipher suite code points indicates fairly insane
> Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.

and which part of the standard says that it is "_perfectly_sane_" server 
behaviour?
 
> Trying to support theoretical encoding size limits is a stupid idea,
> because it leads to endless security problems.  Imposing sane sizes
> plus a safety margin is solid implementation advice.

unlike the endless incompatibility problems?

> Large stuff that doesn't need to be exchanged in abbreviated handshakes
> should *NEVER* be included in ClientHello, because of the performance
> penalties this creates (Network bandwidth for TLS handshake,
> and TCP slow start).

I suggest you take a look at the key_share extension and what are the size 
requirements for PQcrypto key exchanges

> >>> I'm now also collecting some data and have some preliminary
> >>> suspicion on affected devices. My numbers roughly match yours that we
> >>> are in the more or less 3% area of 1.3 intolerance.
> >> 
> >> The TLSv1.2 version intolerance is already a huge problem,
> >> and I'm not seeing it go away.  Acutally Microsoft created an
> >> awfully large installed base of TLSv1.2-intolerant servers
> >> (the entire installed base of Win7 through Win8.1 aka 2008R2, 2012,
> >> 2012R2).
> Please recheck with a vanilla (aka extension-free) ClientHello that
> has ClientHello.client_version = (3,3), to recognize all TLSv1.2-intolerant
> implementations in your counts.

and what about those servers that will abort connection if the RC4 ciphes are 
below the 64'th position in the list?

> >> I would really like to see the TLS WG improving the situation
> >> rather than keep sitting on its hands.  The problem has been well-known
> >> since 2005.  And the "downgrade dance" was a predictably lame approach
> >> to deal with the situation, because it completely subverts/evades the
> >> cryptographic protection of the TLS handshake.
> > 
> > it's not IETF's fault that the implementers add unspecified by IETF
> > restrictions and limitations to parsers of Client Hello messages or that
> > they can't handle handshake messages split over multiple record layer
> > messages, despite the standard being very explicit in that they MUST
> > support this.
> 
> Nope, not really.  Limiting PDU sizes to reasonably sane sizes is
> perfectly valid behaviour.  X.509v3 certificates can theoretically include
> CAT MPEGs and amount to megabytes.  A TLS implementation that limits
> the certificate chain (i.e. the TLS Certificate Handshake message) to
> a reasonably sane size with safety margin, say 32 KBytes in total,
> is acting totally reasonable.  Anyone who creates an insane PKI deserves
> to loose, and deserves to loose quite badly.

if it's valid, please point me to the part of RFC that says that.

and we're not talking about Certificate message here, we're talking about 
Client Hello. The absolute upper size limit for it is 131396 bytes. Any 
implementation that can't process messages that big is simply RFC non 
compliant.

Besides, so what that you can send megabyte sized certificates thought TLS?
even if you do consider it a DoS, pausing the ECDHE key exchange with
a large curve just before Client Key Exchange message is a far more effective 
use of attacker's resources.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Thoughts on Version Intolerance

[David Benjamin]

On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk  wrote:

> On 07/20/2016 05:01 AM, Hanno Böck wrote:
> > On Wed, 20 Jul 2016 11:20:46 +0200
> > Hubert Kario  wrote:
> >
> >> so it looks to me like while we may gain a bit of compatibility by
> >> using extension based mechanism to indicate TLSv1.3,
> > Just quick: This was discussed yesterday, David Benjamin had an
> > interesting proposal, but it was largely met with resistance. So from
>
> I had some follow-up discussion with David and a few others later in the
> day.  One point that I think was not clear during the WG session was
> whether the check for whether a server's version negotiation is
> futureproof could be done in the hot path, so that it is impossible to
> implement a server that works in a major browser and is (e.g., 1.4)
> version-intolerant.
>
> Right now, if a browser wants to probe for (e.g., 1.3) version
> intolerance, it essentially has to treat it as a data-collection step,
> either doing the fallback dance on failure or just doing the probe in
> parallel with a 1.2 clienthello that is actually used for the
> connection, since we know that 1.3-intolerance exists.  With David's
> proposal (and potentially variants of the other ones), browsers could
> implement a check that sends nonexistent versions in their clienthello,
> so that once a server implements 1.3, it would not be 1.4-intolerant.
>
> If we just keep with the current version negotiation scheme, we'll
> always be stuck in the "data-collecting" mode and won't be able to
> strictly enforce the future-proofing, since there are existing servers
> that are intolerant to the current scheme, and the browsers will be
> blamed for breaking sites on those servers if the browsers try to
> introduce strict enforcement of version negotiation future-proofing.
>

[Credit where credit is due, I was not the first to propose the version
list. I don't know who was first, but Dave Garrett had proposed the same
thing. The TLS 1.3 implementors effectively did so too with the draft
version extension. Though I think the fake versions idea is new?]

I should also add that, even if we ever got to our prerequisite quiet
point, this scheme is still problematic. If we had a list, all clients
could participate in this fuzzing and we have a shot at vaccinating the
ecosystem. This one violates the specification, so only clients which can
rapidly deploy changes can safely do it. (Some sort of field trial
mechanism, for instance.) And it requires manual work to sustain: I would
probably only do it for, say, 3 months at a time and manually extend so
long as TLS 1.4 does not exist. I would not want to cause problems by
forgetting to turn it off.

And as Hubert notes, there may well be other intolerance triggers to clear
through. 1.3 has a larger ClientHello. We have also never added a new
signature algorithm before. But I think that just means we have more rusted
protocol joints fix rather than just the one.

Fortunately, most of our other joints admit this kind of fuzzing. It's just
the versioning scheme (fixable with a list), and large ClientHellos. I
don't have a good answer to the second one, but I would be very happy if it
were our only problem. It's much easier to understand. The version one is
surprisingly difficult. The conversations usually go like this:

"Hi, your server software appears to have a bug where you reject TLS 1.2
ClientHellos rather than implementing the version negotiation right."
"Okay, we will deploy TLS 1.2."
"No, please don't fix this with 1.2. That's a different problem."
"You don't want us to add 1.2?"
"No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just
email you later for 1.3."

I am obviously exaggerating for humor, but it's a very common confusion and
I think is part of why version intolerance keeps on existing.

If you implement the latest version of TLS but are intolerant to N+1, even
if no clients did fallbacks, your bug will not be noticed and you'll thrive
in the ecosystem. Then when we go to deploy N+1, we have problems. We want,
as much as possible, turn tomorrow's interop failures into today's interop
failures so the bugs are caught before software ships.

David


> -Ben
>
> > the WG discussion yesterday I had the impression that we will most
> > likely stay with the existing clienthello version mechanism. While that
> > will cause us more trouble, it's probably the cleaner option anyway. So
> > we definitely should continue investigating version intolerance and
> > tell people to fix their stuff.
> >
>
> ___
> 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

[TLS] HTTP, Certificates, and TLS

[Mike Bishop]

Hi, folks -

Martin and I had come previously to the TLS WG to discuss our work with 
handling client certificates at the HTTP layer.  Based on that discussion, we 
revised our model to cover signatures of an exporter value and carry the proof 
in an HTTP/2 frame.  During BA, the HTTP WG expressed interest in flipping the 
model in the opposite direction - carrying additional server identities as 
well.  That means we now have a proposal for carrying both client and server 
certificates above TLS, found at 
https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.

We have also discussed that it might be preferable to pull part of this 
capability back into TLS, expanding post-handshake authentication to allow 
providing multiple certificates in either direction.  Since that would 
necessarily require additional work on that part of the TLS 1.3 spec, we 
discussed the possibility of splitting post-handshake authentication into a 
separate spec so that the core TLS 1.3 spec could proceed to WGLC as scheduled 
and take a little longer on the second draft.

Having spoken to some other TLS WG members, some people would prefer to move 
post-handshake authentication entirely to our layer.  While that's probably not 
feasible (HTTP/1.1 still needs post-handshake auth from TLS, regardless of what 
HTTP/2 does), we can retain our application-layer authentication.  This has the 
advantage of leaving TLS 1.3 unchanged, but keeps a security draft in a 
non-security working group.  We are concerned that, by doing this at the HTTP 
layer, we'll be missing necessary security expert review as this moves forward. 
 (EKR already suggested some necessary improvements to our signature model to 
prevent some pretty trivial attacks; these aren't reflected in the current 
draft.)  If that's the route we go, I would greatly appreciate some TLS folks 
visiting the HTTP WG and helping us review this draft.

I was on the "time permitting" list to present in the TLS meeting on Tuesday, 
and we didn't get a chance to.  We'll be discussing the actual draft tomorrow 
morning in HTTP; I'd be happy to have some TLS folks there to discuss the 
draft, and I'd like to get a sense from the TLS WG whether there's a preference 
for us to do this at the application layer or pass additional requirements to 
post-handshake auth.

Thanks!
-Mike Bishop
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC 7924 on Transport Layer Security (TLS) Cached Information Extension

[Sean Turner]

Congrats to all involved!

spt

> On Jul 19, 2016, at 10:01, rfc-edi...@rfc-editor.org wrote:
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>RFC 7924
> 
>Title:  Transport Layer Security (TLS) Cached 
>Information Extension 
>Author: S. Santesson, H. Tschofenig
>Status: Standards Track
>Stream: IETF
>Date:   July 2016
>Mailbox:s...@aaa-sec.com, 
>hannes.tschofe...@gmx.net
>Pages:  19
>Characters: 35144
>Updates/Obsoletes/SeeAlso:   None
> 
>I-D Tag:draft-ietf-tls-cached-info-23.txt
> 
>URL:https://www.rfc-editor.org/info/rfc7924
> 
>DOI:http://dx.doi.org/10.17487/RFC7924
> 
> Transport Layer Security (TLS) handshakes often include fairly static
> information, such as the server certificate and a list of trusted
> certification authorities (CAs).  This information can be of
> considerable size, particularly if the server certificate is bundled
> with a complete certificate chain (i.e., the certificates of
> intermediate CAs up to the root CA).
> 
> This document defines an extension that allows a TLS client to inform
> a server of cached information, thereby enabling the server to omit
> already available information.
> 
> This document is a product of the Transport Layer Security Working Group of 
> the IETF.
> 
> This is now a Proposed Standard.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
> standardization state and status of this protocol.  Distribution of this 
> memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> ___
> 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] Resumption Contexts and 0-RTT Finished

[Ilari Liusvaara]

On Wed, Jul 20, 2016 at 01:42:58AM -0400, Hugo Krawczyk wrote:
> Without taking a position on the implementation issues, I am in favor of
> Option A with a dedicated context value (and an explicit name "PSK
> Context") as this makes clear the function of this value. Relying in
> Finished makes it more fragile and open to be dropped in the future when
> its binding role is "forgotten" or when deriving some other protocol or
> variant.

Furthermore, I think that there are only two ways to do the kind of
binding required that aren't fatally flawed (as far as I know) in some
way.

One is ADL's "Option A", and the other is implicit variant of "Option B"
I came up with. Both are ugly.

I think ADL's "Option A" is easier to implement (no need to mess with
Finished generation).


I also think that the 0-RTT Finished message should be removed (as
suggested before by one of the "crypto guys", I forgot who). It
is major implementation problem, and doesn't seem to even provode any
security.


> Also, I insist on the need to remark about the need for collision
> resistance of any value with a binding functionality. If this value is
> produced with HKDF (or HMAC as in he case of Finished) the need for
> collision resistance is not explicit and can lead to truncation (which is
> perfectly fine when just deriving keys or when used with a regular PRF
> functionality).

The properties that HKDF and HMAC actually provodes here:

If the base hash is CR and has output length at most blocklength,
then...

- HMAC is CR w.r.t. its message input.
- If the HMAC key is of constant length, the HMAC is CR w.r.t. its
  key.
- HKDF-Extract is CR w.r.t. its key input.
- If the salt is of constant length, HKDF-Extract is CR w.r.t. its
  salt.
- If length is at least one hash output, HKDF-Expand-Label is CR
  w.r.t. its label.
- If length is at least one hash output, HKDF-Expand-Label is CR
  w.r.t. its hashvalue.
- If length is at least one hash output and secret is of constant
  length, HKDF-Expand-Label is CR w.r.t. its secret.

These all can be shown by supposing an counterexample, and showing
that it inevitably follows that the base hash is both CR and not CR
at the same time, which is not possible.

(Conviniently, all length constraints are currently always met).


> Actually, I would suggest that for any such value, we add "collision
> resistance" to the label for that derivation - this would apply to
> resumption/PSK context and to Exporter key (and possibly others)


I suggest appending ", collision resistant".


(E.g. "TLS 1.3, exporter master secret, collision resistant", after
fully expanding the label)


-Ilari

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