[TLS] Fwd: TLS Digest, Vol 134, Issue 12

[Sankalp Bagaria]

Hello,

Truncating 20-byte hash to one byte is NOT a good idea since this would result
in ONLY 255 (2^8 - 1) unique certificates to be identified. This will result in
many certificates sharing the same 1-byte hash ie, 2^160 certificates are mapped
to the 255 1-byte hash. This is NOT desirable and collision may occur.

It is true that the hash, in this case, is not used for cryptographic purpose
but to simply identify the right cached certificate at the server. But, same
hash-truncated-to-one-byte may be assigned to two or more certificates at the
server. Chances of all certificates being unique at the server side is
255*254*253**(255-n+1) where n is the total number of certificates at the
server side. That means, chances of two certificates at server - side having
same hash-truncated-to-one-byte is (1-
(255/255)*(254/255)*(253/255)*...*((255-n+1)/255)). It is a small quantity
(approx. 0.005) but not negligible.

The problem occurs if wrong certificate is chosen at the server side. This may
be avoided by:
1) Sending a full 20-byte hash or hash truncated to a larger number than just
one byte
2) Detecting whether two certificates have same 1-byte hash at the server side
and requesting a full Handshake in such cases.

Thanks and Regards,
Sankalp Bagaria.


-- Forwarded message --
From: mailto:tls-requ...@ietf.org> >
Date: Fri, Sep 11, 2015 at 12:30 AM
Subject: TLS Digest, Vol 134, Issue 12
To: tls@ietf.org 


Send TLS mailing list submissions to
tls@ietf.org 

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/tls

or, via email, send a message with subject or body 'help' to
tls-requ...@ietf.org 

You can reach the person managing the list at
tls-ow...@ietf.org 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TLS digest..."


Today's Topics:

   1. Re:  WGLC for draft-ietf-tls-cached-info-19 (Hannes Tschofenig)
   2. Re:  WGLC for draft-ietf-tls-cached-info-19 (Martin Thomson)


--

Message: 1
Date: Thu, 10 Sep 2015 13:14:52 +0200
From: Hannes Tschofenig < hannes.tschofe...@gmx.net
 >
To: Martin Thomson < martin.thom...@gmail.com 
>
Cc: " tls@ietf.org  " < tls@ietf.org 
>
Subject: Re: [TLS] WGLC for draft-ietf-tls-cached-info-19
Message-ID: < 55f1662c.5050...@gmx.net  >
Content-Type: text/plain; charset="utf-8"

Hi Martin,

thanks for your feedback. I have discussed the topic with my co-worker
Manuel.

Another way of seeing the use of the hash by the client is to help the
server to select the pick certificate (or other cached data). It does
not have a security purpose as such, it is only a way to prevent the
server accidentally including the wrong information. For example, this
can happen when the server has multiple certificates to choose from then
it should pick the right one (and I am not talking about the SNI case
here).

Without the possibility for picking the wrong value we could have as
well omitted the hash altogether. The actual function used to compete
the fingerprint isn't that important as long as it helps to make sure
that the correct value can be chosen with a reasonable probably. In the
worst case, the wrong value is chosen and the exchange failed. The
client will then have to re-start the exchange without the cached info
feature.

As such, you are certainly right that the hash does not need to be long
since the changes of selecting the wrong information is very low. In
case of the certificate the security actually comes from the private
key: the server needs to demonstrate that it knows the privacy key in
the exchange.

Regarding the use of the TLS PRF I am not sure that this will work since
the actual function is the result of the negotiated cipher and not known
at the time when the client and the server exchange their hello messages.

Ciao
Hannes

PS: Additing extra text with information about what is included in the
hash will be added to make sure that implementers compute the hash over
the correct fields of the message.


On 08/24/2015 08:35 PM, Martin Thomson wrote:
> Hi Hannes,
>
> On 24 August 2015 at 09:38, Hannes Tschofenig < hannes.tschofe...@gmx.net
>  > wrote:
>>> I'd like to see the document explicitly note that msg_type and length
>>> from the handshake message are not covered by the hash.  The
>>> description of what is covered is a little too terse (and badly
>>> formatted).
>>
>> There are multiple message type / message length fields included in the
>> message and I am not sure which of those you rare referring to.
>>
>> The msg_type and msg_length from the reco

Re: [TLS] WGLC for draft-ietf-tls-cached-info-19

[Sankalp Bagaria]

