Re: [TLS] [PATCH RFC4492bis] Add EdDSA signature support

[Ilari Liusvaara]

On Wed, Oct 21, 2015 at 09:11:51AM +0300, Yoav Nir wrote:
> LGTM. Can you push this to GitHub?
> 
> > On 20 Oct 2015, at 8:35 PM, Ilari Liusvaara  
> > wrote:
> > 
> > From: Ilari Liusvaara 
> > 
> > ---
> > On Tue, Oct 20, 2015 at 10:42:14AM +0300, Yoav Nir wrote:
> >> Hi Ilari
> >> 
> >>> - Is this document meant to also include the CFRG signatures
> >>> work? The interfaces to functions are already known.
> >> 
> >> That is the intention. A PR is welcome.
> > 
> > Well, here's an attempt at a patch. Comments welcome.

Okay, tlswg/rfc4492bis, PR #11.


This might take some editorial improvements (I'm not that good at
editorial stuff).



-Ilari

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

Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

[Benjamin Kaduk]

On 10/20/2015 10:02 PM, Zhouqian (Cathy) wrote:
> [Cathy]Yes, both web authentication and overdue use cases could be
> considered as captive portals. And I have already sent an email to the
> capport mailing list for their comments. 

I mentioned capport because it sounds like they are trying to solve the
same sort of problem that your solution is trying to solve, not because
I think your proposal will be well-received there.  I agree with Warren
and Joel that directly intercepting TLS connections is not something I
want to support.

>> In any case, it is far from clear that HTTP-specific issues should be 
>> handled at
>> the TLS layer -- TLS is a generic secure channel protocol used in many
>> applications other than HTTPS.
> [Cathy] As defined in [RFC 5246], "application protocol
>   An application protocol is a protocol that normally layers
>   directly on top of the transport layer (e.g., TCP/IP).  Examples
>   include HTTP, TELNET, FTP, and SMTP.",
> the TLS protocol could be used for HTTP applications.
>

I don't think that's quite the point I was trying to make.  HTTPS is
HTTP layered on top of TLS, yes, but in order for there to be a
separation of layers, TLS should not include any data structures that
are only useful for the HTTPS case.  This document seems to add a field
to TLS that is only used in the HTTPS use case, which seems like a
layering violation to me.

-Ben

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

Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

[Melinda Shore]

On 10/21/15 8:13 AM, Benjamin Kaduk wrote:
> I don't think that's quite the point I was trying to make.  HTTPS is
> HTTP layered on top of TLS, yes, but in order for there to be a
> separation of layers, TLS should not include any data structures that
> are only useful for the HTTPS case.  This document seems to add a field
> to TLS that is only used in the HTTPS use case, which seems like a
> layering violation to me.

In fairness you can express all sorts of endpoint addresses
as URLs, not just http.  That said I agree that this is not
an attractive proposal - the performance improvement over
existing redirect models is marginal, there may be some
unpleasant middlebox interactions, and it would require
API changes.  The cost/benefit tradeoff isn't favorable,
on balance.

Melinda

-- 
Melinda Shore
No Mountain Software
melinda.sh...@nomountain.net

"Software longa, hardware brevis."

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

[TLS] HelloRetryRequest and stateless reject

[Eric Rescorla]

Folks,

Several of the remaining TLS 1.3 issues have to do with the
ClientHello/HelloRetryRequest interaction. To recap, if the
ClientHello does not contain a KeyShare with an acceptable group, the
server sends a HelloRetryRequest indicating the correct group,
and the client sends a ClientHello with the correct group:

 Client   Server

 ClientHello
   + KeyShare  >
   <   HelloRetryRequest

 ClientHello
   + KeyShare  >
 ServerHello
  + KeyShare
 ...


DTLS has a very similar mechanism where the server provides a
HelloVerifyRequest containing a cookie in order to force the client to
provide proof of routabilty at its claimed address. The client
re-sends the ClientHello with the cookie and the handshake restarts.

It seems natural to try to merge these mechanisms, but this raises
the question of whether the handshake hashes should continue through
the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104).
The tension here is that you want to be able to have a stateless
rejection (to avoid DoS in the DTLS scenario) but having things
makes it much harder to analyze the handshake's resistance to
downgrade attacks.

Recently, Karthik, Martin Thomson, and I were talking and I think we've
come to a good resolution. The basic observation is that it's possible
to continue the handshake hash through the rejection exchange while
still being stateless. We are aware of two main techniques here:

