Re: [TLS] Certificate compression draft

[Sankalp Bagaria]

Hello,

How is Certificate Compression advantageous over tls cached-info extension?
Only case I can think of is - when the certificate is being sent for the first
time,
it can be compressed. Since the client doesn't have a copy of the certificate,
cached-info can't be used. Are there more cases where compression is useful?

Another point that need to be seen is that the time required to compress/
decompress is not more than the savings got in transmitting a compressed
certificate (smaller in size than complete certificate).

Thanks and Regards,
Sankalp Bagaria.

On Mon, Mar 6, 2017 at 2:58 PM, Victor Vasiliev < vasi...@google.com
 > wrote:

>  Certificate   compression  has been discussed on this list briefly before,
> and
> there was some interest in at least considering a  draft  for it.  The  draft
> now
> exists (co-authored by Alessandro and myself), and it can be found at:
>
>  https://datatracker.ietf.org/doc/draft-ghedini-tls-
> 
>  certificate - compression /
>   [ GitHub repo:  https://github.com/ghedo/tls-certificate-compression
>   ]
>
> The proposed scheme allows a client and a server to negotiate a  compression
> algorithm for the server  certificate  message.  The scheme is purely opt-in
> on
> both sides.  The current version of the  draft  defines zlib and Brotli
>  compression , both of which are well-specified formats with an existing
> deployment experience.
>
> There are multiple motivations to compress certificates.  The first one is
> that
> the smaller they are, the faster they arrive (both due to the transfer
> time and
> a decreased chance of packet loss).
>
> The second, and more interesting one, is that having small certificates is
> important for QUIC in order to achieve 1-RTT handshakes while limiting the
> opportunities for amplification attacks.  Currently,  TLS  1.3 over TCP
> without
> client auth looks like this:
>
>   Round trip 1: client sends SYN, server sends SYN ACK
> Here, the server provides its own random value which client will
> have to echo in the future.
>   Round trip 2: client sends ACK, ClientHello, server sends
> ServerHello...Finished
> Here, ACK confirms to server that the client can receive packets and
> is not
> just spoofing its source address.  Server can send the entire
> ServerHello to
> Finished flight.
>
> In QUIC, we are trying to merge those two rounds into one.  The problem,
> however, is that the ClientHello is one packet, and ServerHello...Finished
> can
> span multiple packets, meaning that this could be used as an amplification
> attack vector since the client's address is not yet authenticated at this
> point.
> In order to address this, the server has to limit the number of packets it
> sends
> during the first flight (i.e. ServerHello...Finished flight).  Since
> certificates make up the majority of data in that flight, making them
> smaller
> can push them under the limit and save a round-trip.
>
> Cheers,
>   Victor.
---
[ 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] review comments on draft-rescorla-tls-subcerts-01

[Benjamin Kaduk]

On 03/29/2017 10:29 AM, Subodh Iyengar wrote:
>
>
>
> > Do we want to leave the valid SignatureSchemes as all that are
> defined, or mention the Recommended column in the registry, or narrow
> things even further?  In other words, should we give some guidance for
> how to select a scheme to use?
>
> It's restricted to the ones that are supported by the client in TLS
> 1.3. I don't see TLS recommending signature algorithms to use beyond
> section 4.2.3 that "rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD
> NOT be offered.". What kind of a recommendation would you like to see.
> Would love a pull request at https://github.com/ekr/tls-subcerts/pulls
> 
>  to
> get a general idea of what you would like to see.
>
>

All I had in mind was like one sentence when talking about the
interpretation of the 'scheme' field of DelegatedCredential: "The scheme
is taken from the TLS SignatureSchemes registry [RFCTLS1.3], and schemes
recommended for use in TLS are also recommended for use in delegated
credentials."  Arguably not needed at all, but perhaps gives a bit more
clarity.

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

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Benjamin Kaduk]

On 03/31/2017 08:40 AM, Hubert Kario wrote:
> On Tuesday, 28 March 2017 08:23:33 CEST Kaduk, Ben wrote:
>> On 3/13/17, 12:30, "Sean Turner"  wrote:
>> Do we want to add some commentary about the extant SHA1 collisions when we
>> say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?
>  
> There still are non-insignificant number of Internet facing servers that 
> require SHA-1 being advertised for connection to be successful.
> SHOULD NOT is a good compromise for it.

Right.  We could note that though SHA1 is "known to be broken", some
servers currently require it, even though they ought to be moving away
from it posthaste.

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

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