gt; >>
> >>>> If the current design is retained, I would
> >>>> like to see a little discussion of this in the document. A little
> >>>> analysis of the properties we expect the hash to provide would also be
> >>>> good.
> >>>>
> >>>> I think that truncated hashes might be advantageous from the server
> >>>> side. Given that the server only uses hashes to identify which of the
> >>>> offered (available, known?) cached information is in use, is there any
> >>>> reason you can't save additional space by arbitrarily truncating the
> >>>> hash? In many cases I would imagine that the client would be offering
> >>>> only one option and even if there were a small number of options
> >>>> presented, a single byte would suffice to disambiguate.
> >>>>
> >>>> I'm trying to think why you might want the full-length hash on the
> >>>> client side, but I believe that the only problem there is that there
> >>>> might be a collision between the certificates that a server might
> >>>> offer if you truncate too aggressively. The connection still relies
> >>>> on the server presenting proof of knowledge of a key that the client
> >>>> extracts from a certificate bound to the server identity, so I believe
> >>>> that it would be equally secure if you removed all mention of
> >>>> certificates from the protocol. And that makes me nervous, because
> >>>> I'm fairly sure that Karthik will tell me that I'm wrong very shortly;
> >>>> since we've put in a lot of work to cover key fields in the handshake
> >>>> hash, and I'm concerned that this could be exploited somehow.
> >>>>
> >>>> The more I think about this, the more I think that we need a little
> >>>> more analysis on this point (i.e., what properties the hash function
> >>>> needs to provide and why). If it has already happened, mention of
> >>>> that in the security considerations is needed.
> >>>>
> >>>> (I think that truncation on the server side is safe if the client uses
> >>>> a strong hash function to identify the certificate, but I'm frequently
> >>>> wrong about these things.)
> >>>>
> >>> There are three designs possible for referencing the cached state, namely
> >>>
> >>> 1) The client creates the reference.
> >>> 2) The server creates the reference.
> >>> 3) There is no reference at all.
> >>
> >> I'm not suggesting that you change the design, just provide a
> >> description of the properties that it provides - and those that it
> >> relies on.
> >>
> >> On the surface at least, it seems OK to rely on a weak guarantee of
> >> collision resistance from the hash. Failure only results in handshake
> >> failure, after which the client can fall back. That suggests that a
> >> truncated hash output could be used, potentially saving quite a few
> >> bytes in the client's first flight. I'd like to do that if it is
> >> possible.
> >>
> >> However, I'm concerned that eliding identity will lead to a weakness
> >> somewhere. For instance, if the client uses a shorter hash, then the
> >> server might pick up different certificates. Or, it means that
> >> identity is not bound to the session hash as directly. If, as you
> >> say, we can rely on this being a direct selector for a private key
> >> where the security is bound to that private key, then maybe it's OK.
> >>
> >
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
> <https://www.ietf.org/mailman/listinfo/tls>
>
>
> --
>
> End of TLS Digest, Vol 134, Issue 12
> 
> ---
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
> ---
>
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> <https://mailarchive.ietf.org/arch/browse/tls/attachments/20150915/aedb7e89/attachment.html>
>
> --
>
> Subject: Digest Footer
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> --
>
> End of TLS Digest, Vol 134, Issue 18
> 
---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

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

Re: [TLS] Should we require implementations to send alerts?

[Florian Weimer]

On 09/12/2015 10:49 PM, Eric Rescorla wrote:
> Issue: https://github.com/tlswg/tls13-spec/issues/242
> 
> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
> 
> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an alert should be SHOULD, at most."

Using full-duplex TCP, it's difficult to get a fatal alert over the wire
if you want to close the connection immediately:



The workarounds proposed in that thread may not be always practical.

-- 
Florian Weimer / Red Hat Product Security

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

Re: [TLS] Should we require implementations to send alerts?

[Salz, Rich]

> Using full-duplex TCP, it's difficult to get a fatal alert over the wire if 
> you want
> to close the connection immediately:

Yes.

But so what. )

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

Re: [TLS] Should we require implementations to send alerts?

[Nico Williams]

On Tue, Sep 15, 2015 at 03:18:30PM +0200, Florian Weimer wrote:
> On 09/12/2015 10:49 PM, Eric Rescorla wrote:
> > Issue: https://github.com/tlswg/tls13-spec/issues/242
> > 
> > In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
> > 
> > "Nobody must ever be *required* to send an alert. Any requirement for
> > sending an alert should be SHOULD, at most."
> 
> Using full-duplex TCP, it's difficult to get a fatal alert over the wire
> if you want to close the connection immediately:

But if you have a fatal error you'll be closing immediately anyways.
Does sending the fatal alert cause a problem other than increase the
likelihood of RSTs?  What is the alternative considering that the next
step is to close the connection anyways?

Nico
-- 

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

Re: [TLS] Review of PR #209

[Andrei Popov]

Perhaps we can simplify the protocol by pulling client auth out of the 
handshake as follows:

1. CertificateRequest, client Certificate, CertificateVerify and 
NewSessionTicket messages use a new content type distinct from "handshake".
2. The client can send Certificate and CertificateVerify at any time 
application data is permitted, regardless of whether the server had previously 
sent CertificateRequest.
3. The server can send CertificateRequest and NewSessionTicket at any time 
application data is permitted. Alternatively, the server can encapsulate 
CertificateRequest in an application protocol message.

Encapsulating CertificateRequest in an application protocol message allows the 
client to determine which specific application request resulted in the need for 
client auth. The application protocol would of course need to allow this.

As far as I can tell, the above scheme seems to work in both 0-RTT and 1-RTT 
modes.

We can decide exactly what CertificateVerify would be signing: whether it's the 
handshake hash or some form of RFC5705 Exported Keying Material (EKM).

Thoughts?

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson
Sent: Saturday, July 25, 2015 8:00 AM
To: tls@ietf.org
Subject: [TLS] Review of PR #209

Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209

The first expands the ways in which a server can identify certificates.  This 
is fine.  I do wonder whether we can remove CertificateType entirely for TLS 
1.3 though (that can be done separately).