- The server offloads its handshake hash state into the cookie
  it provides in the HelloRetryRequest (we'll need the cookie here
  in any case to support the DTLS case. The cookie obviously needs
  to be cryptographically protected, but that's what you're supposed
  to do for DTLS anyway
  (see: https://tools.ietf.org/html/rfc6347#section-4.2.1)

- The server reconstructs the original ClientHello and HelloRetryRequest
  based on the re-sent ClientHello. This is possible because there are
  very strict rules about re-sent ClientHello construction
  (namely: send the same ClientHello except just add a KeyShareEntry
  for the indicated group). The cookie should also allow the server
  to double-check this (and will also need to indicate the reason
  for rejection).

Because the handshake hash is continued through the entire handshake,
it's much easier to analyze the downgrade properties. Moreover,
servers which don't need stateless reject (because there is some
other connection construct as with TLS over TCP or DTLS with
ICE) don't need either of these techniques. They can just continue
the handshake hash in the usual way.

This seems like it fulfills both imperatives, at the primary cost of
some additional complexity on servers who really care about
statelesness (the client is indifferent to the server's implementation
strategy).

If this sounds good to people, I'll work up a PR for this, but
really all it is is saying that you don't reset the hash and
then a non-normative appendix describing stateless implementation
techniques.

Thoughts? Does anyone see anything wrong with this?
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Proposal for client auth

[Eric Rescorla]

Folks,

At the Seattle interim, we decided to have a small ad hoc design team
go and figure out how to harmonize the various forms of client
authentication. I've posted a WIP version of the output of that work
at:

https://github.com/tlswg/tls13-spec/pull/316


The basic observation (due to Karthik) is that TLS already implicitly
adopts the SIGMA framework for authentication (specifically, SIGMA-I).
To see this, consider the 1-RTT key exchange:

   ClientHello
 + ClientKeyShare>
   ServerHello
   ServerKeyShare*
 {EncryptedExtensions}
{ServerConfiguration*}
{Certificate*} <-\
 {CertificateRequest*}>
Signature
  {CertificateVerify*} <-/
 <  {Finished} <-
MAC
Sign.  /-> {Certificate*}
   \-> {CertificateVerify*}
MAC -> {Finished}>
   [Application Data]<--->  [Application Data]


Each signature covers the entire handshake up to that point, including
both identities, and the MAC is derived from g^xy (and in the case of
0-RTT, g^xs as well).


So, what this draft does is adopt the following three messages.

   Certificate
   CertificateVerify
   Finished

As the "TLS Authentication Block" and send them whenever we want to do
authentication. [Note that we may eventually merge messages here, but
that doesn't affect the logic.]

In every case, the input to the block would be:

   - A session context (SC) which is (generally) the handshake
 transcript up to this point.
   - A base key to compute the finished key from (the finished
 keys are directional, so the client and server keys are
 different).

And then the signature covers: SC + Certificate
And the MAC covers SC + Certificate + CertificateVerify

The inputs are:

Mode Handshake ContextBase Key
 -
0-RTTClientHello + ServerConfigurationxSS
 + Server Certificate
 + CertificateRequest

1-RTT (Server)   ClientHello ... ServerConfiguration  master_secret

1-RTT (Client)   ClientHello ... ServerFinished   master_secret

Post-Handshake   ClientHello ... ClientFinished + master_secret
 CertificateRequest


If we just move CertificateRequest to before Certificate, than this
effectively is what we already do for the TLS 1.3 handshake.


The proposal, then, is to adopt the following unified flow diagram.

ClientHello
  + ClientKeyShare
 ^+ EarlyDataIndication
  O-RTT  |  (Certificate*)
  mode   |  (CertificateVerify*
 v  (Finished)  // Note: new message.
(Application Data*)   >
ServerHello
ServerKeyShare*
  {EncryptedExtensions}
  {CertificateRequest*}
 {ServerConfiguration*}
 {Certificate*}  ^
   {CertificateVerify*}  |
Server Authentication
  <  {Finished}  v
 1-RTT   ^  {Certificate*}
 Client  |  {CertificateVerify*}
 Auth|  {Finished}>
 v  [Application Data]<--->  [Application Data]


  <[CertificateRequest]   ^
[Certificate] |
Post-Handshake
[CertificateVerify]   |
Authentication
[Finished]>   v


Note 1: I think the best plan here is to allow the server to send a
CertificateRequest in 1-RTT even if the client sent a certificate in
its 0-RTT first flight. This is superficially more complicated but
actually simpler since it lets us regard there as being just a 1-RTT
handshake plus some stuff that the client sends in 0-RTT.  Obviously,
this leaves the possibility that that server can ask the client for a
certificate in its first flight even with the same CertificateRequest
that the client is (implicitly) responding to in 0-RTT, and while this
is silly there's nothing stopping the server from doing this in
post-handshake auth either.

Note 2: This PR also modifies the master_secret derivation so t

Re: [TLS] New Version Notification for draft-zhou-tls-server-redirect-00.txt

[Short, Todd]

I agree with Ben here. This is very much application-layer (HTTPS) 
functionality being pushed down into the security (TLS) layer. HTTP(S) already 
has a fully functional redirect mechanism, why does this functionality need to 
be pushed to a lower layer? All the cases described in the Introduction can be 
handled at layers independent of TLS

In section 4: “...and after receiving the Get packet, the client responds with 
the…” I believe that “client” should be replaced with “server”.

Section “5. Security Considerations” is completely blank.

From the description it is not clear how much of the handshake completes before 
handling the Redirect. It implies that the Redirect may be acted upon (“fault 
warning page") before the handshake completes, and thus it is not secure. A 
MITM could easily inject the Redirect packet that impacts the client, 
preventing access.

But that is “sorta” the point, a captive portal, acting as a MITM, needs to 
authenticate the user, potentially at any time. This may be going off on a 
tangent, but if the captive portal accepted an HTTPS connection destined for 
anywhere, and if it could announce back to the client that I am your captive 
portal, and the client could verify that, then there would be no need for a 
TLS-level redirect. A browser should be able to handle this by querying for the 
router (i.e. captive portal) IP address/DNS name, and comparing that to the 
received TLS  server credentials. If they match, the client program knows it’s 
talking to a captive portal. I could go into more detail, but it outside the 
scope of this draft.

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

On Oct 21, 2015, at 12:13 PM, Benjamin Kaduk 
mailto:bka...@akamai.com>> wrote:

On 10/20/2015 10:02 PM, Zhouqian (Cathy) wrote:
[Cathy]Yes, both web authentication and overdue use cases could be
considered as captive portals. And I have already sent an email to the
capport mailing list for their comments.

I mentioned capport because it sounds like they are trying to solve the
same sort of problem that your solution is trying to solve, not because
I think your proposal will be well-received there.  I agree with Warren
and Joel that directly intercepting TLS connections is not something I
want to support.

In any case, it is far from clear that HTTP-specific issues should be handled at
the TLS layer -- TLS is a generic secure channel protocol used in many
applications other than HTTPS.
[Cathy] As defined in [RFC 5246], "application protocol
 An application protocol is a protocol that normally layers
 directly on top of the transport layer (e.g., TCP/IP).  Examples
 include HTTP, TELNET, FTP, and SMTP.",
the TLS protocol could be used for HTTP applications.


I don't think that's quite the point I was trying to make.  HTTPS is
HTTP layered on top of TLS, yes, but in order for there to be a
separation of layers, TLS should not include any data structures that
are only useful for the HTTPS case.  This document seems to add a field
to TLS that is only used in the HTTPS use case, which seems like a
layering violation to me.

-Ben

___
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] HelloRetryRequest and stateless reject

[Benjamin Kaduk]

On 10/21/2015 12:32 PM, Eric Rescorla wrote:
> Folks,
>
> Several of the remaining TLS 1.3 issues have to do with the
> ClientHello/HelloRetryRequest interaction. To recap, if the
> ClientHello does not contain a KeyShare with an acceptable group, the
> server sends a HelloRetryRequest indicating the correct group,
> and the client sends a ClientHello with the correct group:
>
>  Client   Server
>   
>  ClientHello
>+ KeyShare  >
><   HelloRetryRequest
>   
>  ClientHello
>+ KeyShare  >
>  ServerHello
>   + KeyShare
>  ...
>
>
> DTLS has a very similar mechanism where the server provides a
> HelloVerifyRequest containing a cookie in order to force the client to
> provide proof of routabilty at its claimed address. The client
> re-sends the ClientHello with the cookie and the handshake restarts.
>
> It seems natural to try to merge these mechanisms, but this raises
> the question of whether the handshake hashes should continue through
> the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104
> ).
> The tension here is that you want to be able to have a stateless
> rejection (to avoid DoS in the DTLS scenario) but having things
> makes it much harder to analyze the handshake's resistance to
> downgrade attacks.
>
> Recently, Karthik, Martin Thomson, and I were talking and I think we've
> come to a good resolution. The basic observation is that it's possible
> to continue the handshake hash through the rejection exchange while
> still being stateless. We are aware of two main techniques here:
>
> - The server offloads its handshake hash state into the cookie
>   it provides in the HelloRetryRequest (we'll need the cookie here
>   in any case to support the DTLS case. The cookie obviously needs
>   to be cryptographically protected, but that's what you're supposed
>   to do for DTLS anyway
>   (see: https://tools.ietf.org/html/rfc6347#section-4.2.1
> )
>
> - The server reconstructs the original ClientHello and HelloRetryRequest
>   based on the re-sent ClientHello. This is possible because there are
>   very strict rules about re-sent ClientHello construction
>   (namely: send the same ClientHello except just add a KeyShareEntry
>   for the indicated group). The cookie should also allow the server
>   to double-check this (and will also need to indicate the reason
>   for rejection).
>
> Because the handshake hash is continued through the entire handshake,
> it's much easier to analyze the downgrade properties. Moreover,
> servers which don't need stateless reject (because there is some
> other connection construct as with TLS over TCP or DTLS with
> ICE) don't need either of these techniques. They can just continue
> the handshake hash in the usual way.
>
> This seems like it fulfills both imperatives, at the primary cost of
> some additional complexity on servers who really care about
> statelesness (the client is indifferent to the server's implementation
> strategy).
>
> If this sounds good to people, I'll work up a PR for this, but
> really all it is is saying that you don't reset the hash and
> then a non-normative appendix describing stateless implementation
> techniques.
>
> Thoughts? Does anyone see anything wrong with this?
>

It sounds like a good plan.  The only thing that comes to mind is
whether a server might want to use encrypted (and MACd) serialized state
instead of an HMAC'd blob for the cookie where it would have to
reconstruct state from the re-sent ClientHello.  (It should be easy to
have text that allows for either case; I just wanted to mention it as a
possibility.)

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

Re: [TLS] HelloRetryRequest and stateless reject

[Short, Todd]

I like the idea. If the functionality is to be merged, perhaps harmonizing the 
names and contents of the messages (if possible)?
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Oct 21, 2015, at 1:32 PM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:

Folks,

Several of the remaining TLS 1.3 issues have to do with the
ClientHello/HelloRetryRequest interaction. To recap, if the
ClientHello does not contain a KeyShare with an acceptable group, the
server sends a HelloRetryRequest indicating the correct group,
and the client sends a ClientHello with the correct group:

 Client   Server

 ClientHello
   + KeyShare  >
   <   HelloRetryRequest

 ClientHello
   + KeyShare  >
 ServerHello
  + KeyShare
 ...


DTLS has a very similar mechanism where the server provides a
HelloVerifyRequest containing a cookie in order to force the client to
provide proof of routabilty at its claimed address. The client
re-sends the ClientHello with the cookie and the handshake restarts.

It seems natural to try to merge these mechanisms, but this raises
the question of whether the handshake hashes should continue through
the rejection exchange 
(https://github.com/tlswg/tls13-spec/issues/104).
The tension here is that you want to be able to have a stateless
rejection (to avoid DoS in the DTLS scenario) but having things
makes it much harder to analyze the handshake's resistance to
downgrade attacks.

Recently, Karthik, Martin Thomson, and I were talking and I think we've
come to a good resolution. The basic observation is that it's possible
to continue the handshake hash through the rejection exchange while
still being stateless. We are aware of two main techniques here:

- The server offloads its handshake hash state into the cookie
  it provides in the HelloRetryRequest (we'll need the cookie here
  in any case to support the DTLS case. The cookie obviously needs
  to be cryptographically protected, but that's what you're supposed
  to do for DTLS anyway
  (see: 
https://tools.ietf.org/html/rfc6347#section-4.2.1)

- The server reconstructs the original ClientHello and HelloRetryRequest
  based on the re-sent ClientHello. This is possible because there are
  very strict rules about re-sent ClientHello construction
  (namely: send the same ClientHello except just add a KeyShareEntry
  for the indicated group). The cookie should also allow the server
  to double-check this (and will also need to indicate the reason
  for rejection).

Because the handshake hash is continued through the entire handshake,
it's much easier to analyze the downgrade properties. Moreover,
servers which don't need stateless reject (because there is some
other connection construct as with TLS over TCP or DTLS with
ICE) don't need either of these techniques. They can just continue
the handshake hash in the usual way.

This seems like it fulfills both imperatives, at the primary cost of
some additional complexity on servers who really care about
statelesness (the client is indifferent to the server's implementation
strategy).

If this sounds good to people, I'll work up a PR for this, but
really all it is is saying that you don't reset the hash and
then a non-normative appendix describing stateless implementation
techniques.

Thoughts? Does anyone see anything wrong with this?
-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] HelloRetryRequest and stateless reject

[Eric Rescorla]

On Wed, Oct 21, 2015 at 11:07 AM, Benjamin Kaduk  wrote:

> On 10/21/2015 12:32 PM, Eric Rescorla wrote:
>
> Folks,
>
> Several of the remaining TLS 1.3 issues have to do with the
> ClientHello/HelloRetryRequest interaction. To recap, if the
> ClientHello does not contain a KeyShare with an acceptable group, the
> server sends a HelloRetryRequest indicating the correct group,
> and the client sends a ClientHello with the correct group:
>
>  Client   Server
>
>  ClientHello
>+ KeyShare  >
><   HelloRetryRequest
>
>  ClientHello
>+ KeyShare  >
>  ServerHello
>   + KeyShare
>  ...
>
>
> DTLS has a very similar mechanism where the server provides a
> HelloVerifyRequest containing a cookie in order to force the client to
> provide proof of routabilty at its claimed address. The client
> re-sends the ClientHello with the cookie and the handshake restarts.
>
> It seems natural to try to merge these mechanisms, but this raises
> the question of whether the handshake hashes should continue through
> the rejection exchange (
> 
> https://github.com/tlswg/tls13-spec/issues/104).
> The tension here is that you want to be able to have a stateless
> rejection (to avoid DoS in the DTLS scenario) but having things
> makes it much harder to analyze the handshake's resistance to
> downgrade attacks.
>
> Recently, Karthik, Martin Thomson, and I were talking and I think we've
> come to a good resolution. The basic observation is that it's possible
> to continue the handshake hash through the rejection exchange while
> still being stateless. We are aware of two main techniques here:
>
> - The server offloads its handshake hash state into the cookie
>   it provides in the HelloRetryRequest (we'll need the cookie here
>   in any case to support the DTLS case. The cookie obviously needs
>   to be cryptographically protected, but that's what you're supposed
>   to do for DTLS anyway
>   (see: https://tools.ietf.org/html/rfc6347#section-4.2.1
> 
> )
>
> - The server reconstructs the original ClientHello and HelloRetryRequest
>   based on the re-sent ClientHello. This is possible because there are
>   very strict rules about re-sent ClientHello construction
>   (namely: send the same ClientHello except just add a KeyShareEntry
>   for the indicated group). The cookie should also allow the server
>   to double-check this (and will also need to indicate the reason
>   for rejection).
>
> Because the handshake hash is continued through the entire handshake,
> it's much easier to analyze the downgrade properties. Moreover,
> servers which don't need stateless reject (because there is some
> other connection construct as with TLS over TCP or DTLS with
> ICE) don't need either of these techniques. They can just continue
> the handshake hash in the usual way.
>
> This seems like it fulfills both imperatives, at the primary cost of
> some additional complexity on servers who really care about
> statelesness (the client is indifferent to the server's implementation
> strategy).
>
> If this sounds good to people, I'll work up a PR for this, but
> really all it is is saying that you don't reset the hash and
> then a non-normative appendix describing stateless implementation
> techniques.
>
> Thoughts? Does anyone see anything wrong with this?
>
>
> It sounds like a good plan.  The only thing that comes to mind is whether
> a server might want to use encrypted (and MACd) serialized state instead of
> an HMAC'd blob for the cookie where it would have to reconstruct state from
> the re-sent ClientHello.  (It should be easy to have text that allows for
> either case; I just wanted to mention it as a possibility.)
>

Yes, this also seems like a good alternative.

Best,
-Ekr

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

Re: [TLS] HelloRetryRequest and stateless reject

[Eric Rescorla]

On Wed, Oct 21, 2015 at 11:13 AM, Short, Todd  wrote:

> I like the idea. If the functionality is to be merged, perhaps harmonizing
> the names and contents of the messages (if possible)?
>

Yes. My plan is to name it HelloRetryRequest and get rid of
HelloVerifyRequest.

-Ekr


> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Oct 21, 2015, at 1:32 PM, Eric Rescorla  wrote:
>
> Folks,
>
> Several of the remaining TLS 1.3 issues have to do with the
> ClientHello/HelloRetryRequest interaction. To recap, if the
> ClientHello does not contain a KeyShare with an acceptable group, the
> server sends a HelloRetryRequest indicating the correct group,
> and the client sends a ClientHello with the correct group:
>
>  Client   Server
>
>  ClientHello
>+ KeyShare  >
><   HelloRetryRequest
>
>  ClientHello
>+ KeyShare  >
>  ServerHello
>   + KeyShare
>  ...
>
>
> DTLS has a very similar mechanism where the server provides a
> HelloVerifyRequest containing a cookie in order to force the client to
> provide proof of routabilty at its claimed address. The client
> re-sends the ClientHello with the cookie and the handshake restarts.
>
> It seems natural to try to merge these mechanisms, but this raises
> the question of whether the handshake hashes should continue through
> the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104
> 
> ).
> The tension here is that you want to be able to have a stateless
> rejection (to avoid DoS in the DTLS scenario) but having things
> makes it much harder to analyze the handshake's resistance to
> downgrade attacks.
>
> Recently, Karthik, Martin Thomson, and I were talking and I think we've
> come to a good resolution. The basic observation is that it's possible
> to continue the handshake hash through the rejection exchange while
> still being stateless. We are aware of two main techniques here:
>
> - The server offloads its handshake hash state into the cookie
>   it provides in the HelloRetryRequest (we'll need the cookie here
>   in any case to support the DTLS case. The cookie obviously needs
>   to be cryptographically protected, but that's what you're supposed
>   to do for DTLS anyway
>   (see: https://tools.ietf.org/html/rfc6347#section-4.2.1
> 
> )
>
> - The server reconstructs the original ClientHello and HelloRetryRequest
>   based on the re-sent ClientHello. This is possible because there are
>   very strict rules about re-sent ClientHello construction
>   (namely: send the same ClientHello except just add a KeyShareEntry
>   for the indicated group). The cookie should also allow the server
>   to double-check this (and will also need to indicate the reason
>   for rejection).
>
> Because the handshake hash is continued through the entire handshake,
> it's much easier to analyze the downgrade properties. Moreover,
> servers which don't need stateless reject (because there is some
> other connection construct as with TLS over TCP or DTLS with
> ICE) don't need either of these techniques. They can just continue
> the handshake hash in the usual way.
>
> This seems like it fulfills both imperatives, at the primary cost of
> some additional complexity on servers who really care about
> statelesness (the client is indifferent to the server's implementation
> strategy).
>
> If this sounds good to people, I'll work up a PR for this, but
> really all it is is saying that you don't reset the hash and
> then a non-normative appendix describing stateless implementation
> techniques.
>
> Thoughts? Does anyone see anything wrong with this?
> -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] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

[Hanno Böck]

Not sure if I'm getting anything wrong, but doesn't this open a huge
security hole?

Scenario right now is that if I want to be secure on a webpage I type
in its HTTPS URL (either directly or through a bookmark) and can be
pretty much sure that as long as I don't click on external links that
I'll stay on that webpage.

Basically this proposal would allow a man-in-the-middle to send
me to another webpage each time I click on a (supposedly https
protected) link. Given that there are many browsers these days
(mobile) that hide the URL bar thats even more severe.

This severely changes the security expectations one can have from a
browser.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


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

Re: [TLS] New Version Notification for draft-zhou-tls-server-redirect-00.txt

[Yoav Nir]

> On 21 Oct 2015, at 9:03 PM, Short, Todd  wrote:
> 
> I agree with Ben here. This is very much application-layer (HTTPS) 
> functionality being pushed down into the security (TLS) layer.

In fairness, if the TLS layer is blocking you, you don’t get to talk to the 
HTTP layer. So the captive portal intercept case has to be solved at the TLS 
layer or lower still.

Yoav

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

[TLS] Controlling use of SHA-1

[Martin Thomson]

The current draft permits the use of SHA-1 in the certificate chain,
which gives SHA-1 a free pass indefinitely. Since we expressly forbid
the use of SHA-1 for signing in TLS itself, we can just permit clients
to include it in "signature_algorithms" and use that to determine
whether SHA-1 is acceptable.

That means that clients that want to disable SHA-1 (real soon now, we
promise), can signal that preference cleanly.

I've opened PR #317 for this, but the commit is probably more useful
to review, since I built this on top of ekr's client authentication
changes (to avoid messy rebases):

https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5

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

Re: [TLS] Controlling use of SHA-1

[Eric Rescorla]

I think this is the right answer and parallels what we are doing with PSS.

-Ekr


On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson 
wrote:

> The current draft permits the use of SHA-1 in the certificate chain,
> which gives SHA-1 a free pass indefinitely. Since we expressly forbid
> the use of SHA-1 for signing in TLS itself, we can just permit clients
> to include it in "signature_algorithms" and use that to determine
> whether SHA-1 is acceptable.
>
> That means that clients that want to disable SHA-1 (real soon now, we
> promise), can signal that preference cleanly.
>
> I've opened PR #317 for this, but the commit is probably more useful
> to review, since I built this on top of ekr's client authentication
> changes (to avoid messy rebases):
>
>
> https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5
>
> ___
> 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] HelloRetryRequest and stateless reject

[Ilari Liusvaara]

On Wed, Oct 21, 2015 at 11:17:10AM -0700, Eric Rescorla wrote:
> On Wed, Oct 21, 2015 at 11:13 AM, Short, Todd  wrote:
> 
> > I like the idea. If the functionality is to be merged, perhaps harmonizing
> > the names and contents of the messages (if possible)?
> >
> 
> Yes. My plan is to name it HelloRetryRequest and get rid of
> HelloVerifyRequest.

Bit crazy idea: Have vector of causes handshake went wrong
(e.g. required share missing, cookie required). Then the
client verifies that that:
- There is at least one cause
- All causes are known (can't retry with unknown error)
- All causes are proper (e.g. actual missing share).


-Ilari

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

Re: [TLS] HelloRetryRequest and stateless reject

[Martin Thomson]

On 21 October 2015 at 12:29, Ilari Liusvaara  wrote:
> Bit crazy idea: Have vector of causes handshake went wrong
> (e.g. required share missing, cookie required). Then the
> client verifies that that:
> - There is at least one cause
> - All causes are known (can't retry with unknown error)
> - All causes are proper (e.g. actual missing share).

The client doesn't need this information, though the server might.
That is, if it doesn't want to try several options to see which one
passes the MAC, noting that there aren't that many options.  Given
that, I don't think we need to specify anything.

Note that absence of cookie is the only valid starting state, so you
don't need a bit for that.

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

Re: [TLS] Controlling use of SHA-1

[Andrei Popov]

I am in favor of this change: it prohibits the server to send SHA-1 certs when 
signature_algorithms does not advertise SHA-1.

IMHO it would be best to not allow the server to send certs using any 
algorithms that don’t agree with signature_algorithms, as TLS 1.2 did. But this 
is a step in the right direction.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, October 21, 2015 12:18 PM
To: Martin Thomson 
Cc: tls@ietf.org
Subject: Re: [TLS] Controlling use of SHA-1

I think this is the right answer and parallels what we are doing with PSS.

-Ekr


On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson 
mailto:martin.thom...@gmail.com>> wrote:
The current draft permits the use of SHA-1 in the certificate chain,
which gives SHA-1 a free pass indefinitely. Since we expressly forbid
the use of SHA-1 for signing in TLS itself, we can just permit clients
to include it in "signature_algorithms" and use that to determine
whether SHA-1 is acceptable.

That means that clients that want to disable SHA-1 (real soon now, we
promise), can signal that preference cleanly.

I've opened PR #317 for this, but the commit is probably more useful
to review, since I built this on top of ekr's client authentication
changes (to avoid messy rebases):

https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5

___
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] Controlling use of SHA-1

[Viktor Dukhovni]

On Wed, Oct 21, 2015 at 12:15:25PM -0700, Martin Thomson wrote:

> The current draft permits the use of SHA-1 in the certificate chain,
> which gives SHA-1 a free pass indefinitely.

Forbidding the sending of SHA-1 chains was wrong last time we
discussed this at length, and remains wrong now.

Whether SHA-1 in the chain is used to make trust decisions is only
known to the client, and the server MUST NOT preempt that by denying
the client access to whatever chain it has on hand.

Each peer MUST try to send a chain that matches an advertised
signature algorithm if it has a choice of chains, but otherwise
MUST send whatever it has.

> That means that clients that want to disable SHA-1 (real soon now, we
> promise), can signal that preference cleanly.

The clients can indeed not signal SHA-1 support, and SHOULD avoid
trusting SHA-1, but the server MUST still send whatever chain it
has and let the client decide.

> I've opened PR #317 for this, but the commit is probably more useful
> to review, since I built this on top of ekr's client authentication
> changes (to avoid messy rebases):
> 
> https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5

The final diff "hunk" is dejavu-all-over-again.  This text must
stay unchanged.

 indicated supported pairs, then it SHOULD continue the handshake by sending
 the client a certificate chain of its choice that may include algorithms
 that are not known to be supported by the client. This fallback chain MAY
-use the deprecated SHA-1 hash algorithm.
+use the deprecated SHA-1 hash algorithm only if the "signature_algorithms"
+extension provided by the client permits it.
 If the client cannot construct an acceptable chain using the provided
 certificates and decides to abort the handshake, then it MUST send an
 "unsupported_certificate" alert message and close the connection.

So, no to the diff above.

-- 
Viktor.

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

Re: [TLS] Controlling use of SHA-1

[Martin Thomson]

On 21 October 2015 at 12:56, Viktor Dukhovni  wrote:
> Each peer MUST try to send a chain that matches an advertised
> signature algorithm if it has a choice of chains, but otherwise
> MUST send whatever it has.

Do, or do not.  There is no try.

It's not like any of this is ambiguous in any way.

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

[TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 7685

Title:  A Transport Layer Security (TLS) 
ClientHello Padding Extension 
Author: A. Langley
Status: Standards Track
Stream: IETF
Date:   October 2015
Mailbox:a...@google.com
Pages:  4
Characters: 7034
Updates:RFC 5246

I-D Tag:draft-ietf-tls-padding-04.txt

URL:https://www.rfc-editor.org/info/rfc7685

DOI:http://dx.doi.org/10.17487/RFC7685

This memo describes a Transport Layer Security (TLS) extension that
can be used to pad ClientHello messages to a desired size.

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/rfc.html

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

Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension

[Martin Thomson]

On 21 October 2015 at 13:43,   wrote:
> RFC 7685
>
> Title:  A Transport Layer Security (TLS)
> ClientHello Padding Extension

That took longer than I expected.  Nice work.

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

Re: [TLS] New Version Notification for draft-cairns-tls-session-key-interface-01.txt

[Daniel Migault]

Hi, 

Please find our new version from of the Session Key Interface for TLS and DTLS.

The main motivation for this interface is that the private key is centralized 
in a Key Server instead of being distributed and copied among the Edge Servers. 
All cryptographic operation are performed by the Key Server and the Edge Server 
uses this interface.   

Feel free to comment the draft but here are some our concerns and we would like 
to know your opinion:

QUESTION 1) An interaction occurs when RSA or ephemeral Diffie Hellman 
(DHE_RSA, ECDHE_RSA or ECDHE_ECDSA) key agreement . In your opinion, should we 
consider RSA?

QUESTION 2) When Diffie Hellman is used, to build the signature, the Edge 
Server provides all parameters to the key Server, and the Key Server hashes and 
signs. An alternative would be the Edge Server hashes and requests the Key 
Server to sign it. We believe the first alternative is more secure, but the 
second generates less load on the network . Do you have any opinion regarding 
these two alternatives.

BR, 
Daniel

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, October 19, 2015 7:59 PM
To: Kelsey Cairns; John Mattsson; Daniel Migault; Robert Skog
Subject: New Version Notification for 
draft-cairns-tls-session-key-interface-01.txt


A new version of I-D, draft-cairns-tls-session-key-interface-01.txt
has been successfully submitted by John Mattsson and posted to the IETF 
repository.

Name:   draft-cairns-tls-session-key-interface
Revision:   01
Title:  Session Key Interface (SKI) for TLS and DTLS
Document date:  2015-10-19
Group:  Individual Submission
Pages:  24
URL:
https://www.ietf.org/internet-drafts/draft-cairns-tls-session-key-interface-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-cairns-tls-session-key-interface/
Htmlized:   
https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-cairns-tls-session-key-interface-01

Abstract:
   This document describes a session key interface that can be used for
   TLS and DTLS.  The Heartbleed attack has clearly illustrated the
   security problems with storing private keys in the memory of the TLS
   server.  Hardware Security Modules (HSM) offer better protection but
   are inflexible, especially as more (D)TLS servers are running on
   virtualized servers in data centers.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

[TLS] Remove extra 0-RTT content types

[Eric Rescorla]

https://github.com/tlswg/tls13-spec/issues/311

I initially added this to make it easier to determine the end of the 0-RTT
handshake if the server had forgotten the key, but with content type
encryption
this is no longer relevant. I propose we remove this and simply use
Handshake here, allowing the keying material to differentiate these.

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

Re: [TLS] Remove extra 0-RTT content types

[Martin Thomson]

I'm not sure that I follow.  Are all the records in 0RTT going to use
a content of handshake, or just the
Certificate/CertificateVerify/Finished?  I assume that you meant just
the handshake messages, in which case yes, this is OK.  It does make
identification of what goes into the handshake hash marginally more
difficult.

With your client authentication changes, you could just concatenate up
everything with content type of handshake.  Now you have to be a
little more selective.

On 21 October 2015 at 15:44, Eric Rescorla  wrote:
> https://github.com/tlswg/tls13-spec/issues/311
>
> I initially added this to make it easier to determine the end of the 0-RTT
> handshake if the server had forgotten the key, but with content type
> encryption
> this is no longer relevant. I propose we remove this and simply use
> Handshake here, allowing the keying material to differentiate these.
>
> -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] Remove extra 0-RTT content types