[Benjamin Kaduk]

On 04/01/2017 07:13 PM, Subodh Iyengar wrote:
> Thanks for your question Brian.
>
> The motivation behind delegated credentials is to create a more
> reasonable deployment model for short lived credentials.

My apologies for being blunt, but that text reads like a solution in
search of a problem.  That is, what is expected to be achieved by having
shorter-lived credentials?  Is there a threat model for which having
them brings security advantages, or are there operational concerns, or ... ?

> []

> This led us to think of whether we could deploy short lived
> credentials with another approach. Once you can deploy short lived
> credentials we found several use cases for these:
>
> * Removing private keys from currently trusted hosts and keeping them
> in even more secure locations. In this way you could increase security
> by moving keys from places they currently exist.
> * You could make a security / performance by giving delegated
> credentials to your less trusted locations where you could make the
> tradeoff that if one of these is stolen it's valid only for a very
> short period of time.
>
> I'm not too familiar with the cloud provider to service owner
> trust model, but your idea of giving the cloud provider a delegated
> credential instead of a longer lived certificate key sounds great.
>
> Delegated credentials bounds time, however if used with other
> mechanisms you can make security protections even more robust. For
> example you could give your cloud provider a delegated credential
> bound to a certificate with a different origin. If you find that
> something bad has happened you can stop routing traffic to that origin
> as well.
>

These are also some useful analysis, but still leaves me wondering what
the actual goal to be achieved is.  Put another way, I assume that there
is some attacker with some capabilities that will be stymied in some way
by the deployment of delegated credentials, as compared to having real
certificates/keys deployed to the machines that are going to get
delegated credentials on them.  But what benefit, and what are the
attacker's capabilities?

There is also an alternate world in which the TLS terminators should not
have certificates/keys on them but it is okay to give them delegated
credentials.  Here, one benefit is clear: performance.  But the attacker
capabilities against which this is supposed to be useful/acceptable
remain unclear.

Can you share some more thoughts about which of these two pictures you
have in mind, and what the attacker capabilities are in that scenario?

Thanks,

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

Re: [TLS] PRs for review

[Sean Turner]

> On Apr 4, 2017, at 13:09, Eric Rescorla  wrote:
> 
> and removing extensions which no longer work from the table.

I’ll make sure to add these to the “orphaned” list of registries in 
draft-ietf-tls-iana-registry-updates.

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

Re: [TLS] PRs for review

[Eric Rescorla]

On Tue, Apr 4, 2017 at 10:29 AM, Ilari Liusvaara 
wrote:

> On Tue, Apr 04, 2017 at 10:09:16AM -0700, Eric Rescorla wrote:
> >
> > * Explicitly describing how RFC 7250 Raw Public Keys work with TLS
> > 1.3 and removing extensions which no longer work from the table.
> > https://github.com/tlswg/tls13-spec/pull/932
>
> The things that seem missing:
>
> - Specifying that OpenPGP type MUST NOT be used in TLS 1.3 (client
>   MAY advertise if it supports TLS 1.2, server MUST NOT select).


Thanks. Good catch.



> - Correcting client_certificate_type to be CR,CERT (and not CH,EE).
>   This becomes practicularly relevant if any new certificate type
>   is ever defined.
>

Thanks!

-Ekr


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

Re: [TLS] PRs for review

[Ilari Liusvaara]

On Tue, Apr 04, 2017 at 10:09:16AM -0700, Eric Rescorla wrote:
> 
> * Explicitly describing how RFC 7250 Raw Public Keys work with TLS
> 1.3 and removing extensions which no longer work from the table.
> https://github.com/tlswg/tls13-spec/pull/932

The things that seem missing:

- Specifying that OpenPGP type MUST NOT be used in TLS 1.3 (client
  MAY advertise if it supports TLS 1.2, server MUST NOT select).
- Correcting client_certificate_type to be CR,CERT (and not CH,EE).
  This becomes practicularly relevant if any new certificate type
  is ever defined.


-Ilari

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

[TLS] PRs for review

[Eric Rescorla]

Hi folks,

As discussed in the meeting, and with an assist from MT, I've prepared
two small PRs:

* An extension by the client to negotiated post-handshake client auth:
https://github.com/tlswg/tls13-spec/pull/933

* Explicitly describing how RFC 7250 Raw Public Keys work with TLS
1.3 and removing extensions which no longer work from the table.
https://github.com/tlswg/tls13-spec/pull/932