The second is worrisome.  I don't like that a handshake message now has two 
different potential locations that it might appear in.  That seems like a 
hazard.  I think that we need a new content type for a new message that can be 
used after the handshake completes.  Then there are two options:
 a) remove CertificateRequest from the handshake entirely and allow the 
handshake to complete before authenticating (this has a number of hazards that 
make it probably worse than the duplication it addresses)
 b) use CertificateRequest within the handshake, and the new content type 
outside of it

___
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] WGLC for draft-ietf-tls-cached-info-19

[Sean Turner]

Hannes,

Go ahead and post the -20 version so we can get this ball rolling.

spt

On Aug 24, 2015, at 09:38, Hannes Tschofenig  wrote:

> Hi Martin,
> 
> thanks for your review.
> 
> On 08/06/2015 10:33 PM, Martin Thomson wrote:
>> I've read this draft before, but this is considerably different to
>> what I read, and I haven't been following the discussion, so consider
>> this as a review with fresh eyes.
>> 
>> First the high points.  I think that this is useful, the right scope,
>> and reasonably well formulated.  I have a couple of minor points
>> 
>> Figure 2 is in error: it shows CertificateRequest instead of Certificate.
> 
> Good catch. A copy-and-paste error.
> 
>> 
>> I'd like to see the document explicitly note that msg_type and length
>> from the handshake message are not covered by the hash.  The
>> description of what is covered is a little too terse (and badly
>> formatted).
> 
> There are multiple message type / message length fields included in the
> message and I am not sure which of those you rare referring to.
> 
> The msg_type and msg_length from the record layer is not part of the
> fingerprint calculation. The spec only focuses on the certificate
> message in Section 4.1 and the CertificateRequest message in Section
> 4.2. These message do, however, also contain length information.
> 
> I included an example into the document. See Appendix A:
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt
> 
>> 
>> I'm not sure that I like the lack of both negotiation and signaling
>> for the hashes that are used here.
> 
> We had a negotiation capability in earlier versions of the document but
> it appeared to be an overkill.
> 
> What is there now is essentially an indication of the hash algorithm
> based on what the client presents with the CachedInformationType
> structure. If you need support for a new algorithm then add a new type
> (and the implementation). We could make it easier to add new algorithms
> (via the expert review process). We could also register another
> algorithm already now, if found necessary.
> 
>> Though I think the chances of a
>> collision being found, or that a collision would lead to an attack,
>> are slim, I would rather see this use the PRF hash so we have at least
>> that much flexibility.
> 
> While there is indeed a possibility for hash collisions those will still
> lead to a failed exchange since the TLS server will not possess the
> correct private key that corresponds to the cached certificate.
> 
>> If the current design is retained, I would
>> like to see a little discussion of this in the document.  A little
>> analysis of the properties we expect the hash to provide would also be
>> good.
>> 
>> I think that truncated hashes might be advantageous from the server
>> side.  Given that the server only uses hashes to identify which of the
>> offered (available, known?) cached information is in use, is there any
>> reason you can't save additional space by arbitrarily truncating the
>> hash?  In many cases I would imagine that the client would be offering
>> only one option and even if there were a small number of options
>> presented, a single byte would suffice to disambiguate.
>> 
>> I'm trying to think why you might want the full-length hash on the
>> client side, but I believe that the only problem there is that there
>> might be a collision between the certificates that a server might
>> offer if you truncate too aggressively.  The connection still relies
>> on the server presenting proof of knowledge of a key that the client
>> extracts from a certificate bound to the server identity, so I believe
>> that it would be equally secure if you removed all mention of
>> certificates from the protocol.  And that makes me nervous, because
>> I'm fairly sure that Karthik will tell me that I'm wrong very shortly;
>> since we've put in a lot of work to cover key fields in the handshake
>> hash, and I'm concerned that this could be exploited somehow.
>> 
>> The more I think about this, the more I think that we need a little
>> more analysis on this point (i.e., what properties the hash function
>> needs to provide and why).  If it has already happened, mention of
>> that in the security considerations is needed.
>> 
>> (I think that truncation on the server side is safe if the client uses
>> a strong hash function to identify the certificate, but I'm frequently
>> wrong about these things.)
>> 
> There are three designs possible for referencing the cached state, namely
> 
> 1) The client creates the reference.
> 
> This is the current approach. The client creates a reference (via the
> use of the hash function) and tells the server that it has seen certain
> parameters before and that there is no need to re-transmit them.
> 
> 2) The server creates the reference.
> 
> In this design the server allocates the reference and sends it to the
> client. The client
> 
> 3) There is no reference at all.
> 
> Th

Re: [TLS] WGLC for draft-ietf-tls-cached-info-19

[Eric Rescorla]

Sorry it's taken me so long to respond, but I'm not convinced that it's not
necessary
to have a secure digest here. Do you have a security analysis that
demonstrates
that that's the case?

-Ekr

On Thu, Sep 10, 2015 at 7:59 AM, Martin Thomson 
wrote:

> Hi Hannes,
>
> I've followed a similar chain of thought myself.  I think that the
> right answer here is similar to what you describe: the security of TLS
> does not depend on the presence of the certificate at all, rather it
> depends on the use of a private key that the client trusts.  That most
> clients rely on the certificate for getting the information they need
> to make that trust decision and that the certificate happens to be
> carried in TLS in most cases is largely consequential.
>
> On that basis, I would be happy then to accept any hash, even a
> truncated hash in both directions.  In most cases, I suspect that 8
> bits would be plenty, though I imagine that clients will want to send
> a few more than that just to reduce the odds of having to receive a
> certificate.
>
> --Martin
>
>
> On 10 September 2015 at 04:14, Hannes Tschofenig
>  wrote:
> > Hi Martin,
> >
> > thanks for your feedback. I have discussed the topic with my co-worker
> > Manuel.
> >
> > Another way of seeing the use of the hash by the client is to help the
> > server to select the pick certificate (or other cached data). It does
> > not have a security purpose as such, it is only a way to prevent the
> > server accidentally including the wrong information. For example, this
> > can happen when the server has multiple certificates to choose from then
> > it should pick the right one (and I am not talking about the SNI case
> > here).
> >
> > Without the possibility for picking the wrong value we could have as
> > well omitted the hash altogether. The actual function used to compete
> > the fingerprint isn't that important as long as it helps to make sure
> > that the correct value can be chosen with a reasonable probably. In the
> > worst case, the wrong value is chosen and the exchange failed. The
> > client will then have to re-start the exchange without the cached info
> > feature.
> >
> > As such, you are certainly right that the hash does not need to be long
> > since the changes of selecting the wrong information is very low. In
> > case of the certificate the security actually comes from the private
> > key: the server needs to demonstrate that it knows the privacy key in
> > the exchange.
> >
> > Regarding the use of the TLS PRF I am not sure that this will work since
> > the actual function is the result of the negotiated cipher and not known
> > at the time when the client and the server exchange their hello messages.
> >
> > Ciao
> > Hannes
> >
> > PS: Additing extra text with information about what is included in the
> > hash will be added to make sure that implementers compute the hash over
> > the correct fields of the message.
> >
> >
> > On 08/24/2015 08:35 PM, Martin Thomson wrote:
> >> Hi Hannes,
> >>
> >> On 24 August 2015 at 09:38, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>  I'd like to see the document explicitly note that msg_type and length
>  from the handshake message are not covered by the hash.  The
>  description of what is covered is a little too terse (and badly
>  formatted).
> >>>
> >>> There are multiple message type / message length fields included in the
> >>> message and I am not sure which of those you rare referring to.
> >>>
> >>> The msg_type and msg_length from the record layer is not part of the
> >>> fingerprint calculation. The spec only focuses on the certificate
> >>> message in Section 4.1 and the CertificateRequest message in Section
> >>> 4.2. These message do, however, also contain length information.
> >>
> >> I refer to the msg_type and length from the handshake message, which
> >> are the only things with that name in the TLS spec.
> >>
> >> You use the name `CertificateRequest`, which leads me to conclude that
> >> you mean the struct identified as such, which is *inside* the
> >> handshake message.  (I'm fine with hashing that part, I just want to
> >> have it be very clear.)
> >>
> >>> I included an example into the document. See Appendix A:
> >>>
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt
> >>
> >> This includes the msg_type and length.  Which means that you should
> >> talk about hashing `Handshake` instead.
> >>
>  I'm not sure that I like the lack of both negotiation and signaling
>  for the hashes that are used here.
> >>>
> >>> We had a negotiation capability in earlier versions of the document but
> >>> it appeared to be an overkill.
> >>
> >> Yeah, that's why I'm thinking that this can use the PRF hash.
> >>
> >>> What is there now is essentially an indication of the hash algorithm
> >>> based on what the client presents with the CachedInformationType
> >>> structure.
> >>
> >> I don't see that anywhere.

Re: [TLS] PR for PSS support

[Joseph Salowey]

I looks like we have consensus to move forward with this PR (PSS), please
apply the change.  I think Russ's suggestion improves the text.

Thanks,

Joe

On Thu, Sep 10, 2015 at 1:18 PM, Eric Rescorla  wrote:

> https://github.com/tlswg/tls13-spec/pull/239
>
> Based on the WG discussion, I've created a PR for adding support for PSS.
> The basic tactic I took is:
>
> - All in-protocol RSA signatures (i.e., in CertificateVerify) are PSS
> - You must use MGF1 with  the same hash as you used for the content.
> - I added a rsa_pss SignatureAlgorithm field.
>
> The impact of this is that endpoints can sunset support for RSASSA-PKCS1
> by omitting it from SignatureAlgorithms.
>
> Note that I didn't deprecate SHA-1 (something Hanno suggested) but I expect
> to in another PR based on WG consensus.
>
> Please take a look.
>
> -Ekr
>
>
>
>
> ___
> 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] WGLC for draft-ietf-tls-cached-info-19

[Sean Turner]

If I recall correctly we’ve waffled on this a couple of times now; the draft 
has gone from requiring SHA-1 to FNV [0] back to SHA-1 and now I think it’s on 
SHA-256.  The switch away from FNV was primarily because it seemed odd to 
include a new algorithm for non-cryptographic purposes [1], i.e. just use SHA-1 
and be done with it.  The security considerations have evolved over time from 
requiring reasonable random properties to none back to reasonable and then to 
strong randomness requirements to being silent.

spt