[Eric Rescorla]

On Wed, Oct 21, 2015 at 3:52 PM, Martin Thomson 
wrote:

> I'm not sure that I follow.  Are all the records in 0RTT going to use
> a content of handshake, or just the
> Certificate/CertificateVerify/Finished?  I assume that you meant just
> the handshake messages, in which case yes, this is OK.


Yes. The application data would be application_data, etc.




> It does make
> identification of what goes into the handshake hash marginally more
> difficult.
>
> With your client authentication changes, you could just concatenate up
> everything with content type of handshake.  Now you have to be a
> little more selective.


I don't think this will make the implementation that hard :)

-Ekr

On 21 October 2015 at 15:44, Eric Rescorla  wrote:
> > https://github.com/tlswg/tls13-spec/issues/311
> >
> > I initially added this to make it easier to determine the end of the
> 0-RTT
> > handshake if the server had forgotten the key, but with content type
> > encryption
> > this is no longer relevant. I propose we remove this and simply use
> > Handshake here, allowing the keying material to differentiate these.
> >
> > -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] Remove extra 0-RTT content types

[Martin Thomson]

On 21 October 2015 at 15:52, Eric Rescorla  wrote:
> I don't think this will make the implementation that hard :)

Yeah, you have to actually pay attention to the early_data extension.
That might not be a bad thing in the end.

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