Target merge date: Thursday.

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

Re: [TLS] Support of integrity only cipher suites in TLS 1.3

[Hanno Böck]

On Mon, 3 Apr 2017 16:17:45 +
"Fries, Steffen"  wrote:

> The reason I'm asking is that in industrial communication it is often
> sufficient to have source authentication and message integrity while
> probes on the network are still able to monitor the traffic for
> certain properties or verify allowed exchanges. An example is ICCP
> for inter control center communication. The two control center are
> connected via an IPSec tunnel terminated in the DMZ. The desire is to
> have the TLS tunnel end-to-end to allow for source authentication and
> also for message integrity, while doing traffic inspection in the
> DMZ. There exist other scenarios, with a similar requirement.

Adding such a mode would add additional complexity that might lead to
vulnerabiltiies, e.g. implementations that can be tricked into using a
nonencrypted mode.

It's been a trend in the tls working group to
a) reduce complexity when possible.
b) not try to accomodate obscure use cases that aren't relevant for the
majority of TLS use cases.

Thus I assume a null cipher won't find support here. If you want to
have traffic inspection with TLS imho the right way is to support that
at the end points (let alone any arguments why you're doing traffic
inspection in the first place and whether those reasons are good ones).
If you don't like that then TLS may be not the right protocol for your
use case.

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

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

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

Re: [TLS] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt

[Tommy Pauly]

I've gone through my review of the draft as well, and I think this version 
looks good!

Thanks,
Tommy

> On Apr 3, 2017, at 11:25 AM, David Schinazi  wrote:
> 
> Thanks for the update!
> 
> I've reviewed -04 and I think the draft is ready to move forward.
> 
> Regards,
> David Schinazi
> 
> 
>> On Mar 28, 2017, at 15:43, Daniel Migault > > wrote:
>> 
>> Hi, 
>> 
>> Thank you Jim for the update. Here is the version resulting from the 
>> discussion we had during the WG meeting yesterday.  Please review the 
>> document and provide your feed backs by April 4 so we can move the draft to 
>> the IESG. 
>> 
>> Yours, 
>> Daniel
>> 
>> -Original Message-
>> From: Curdle [mailto:curdle-boun...@ietf.org] On Behalf Of Jim Schaad
>> Sent: Tuesday, March 28, 2017 4:40 PM
>> To: cur...@ietf.org
>> Subject: [Curdle] FW: New Version Notification for 
>> draft-ietf-curdle-pkix-04.txt
>> 
>> Here is the promised updated draft.
>> 
>> Changes:
>> 1.  Fixed an example that David Benjamin found was wrong.  (Incorrect sign 
>> bit in public key.) 2.  Remove all of the pre-hash text except to note that 
>> it does exist.
>> 3.  No changes to the OID arc being used despite the agreement during the 
>> meeting.  After the meeting, Russ, the chairs and I had a short talk and 
>> decided that this did not need to occur.  The problem was only with getting 
>> new values assigned not with the current values which were already assigned.
>> 
>> That should be the final issues in the draft
>> 
>> Jim
>> 
>> 
>>> -Original Message-
>>> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>>> Sent: Tuesday, March 28, 2017 4:31 PM
>>> To: Jim Schaad ; Simon Josefsson 
>>> 
>>> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt
>>> 
>>> 
>>> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been 
>>> successfully submitted by Jim Schaad and posted to the IETF repository.
>>> 
>>> Name:   draft-ietf-curdle-pkix
>>> Revision:   04
>>> Title:  Algorithm Identifiers for Ed25519, Ed448, X25519 and 
>>> X448 for
>>> use in the Internet X.509 Public Key Infrastructure
>>> Document date:  2017-03-28
>>> Group:  curdle
>>> Pages:  15
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt
>>> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
>>> Htmlized:   https://tools.ietf.org/html/draft-ietf-curdle-pkix-04
>>> Htmlized:   
>>> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04
>>> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04
>>> 
>>> Abstract:
>>>  This document specifies algorithm identifiers and ASN.1 encoding
>>>  formats for Elliptic Curve constructs using the Curve25519 and
>>>  Curve448 curves.  The signature algorithms covered are Ed25519 and
>>>  Ed448.  The key agreement algorithm covered are X25519 and X448.  The
>>>  encoding for Public Key, Private Key and EdDSA digital signature
>>>  structures is provided.
>>> 
>>> 
>>> 
>>> 
>>> 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
>> 
>> 
>> ___
>> Curdle mailing list
>> cur...@ietf.org
>> https://www.ietf.org/mailman/listinfo/curdle
>> 
>> ___
>> Curdle mailing list
>> cur...@ietf.org 
>> https://www.ietf.org/mailman/listinfo/curdle 
>> 
> 
> ___
> Curdle mailing list
> cur...@ietf.org 
> https://www.ietf.org/mailman/listinfo/curdle 
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Support of integrity only cipher suites in TLS 1.3