[0] http://datatracker.ietf.org/doc/draft-eastlake-fnv/
[1] https://mailarchive.ietf.org/arch/msg/tls/M3U1OJamaknKaN6rTdEEo4F8dm4

On Sep 15, 2015, at 13:29, Eric Rescorla  wrote:

> Sorry it's taken me so long to respond, but I'm not convinced that it's not 
> necessary
> to have a secure digest here. Do you have a security analysis that 
> demonstrates
> that that's the case?
> 
> -Ekr
> 
> On Thu, Sep 10, 2015 at 7:59 AM, Martin Thomson  
> wrote:
> Hi Hannes,
> 
> I've followed a similar chain of thought myself.  I think that the
> right answer here is similar to what you describe: the security of TLS
> does not depend on the presence of the certificate at all, rather it
> depends on the use of a private key that the client trusts.  That most
> clients rely on the certificate for getting the information they need
> to make that trust decision and that the certificate happens to be
> carried in TLS in most cases is largely consequential.
> 
> On that basis, I would be happy then to accept any hash, even a
> truncated hash in both directions.  In most cases, I suspect that 8
> bits would be plenty, though I imagine that clients will want to send
> a few more than that just to reduce the odds of having to receive a
> certificate.
> 
> --Martin
> 
> 
> On 10 September 2015 at 04:14, Hannes Tschofenig
>  wrote:
> > Hi Martin,
> >
> > thanks for your feedback. I have discussed the topic with my co-worker
> > Manuel.
> >
> > Another way of seeing the use of the hash by the client is to help the
> > server to select the pick certificate (or other cached data). It does
> > not have a security purpose as such, it is only a way to prevent the
> > server accidentally including the wrong information. For example, this
> > can happen when the server has multiple certificates to choose from then
> > it should pick the right one (and I am not talking about the SNI case
> > here).
> >
> > Without the possibility for picking the wrong value we could have as
> > well omitted the hash altogether. The actual function used to compete
> > the fingerprint isn't that important as long as it helps to make sure
> > that the correct value can be chosen with a reasonable probably. In the
> > worst case, the wrong value is chosen and the exchange failed. The
> > client will then have to re-start the exchange without the cached info
> > feature.
> >
> > As such, you are certainly right that the hash does not need to be long
> > since the changes of selecting the wrong information is very low. In
> > case of the certificate the security actually comes from the private
> > key: the server needs to demonstrate that it knows the privacy key in
> > the exchange.
> >
> > Regarding the use of the TLS PRF I am not sure that this will work since
> > the actual function is the result of the negotiated cipher and not known
> > at the time when the client and the server exchange their hello messages.
> >
> > Ciao
> > Hannes
> >
> > PS: Additing extra text with information about what is included in the
> > hash will be added to make sure that implementers compute the hash over
> > the correct fields of the message.
> >
> >
> > On 08/24/2015 08:35 PM, Martin Thomson wrote:
> >> Hi Hannes,
> >>
> >> On 24 August 2015 at 09:38, Hannes Tschofenig  
> >> wrote:
>  I'd like to see the document explicitly note that msg_type and length
>  from the handshake message are not covered by the hash.  The
>  description of what is covered is a little too terse (and badly
>  formatted).
> >>>
> >>> There are multiple message type / message length fields included in the
> >>> message and I am not sure which of those you rare referring to.
> >>>
> >>> The msg_type and msg_length from the record layer is not part of the
> >>> fingerprint calculation. The spec only focuses on the certificate
> >>> message in Section 4.1 and the CertificateRequest message in Section
> >>> 4.2. These message do, however, also contain length information.
> >>
> >> I refer to the msg_type and length from the handshake message, which
> >> are the only things with that name in the TLS spec.
> >>
> >> You use the name `CertificateRequest`, which leads me to conclude that
> >> you mean the struct identified as such, which is *inside* the
> >> handshake message.  (I'm fine with hashing that part, I just want to
> >> have it be very clear.)
> >>
> >>> I included an example into the document. See Appendix A:
> >>> https://github.com/hannestschofenig/tschofenig-

Re: [TLS] Review of PR #209

[Andrei Popov]

> How many Certificate+CertificateVerify messages would a client be permitted 
> to send.  1? N?

I don't see a good reason to restrict to 1, although in many cases it would 
probably suffice.

> If the answer to the above is N, does the client's
> Certificate+CertificateVerify somehow identify the CertificateRequest?
> That is, how does the server identify whether this is unilateral or in 
> response to its own request?

The model I'm thinking of is where the server receives a request from the 
client, determines that the request requires authentication, then queries 
session state to see whether a suitable client credential is available.
If such client credential is not available, the server sends 
CertificateRequest. In this model, it does not matter whether the client 
volunteered a credential or responded to the server's request.

> How does a client determine if the NewSessionTicket that it receives includes 
> its authentication? That is, how can a client know whether a resumed session 
> will need a certificate or not?  (I'm not sure about this one, but the first 
> thought that occurs is that the server could include an indicator in the 
> NewSessionTicket message.)

I'd say the client should send the latest ticket it has, assume that it has all 
session context including client identity, and the server will request creds if 
this is not the case.

> Does the session need to be rekeyed as a result of this new information?  (I 
> think not, though see above regarding analysis.)