Re: [TLS] Remove extra 0-RTT content types

[Eric Rescorla]

On Wed, Oct 21, 2015 at 3:56 PM, Martin Thomson 
wrote:

> On 21 October 2015 at 15:52, Eric Rescorla  wrote:
> > I don't think this will make the implementation that hard :)
>
> Yeah, you have to actually pay attention to the early_data extension.
> That might not be a bad thing in the end.
>

Yes, you do have to.

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

Re: [TLS] Controlling use of SHA-1

[Dave Garrett]

I'm in favor of this change as well. It annoys Viktor, as it changes the 
fallback in a way that isn't ideal for some cases that trust the cert directly 
or with OE, but I think it's better than the alternative.


Dave


On Wednesday, October 21, 2015 03:17:44 pm Eric Rescorla wrote:
> I think this is the right answer and parallels what we are doing with PSS.
> 
> -Ekr
> 
> 
> On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson 
> wrote:
> 
> > The current draft permits the use of SHA-1 in the certificate chain,
> > which gives SHA-1 a free pass indefinitely. Since we expressly forbid
> > the use of SHA-1 for signing in TLS itself, we can just permit clients
> > to include it in "signature_algorithms" and use that to determine
> > whether SHA-1 is acceptable.
> >
> > That means that clients that want to disable SHA-1 (real soon now, we
> > promise), can signal that preference cleanly.
> >
> > I've opened PR #317 for this, but the commit is probably more useful
> > to review, since I built this on top of ekr's client authentication
> > changes (to avoid messy rebases):
> >
> >
> > https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5

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