[Fries, Steffen]

Hello Harlan,

thank you for the information. I will go back to the discussion and read it to 
get a better understanding about the reasoning. I had a peek into 3 or 4 emails 
and there were centered around the deprecation of RSA encrypted  key exchange. 
This is different from what I had in mind. You mentioned null-cipher, which 
would be the choice I would see. Yes, maybe it is too late to bring this issue 
into the discussion. Nevertheless, as there is a need for network monitoring it 
would be easier to have the monitoring on an integrity protected connection, 
while the traffic is additionally encrypted when crossing public networks. This 
is  the intended approach for the scenario I described for Inter Control Center 
communication.  This would allow for non-intrusive monitoring instead of a 
distinct termination point, which breaks end-to-end integrity (if not provided 
on higher layers) also influences the end-to-end performance. I see that the 
integrity only is a problem for certain other scenarios, 
 but having the flexibility in the protocol would allow to make a decision 
about the preferred cipher suites for a specific use case based on a security 
policy. 

Best regards
Steffen

-Original Message-
From: Harlan Lieberman-Berg [mailto:hlieber...@setec.io] 
Sent: Dienstag, 4. April 2017 07:10
To: Fries, Steffen (CT RDA ITS); TLS WG
Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3

"Fries, Steffen"  writes:
> The reason I'm asking is that in industrial communication it is often 
> sufficient to have source authentication and message integrity while 
> probes on the network are still able to monitor the traffic for 
> certain properties or verify allowed exchanges.

Hello Steffen,

We've had a couple of discussions about this on the mailing list before.
(See especially the "Industry Concerns about TLS 1.3" email thread starting 
with 
dm5pr11mb1419b782d2bef0e0a35e420df4...@dm5pr11mb1419.namprd11.prod.outlook.com).
At this point, I don't think there's much of an appetite to be adding support 
for null-encryption cipher suites into TLS 1.3.

In a quick summary of the 100+ message thread, the impression I got from the 
conversation was that the WG feels there's too much foot-gun potential from 
null cipher suites and that the risk was too high and the concerns brought up 
too late.

Sincerely,
--
Harlan Lieberman-Berg
~hlieberman

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

Re: [TLS] Remove deprecated fields in TLS 1.3

[Arnaud Venturi]

This was infact the idea, even I thought of the gain much more in terms
of removing something useless than in gaining a few bytes.

Anyway, thanks for your opinions and your time !


-- 
Arnaud

On 04/04/2017 03:10 AM, Eric Rescorla wrote:
> I agree with David. This seems like a low value change
>
> On Mon, Apr 3, 2017 at 9:36 AM, David Benjamin  > wrote:
>
> On Mon, Apr 3, 2017 at 12:29 AM Benjamin Kaduk  > wrote:
>
> On 04/02/2017 03:33 AM, Arnaud Venturi wrote:
>> I could not think of any security or interoperability issue with this
>> proposal, the only drawback I can see being the slight complexity 
>> added
>> in ClientHello parsing.
>
> The ClientHello message needs to be interpreted in the same
> way by TLS servers running all versions of TLS.  A TLS 1.0
> server would not know to use the changed interpretation of the
> fields and would fail to negotiate a connection.  Basically,
> no change in the format is possible while preserving the
> backwards and forwards compatibility of version negotiation.
>
>
> I believe the idea is that, if you support TLS 1.2 and below, you
> send a 1.2-compatible ClientHello. If you don't, then you send the
> proposed ClientHello. Servers would be required to support both
> formats.
>
> This change would save us all of 3 bytes in the ClientHello, so my
> feeling is this isn't worth the trouble of having two formats and
> all the trouble that entails. (Servers having to parse both
> formats, code in servers that won't be exercised for years,
> clients worrying about whether servers implemented that, etc.)
>
> David
>
> ___
> 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