Agree on both points: the need for rekey is not obvious; until proved 
otherwise, I'm assuming no rekey.

> Do we allow for application data between Certificate and CertificateVerify? 
> (I think not.)

No application data between Certificate and CertificateVerify.

> What value do you see in having a spontaneous NewSessionTicket messages?  Is 
> this just a case of not wanting to bind it more formally to something that 
> the client sends?  

The reason I want to allow NewSessionTicket messages in mid-stream is to allow 
the server to include newly obtained client creds in the session state. If the 
server wants to do this, it can send NewSessionTicket after processing the 
client's CertificateVerify.

-Original Message-
From: Martin Thomson [mailto:martin.thom...@gmail.com] 
Sent: Tuesday, September 15, 2015 2:38 PM
To: Andrei Popov 
Cc: tls@ietf.org
Subject: Re: [TLS] Review of PR #209

This sounds like a good idea.  I certainly like how it eliminates a number of 
variations (particularly the one that #209 added).  It enables unilateral 
client authentication, which is a big plus.

My biggest concern would be the one you note and how this interacts with the 
session transcript.  It seems OK to me, but I'd like Hugo or Karthik to spend a 
few cycles thinking about that one before I'm confident there isn't an actual 
problem.

How many Certificate+CertificateVerify messages would a client be permitted to 
send.  1? N?  (I think 1)

If the answer to the above is N, does the client's
Certificate+CertificateVerify somehow identify the CertificateRequest?
 That is, how does the server identify whether this is unilateral or in 
response to its own request?

How does a client determine if the NewSessionTicket that it receives includes 
its authentication? That is, how can a client know whether a resumed session 
will need a certificate or not?  (I'm not sure about this one, but the first 
thought that occurs is that the server could include an indicator in the 
NewSessionTicket message.)

Does the session need to be rekeyed as a result of this new information?  (I 
think not, though see above regarding analysis.)

Do we allow for application data between Certificate and CertificateVerify? (I 
think not.)

Question: What value do you see in having a spontaneous NewSessionTicket 
messages?  Is this just a case of not wanting to bind it more formally to 
something that the client sends?  I worry that we'll have cases where the 
session tickets encompass new states if we permit that.


On 15 September 2015 at 13:17, Andrei Popov  wrote:
> Perhaps we can simplify the protocol by pulling client auth out of the 
> handshake as follows:
>
> 1. CertificateRequest, client Certificate, CertificateVerify and 
> NewSessionTicket messages use a new content type distinct from "handshake".
> 2. The client can send Certificate and CertificateVerify at any time 
> application data is permitted, regardless of whether the server had 
> previously sent CertificateRequest.
> 3. The server can send CertificateRequest and NewSessionTicket at any time 
> application data is permitted. Alternatively, the server can encapsulate 
> CertificateRequest in an application protocol message.
>
> Encapsulating CertificateRequest in an application protocol message allows 
> the client to determine which specific application request resulted in the 
> need for client auth. The application protocol would of course need to allow 
> this.
>
> As far as I can t

[TLS] reminder (Re: '15 TLS Fall Interim Logistics)

[Sean Turner]

In case you’re planning on attending the f2f meeting next week please fill out 
the doodle poll (http://doodle.com/ei6px58ip59gr85y) to ensure we’ve got a 
badge to get you into the building.  See you next week!

spt

On Sep 02, 2015, at 19:39, Sean Turner  wrote:

> All,
> 
> Andrei has graciously offered to host us at Microsoft in Redmond, WA [0].  
> We’re going to need a list of those that plan to attend in person in order to 
> make sure there’s a badge for you to get into the buildings.  Please fill out 
> the following doodle poll if you plan to attend in person: 
> http://doodle.com/ei6px58ip59gr85y.
> 
> Note that we’re in different buildings/rooms each day.  Here are the 
> specifics:
> 
> 09/21: 16071 NE 36th Way, REDMOND, WA, 98052 (East Campus bldg. 37 room 1727)
> 09/22: 3850 148th Ave NE, REDMOND, WA, 98052 (West Campus Studio H room 1022)
> 
> More details as we get them.
> 
> The original meeting announcement can be found at:
> https://mailarchive.ietf.org/arch/msg/tls/lfJjrpjZoidONUTIvDWzM5V52ug
> 
> spt
> 
> [0] For those of you flying, you still fly into Seattle, WA.  Don’t be 
> confused when you see the doodle poll that says “Redmond, WA".

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

Re: [TLS] Review of PR #209

[Martin Thomson]

On 15 September 2015 at 15:03, Andrei Popov  wrote:
>> That is, how does the server identify whether this is unilateral or in 
>> response to its own request?
>
> The model I'm thinking of is where the server receives a request from the 
> client, determines that the request requires authentication, then queries 
> session state to see whether a suitable client credential is available.
> If such client credential is not available, the server sends 
> CertificateRequest. In this model, it does not matter whether the client 
> volunteered a credential or responded to the server's request.

I'm concerned that this produces an indeterminate state on the server.
Say that the server receives a Certificate after it sends
CertificateRequest.  What if that Certificate doesn't conform to the
request in some way: was the Certificate just a unilateral offer that
was sent before the client received the CertificateRequest, is the
client unable to understand the CertificateRequest, or is the client
in error?  Depending on which of these is really the case, the server
is unable to decide whether it should continue awaiting a Certificate
or not.

It's not a huge issue, but I'd be happier if we nailed this sort of thing down.

>> How does a client determine if the NewSessionTicket that it receives 
>> includes its authentication? That is, how can a client know whether a 
>> resumed session will need a certificate or not?  (I'm not sure about this 
>> one, but the first thought that occurs is that the server could include an 
>> indicator in the NewSessionTicket message.)
>
> I'd say the client should send the latest ticket it has, assume that it has 
> all session context including client identity, and the server will request 
> creds if this is not the case.

That doesn't work for clients that send credentials without prompting.

>> What value do you see in having a spontaneous NewSessionTicket messages?  Is 
>> this just a case of not wanting to bind it more formally to something that 
>> the client sends?
>
> The reason I want to allow NewSessionTicket messages in mid-stream is to 
> allow the server to include newly obtained client creds in the session state. 
> If the server wants to do this, it can send NewSessionTicket after processing 
> the client's CertificateVerify.

Would you be OK with saying that NewSessionTicket can only be sent in
response to CertificateVerify or Finished?

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

Re: [TLS] Review of PR #209

[Andrei Popov]

> I'm concerned that this produces an indeterminate state on the server.
> What if that Certificate doesn't conform to the request in some way: was the 
> Certificate just a unilateral offer that was sent before the client received 
> the CertificateRequest, is the client unable to understand the 
> CertificateRequest, or is the client in error?

Traditionally, it was not an error for the client to send an empty Certificate 
message, or to offer a credential that does not match the parameters in the 
CertificateRequest. From the server's perspective, it doesn't matter what went 
wrong: the server treats the client as unauthenticated in this case (and 
possibly alerts/disconnects).

Because we want to allow the client to volunteer a certificate, there can be a 
situation where the server sends a CertificateRequest and receives an 
unsolicited client cert before the client can respond to CertificateRequest. We 
can add a flag to the client Certificate message to distinguish unsolicited 
creds from requested ones. Would this address the concern?

> That doesn't work for clients that send credentials without prompting.

Not sure what you mean, can you elaborate on the scenario?

> Would you be OK with saying that NewSessionTicket can only be sent in 
> response to CertificateVerify or Finished?

Absolutely.

-Original Message-
From: Martin Thomson [mailto:martin.thom...@gmail.com] 
Sent: Tuesday, September 15, 2015 3:26 PM
To: Andrei Popov 
Cc: tls@ietf.org
Subject: Re: [TLS] Review of PR #209

On 15 September 2015 at 15:03, Andrei Popov  wrote:
>> That is, how does the server identify whether this is unilateral or in 
>> response to its own request?
>
> The model I'm thinking of is where the server receives a request from the 
> client, determines that the request requires authentication, then queries 
> session state to see whether a suitable client credential is available.
> If such client credential is not available, the server sends 
> CertificateRequest. In this model, it does not matter whether the client 
> volunteered a credential or responded to the server's request.

I'm concerned that this produces an indeterminate state on the server.
Say that the server receives a Certificate after it sends CertificateRequest.  
What if that Certificate doesn't conform to the request in some way: was the 
Certificate just a unilateral offer that was sent before the client received 
the CertificateRequest, is the client unable to understand the 
CertificateRequest, or is the client in error?  Depending on which of these is 
really the case, the server is unable to decide whether it should continue 
awaiting a Certificate or not.

It's not a huge issue, but I'd be happier if we nailed this sort of thing down.

>> How does a client determine if the NewSessionTicket that it receives 
>> includes its authentication? That is, how can a client know whether a 
>> resumed session will need a certificate or not?  (I'm not sure about 
>> this one, but the first thought that occurs is that the server could 
>> include an indicator in the NewSessionTicket message.)
>
> I'd say the client should send the latest ticket it has, assume that it has 
> all session context including client identity, and the server will request 
> creds if this is not the case.

That doesn't work for clients that send credentials without prompting.

>> What value do you see in having a spontaneous NewSessionTicket messages?  Is 
>> this just a case of not wanting to bind it more formally to something that 
>> the client sends?
>
> The reason I want to allow NewSessionTicket messages in mid-stream is to 
> allow the server to include newly obtained client creds in the session state. 
> If the server wants to do this, it can send NewSessionTicket after processing 
> the client's CertificateVerify.

Would you be OK with saying that NewSessionTicket can only be sent in response 
to CertificateVerify or Finished?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Review of PR #209

[Andrei Popov]

> The client is now uncertain about whether the server has remembered their 
> certificate.  That's bad if there are actions that might be denied to the 
> client in the absence of the certificate.

But the server will send a CertificateRequest in this case and the client will 
have a chance to authenticate. 

> You could say that the easiest remedy is to offer the certificate again, 
> because that removes the uncertainty.  But a major reason for having 
> resumption is to avoid the public key operations on both peers, so that's not 
> a great solution.

That's why instead I say the client should send the ticket and if it turns out 
insufficient, the client will get a CertificateRequest :).

> ... but that doesn't mean that someone couldn't build a system that offers 
> different content in response to client authentication AND that system could 
> have TLS 1.3 clients authenticate without prompting in order to get that 
> different content.

This is a new use case; with PR #209 I'm mostly trying to support existing 
use-cases. But if you want to enable this new scenario, we can consider 
something like this:
- CertificateRequest can include a random ID;
- Client Certificate and CertificateVerify would either echo the ID from a 
CertificateRequest, or use a new random ID if it's unsolicited;
- NewSessionTicket would use an ID matching the client 
Certificate/CertificateVerify.

This also solves the unsolicited vs. requested client Certificate issue we 
talked about earlier. This of course introduces a bit of extra complexity.

> After all, asking has consequences that you might want to avoid, like the 
> "pick a certificate" dialog in browsers.  (Maybe you only need this behavior 
> for bespoke clients.)

I'm not sure about this.

"Pick a certificate" dialog means that the client:
a) Does not know whether the user wants to send a credential to a server;
b) Does not know which of the multiple available credentials to send to the 
server.