[TLS] Allow NamedGroups from the server?

[Eric Rescorla]

https://github.com/tlswg/tls13-spec/issues/292

Presently, RFC 4492 only specifies the EC points it can support in
ServerHello, but does not let the server indicate which EC curves it
supports. Unless I'm missing something, this means that there's
no way for the server to indicate what groups it would support.

That seems less than ideal. There seem like three options here:

1. Put it in CertificateRequest
2. Send it in ServerHello
3. Do nothing.

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

Re: [TLS] Allow NamedGroups from the server?

[Martin Thomson]

2b. encrypted extensions over ServerHello

If we make this like signature_algorithms, then I think that I prefer
option 1.  I don't like that signature_algorithms is built that way, I
think that it's repulsive, but there are some advantages to doing it
that way, especially if we accept the fact that the client can
authenticate multiple times, so I'm willing to live with that.

On 21 October 2015 at 16:56, Eric Rescorla  wrote:
> https://github.com/tlswg/tls13-spec/issues/292
>
> Presently, RFC 4492 only specifies the EC points it can support in
> ServerHello, but does not let the server indicate which EC curves it
> supports. Unless I'm missing something, this means that there's
> no way for the server to indicate what groups it would support.
>
> That seems less than ideal. There seem like three options here:
>
> 1. Put it in CertificateRequest
> 2. Send it in ServerHello
> 3. Do nothing.
>
> Thoughts?
> -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] Allow NamedGroups from the server?

[Andrei Popov]

If it's true that the only use of this indication is client auth, then option 1 
makes the most sense to me.

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson
Sent: Wednesday, October 21, 2015 5:01 PM
To: Eric Rescorla 
Cc: tls@ietf.org
Subject: Re: [TLS] Allow NamedGroups from the server?

2b. encrypted extensions over ServerHello

If we make this like signature_algorithms, then I think that I prefer option 1. 
 I don't like that signature_algorithms is built that way, I think that it's 
repulsive, but there are some advantages to doing it that way, especially if we 
accept the fact that the client can authenticate multiple times, so I'm willing 
to live with that.

On 21 October 2015 at 16:56, Eric Rescorla  wrote:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2ftlswg%2ftls13-spec%2fissues%2f292&data=01%7c01%7cAndrei.Popov%
> 40microsoft.com%7c6625ee4cf40f4f52917108d2da73ea39%7c72f988bf86f141af9
> 1ab2d7cd011db47%7c1&sdata=qOVO5xpSgVIXG6%2fiMyP3zQSbeFwZlrDW1kcqvONCRD
> Y%3d
>
> Presently, RFC 4492 only specifies the EC points it can support in 
> ServerHello, but does not let the server indicate which EC curves it 
> supports. Unless I'm missing something, this means that there's no way 
> for the server to indicate what groups it would support.
>
> That seems less than ideal. There seem like three options here:
>
> 1. Put it in CertificateRequest
> 2. Send it in ServerHello
> 3. Do nothing.
>
> Thoughts?
> -Ekr
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40micro
> soft.com%7c6625ee4cf40f4f52917108d2da73ea39%7c72f988bf86f141af91ab2d7c
> d011db47%7c1&sdata=%2f612ldpCER8pXNtxSxUfQjhuYcMAIZ2S3o1ozmxqqWI%3d
>

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c6625ee4cf40f4f52917108d2da73ea39%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2f612ldpCER8pXNtxSxUfQjhuYcMAIZ2S3o1ozmxqqWI%3d

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