If you have a system where the client app knows that a certificate is required, 
and knows the specific certificate to send, there is no need for the dialog. 
Such a system is ready to respond to a CertificateRequest (without showing the 
dialog), or it could send the certificate unsolicited. I think that 
uncertainty, not CertificateRequest, is the reason for the dialog.

-Original Message-
From: Martin Thomson [mailto:martin.thom...@gmail.com] 
Sent: Tuesday, September 15, 2015 4:53 PM
To: Andrei Popov 
Cc: tls@ietf.org
Subject: Re: [TLS] Review of PR #209

On 15 September 2015 at 16:19, Andrei Popov  wrote:
>> I'm concerned that this produces an indeterminate state on the server.
>> What if that Certificate doesn't conform to the request in some way: was the 
>> Certificate just a unilateral offer that was sent before the client received 
>> the CertificateRequest, is the client unable to understand the 
>> CertificateRequest, or is the client in error?
>
> Traditionally, it was not an error for the client to send an empty 
> Certificate message, or to offer a credential that does not match the 
> parameters in the CertificateRequest. From the server's perspective, it 
> doesn't matter what went wrong: the server treats the client as 
> unauthenticated in this case (and possibly alerts/disconnects).

Right, but not all applications work on that model.  Some make the request and 
block on a response.