Re: [TLS] Controlling use of SHA-1

[Dave Garrett]

On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote:
> Whether SHA-1 in the chain is used to make trust decisions is only
> known to the client, and the server MUST NOT preempt that by denying
> the client access to whatever chain it has on hand.

Can we please just fix this issue properly and add an "any(0xFF)" value to the 
enum so clients can explicitly tell the server that they're capable of trusting 
certs directly (or is doing OE) and the hash is potentially irrelevant?

Note that the current proposed change does not break your use-case. Those 
clients can simply offer SHA-1 support indefinitely. Sure, they don't strictly 
support using SHA-1, but they support receiving certs using it, which is all 
the signal is really for.


Dave

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

Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension

[Dave Garrett]

Congrats on releasing an RFC that has day one 100% server support. :p


Dave

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

Re: [TLS] Allow NamedGroups from the server?

[Dave Garrett]

On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/issues/292
> 
> Presently, RFC 4492 only specifies the EC points it can support in
> ServerHello, but does not let the server indicate which EC curves it
> supports. Unless I'm missing something, this means that there's
> no way for the server to indicate what groups it would support.
> 
> That seems less than ideal. There seem like three options here:
> 
> 1. Put it in CertificateRequest
> 2. Send it in ServerHello
> 3. Do nothing.

I prefer #2. I don't think encryption is necessarily required for this, but 
EncryptedExtensions is fine too (Martin's 2b).

I'm generally against putting it in CertificateRequest, as we're reusing an 
existing hello extension so keeping it in a hello message (or it's trailing 
encrypted field) seems best. (restricted to TLS 1.3+ clients, though)


Dave

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

Re: [TLS] Allow NamedGroups from the server?

[Eric Rescorla]

On Wed, Oct 21, 2015 at 5:29 PM, Dave Garrett 
wrote:

> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
> > https://github.com/tlswg/tls13-spec/issues/292
> >
> > Presently, RFC 4492 only specifies the EC points it can support in
> > ServerHello, but does not let the server indicate which EC curves it
> > supports. Unless I'm missing something, this means that there's
> > no way for the server to indicate what groups it would support.
> >
> > That seems less than ideal. There seem like three options here:
> >
> > 1. Put it in CertificateRequest
> > 2. Send it in ServerHello
> > 3. Do nothing.
>
> I prefer #2. I don't think encryption is necessarily required for this,
> but EncryptedExtensions is fine too (Martin's 2b).
>
> I'm generally against putting it in CertificateRequest, as we're reusing
> an existing hello extension so keeping it in a hello message (or it's
> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,
> though)


This would need to be limited to 1.3 in any case because in all the other
cases
it would be illegal.

-Ekr


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

Re: [TLS] Comments from CELLOS consortium

[Shin'ichiro Matsuo]

Dear Sean, Eric, Dave, and all,

We appreciate much kind treatment for our comments at GitHub on the following 
items.

CELLOS: AEAD-1/2
CELLOS: 0-RTT 1/2/3
CELLOS: Resumption & PSK 2
CELLOS: KDF
CELLOS: SharedSecret
CELLOS: ClientAuthentication
CELLOS: HelloRetryRequest

With Best Regards,
Shin’ichiro Matsuo

> On Oct 18, 2015, at 6:13 AM, Sean Turner  wrote:
> 
> Since we’ve been using github as an issue tracker, I’m going to copy these 
> comments there.  I’m going to put “CELLOS” somewhere in the issue so they can 
> be easily found.  Also note that some of these are resolved, similar to 
> others, or over taken by events so I expect some to be closed almost 
> immediately.
> 
> spt
> 
> 
> On Oct 05, 2015, at 15:54, Shin'ichiro Matsuo  wrote:
> 
>> Dear all,
>> 
>> Members in the CELLOS consortium (https://www.cellos-consortium.org), which 
>> is the consortium on security of cryptographic protocols, are studying on 
>> the TLS 1.3 protocol. We have several comments and suggestions to make the 
>> specification of TLS1.3 better. 
>> 
>> Please find the comments at the following URL.
>> 
>> https://www.cellos-consortium.org/studygroup/tls_1_3-draft_08_issues_rev1.pdf
>> 
>> The comments are on the following matters.
>> 
>> - AEAD
>> - KDF
>> - Full Handshake
>> - Hello Retry Request
>> - Shared Secret
>> - Client Authentication
>> - Cipher Suite
>> - 0-RTT
>> - Resumption and PSK
>> 
>> Some of them are already fixed, such as HFDF. However, we left it as a 
>> result of our study.
>> 
>> 
>> Regards,
>> Shin’ichiro Matsuo
>> ___
>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Controlling use of SHA-1

[Viktor Dukhovni]

On Wed, Oct 21, 2015 at 08:14:19PM -0400, Dave Garrett wrote:

> On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote:
> > Whether SHA-1 in the chain is used to make trust decisions is only
> > known to the client, and the server MUST NOT preempt that by denying
> > the client access to whatever chain it has on hand.
> 
> Can we please just fix this issue properly and add an "any(0xFF)" value
> to the enum so clients can explicitly tell the server that they're capable
> of trusting certs directly (or is doing OE) and the hash is potentially
> irrelevant?

This forces a new signalling channel from TLS clients that need
this to their TLS library to enable this new "any" value.  Not an
API that's found in existing libraries or applications.  Previously
the TLS library would just let clients validate chains as they fit.

> Note that the current proposed change does not break your use-case. Those
> clients can simply offer SHA-1 support indefinitely. Sure, they don't
> strictly support using SHA-1, but they support receiving certs using it,
> which is all the signal is really for.

Yes, the signal "would" suffice, if it were practical to inject
it.  On the other hand, interposing on trust decisions for RFC 5280
chains is not the proper job of TLS.  And the chain the server has
may not get used by the client in full (the client might replace
some issuer certs with alternative certs for the "same" issuer).

So, just as before, why is the TLS server the proper vehicle for
hiding SHA-1 certs from potentially, but not necessarily PKIX
clients?  What's wrong with just having the various CAs no longer
issue SHA-1 certs, and the PKIX code in TLS libraries no longer
trusting SHA-1 certs by default?  Do we really need a third
counter-measure that exceeds the proper scope of TLS?

-- 
Viktor.

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