> Because we want to allow the client to volunteer a certificate, there can be 
> a situation where the server sends a CertificateRequest and receives an 
> unsolicited client cert before the client can respond to CertificateRequest. 
> We can add a flag to the client Certificate message to distinguish 
> unsolicited creds from requested ones. Would this address the concern?

That would work.

>> That doesn't work for clients that send credentials without prompting.
>
> Not sure what you mean, can you elaborate on the scenario?

Client connects to server and completes the handshake.
Client sends certificate immediately after Finished.
Server sends NewSessionTicket after seeing Finished or CertificateVerify; 
client is unable to tell which.
Later, Client resumes using the ticket.

The client is now uncertain about whether the server has remembered their 
certificate.  That's bad if there are actions that might be denied to the 
client in the absence of the certificate.

You could say that the easiest remedy is to offer the certificate again, 
because that removes the uncertainty.  But a major reason for having resumption 
is to avoid the public key operations on both peers, so that's not a great 
solution.

This isn't a problem with TLS <=1.2, because there is no client authentication 
without prompting, but that doesn't mean that someone couldn't build a system 
that offers different content in response to client authentication AND that 
system could have TLS 1.3 clients authenticate without prompting in order to 
get that different content.
After all, asking has c

[TLS] Call for consensus to remove anonymous DH

[Joseph Salowey]

There has been some discussion to remove anonymous DH as described in
https://www.ietf.org/mail-archive/web/tls/current/msg17481.html.  I think
ekr's message sums up the pros and cons well.  I don't think we have
consensus on this issue yet.  Please respond on this message by Monday,
September 21, if you have an opinion.

Thanks,

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

Re: [TLS] Call for consensus to remove anonymous DH

[Tom Ritter]

On 15 September 2015 at 20:42, Tony Arcieri  wrote:
> +1 for removing anonymous DH

+1.

Even for the anonymous use cases I like having a long-term key around
for people to optionally remember. (I realize we're not requiring
that.)

-tom

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

Re: [TLS] WGLC for draft-ietf-tls-cached-info-19

[Karthikeyan Bhargavan]

> Sam just ran the analysis.  The TLS 1.3 proofs they have work without
> Certificate in the transcript, which is equivalent to a zero-bit
> truncated hash.

I assume the client hello extension still has the certificate digest, yes?
This means that the analysis probably relied on agreement of the certificate 
hash from the client hello.

I’d imagine that a full security analysis of this mode depends on which model 
of certificate issuance  we use.
For example, is it possible for a website to use the same public key on two 
certificates for two different purposes? Is it possible for an attacker to 
obtain a certificate from a CA for a public key even though it does not know 
the corresponding private key? 

Also, is this mode intended to be used for RSA handshakes in TLS 1.2? In that 
case the proof of private-key possession comes quite late in the handshake. 
Even for signature-based ciphersuites, I would need to look
closer to be convinced that the ServerKeyExchange (in TLS 1.2) and 
ServerCertificateVerify (in TLS 1.3) do 
provide sufficient guarantees on which certificate/private key was used to 
create the signature.

Best,
Karthik

> 
> ___
> 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