Re: [TLS] Proposed Change to Certificate message (#654)

[Martin Thomson]

On 6 October 2016 at 06:40, Ilari Liusvaara  wrote:
> The only issue that comes to mind is where extensions that are specific
> to the certificate chain instead to the certificate go.

Let's keep it simple.  I would put these on the EE cert.  That is the
entry that has the most chance of being looked at.

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

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

Florian--Anecdotally, I have heard Microsoft and F5 did code upgrades a few 
years back that moved Diffie Hellman to the top cipher suite priorities which 
broke security and fraud monitoring, APM reporting, and sniffer troubleshooting 
for a financial services client and at least one other organization in a 
different industry.  

The solution, at the time, was to put the PFS options (choices we will no 
longer in 1.3) at the bottom of the priority list.  I don't know how much of 
this was communicated back to the vendors at the time.  

In retrospect, this could have been seen as the canary in the coalmine... but 
here we are now at least.  

- Andrew 


-Original Message-
From: Florian Weimer [mailto:f...@deneb.enyo.de] 
Sent: Wednesday, October 5, 2016 2:17 PM
To: BITS Security 
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

* BITS Security:

> Deprecation of the RSA key exchange in TLS 1.3 will cause significant 
> problems for financial institutions, almost all of whom are running 
> TLS internally and have significant, security-critical investments in 
> out-of-band TLS decryption.
>  
> Like many enterprises, financial institutions depend upon the ability 
> to decrypt TLS traffic to implement data loss protection, intrusion 
> detection and prevention, malware detection, packet capture and 
> analysis, and DDoS mitigation.

We should have already seen this with changing defaults in crypto libraries as 
part of security updates.  That should have broken passive monitoring 
infrastructure, too.

Maybe some of the vendors can shed some light on this problem and tell us if 
they ever have received pushback for rolling out ECDHE-by-default.  (I know 
that some products have few capabilities for centralized policy management, 
which is why defaults matter a lot
there.)

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

Re: [TLS] Proposed Change to Certificate message (#654)

[Sean Turner]

I’m not seeing objections to this PR so please let us know by Friday (7 
October) whether you see any issues with what’s been proposed. 

spt

> On Sep 22, 2016, at 20:42, Nick Sullivan  wrote:
> 
> PR: https://github.com/tlswg/tls13-spec/pull/654
> 
> Hello,
> 
> I'd like to propose a small to the Certificate message format to allow for 
> future extensibility of the protocol.
> 
> This change adds a set of extensions to the Certificate message. With this 
> change, the Certificate message can now hold all extension messages that are 
> certificate-specific (rather than connection-specific). This change also 
> resolves the anomaly of OCSP messages appearing before certificates in the 
> handshake.
> 
> Reasoning: 
> I've come to the conclusion that the current mechanism in TLS 1.3 for OCSP 
> and SCT is lacking forsight. OCSP and SCT are per-certificate metadata, not 
> per-connection metadata. By putting these responses in the 
> EncryptedExtensions, you limit these extensions to being shown once per 
> connection. This restricts future protocol extensions from using multiple 
> Certificate messages to support multiple certificates on the same connection. 
> An example of this is the post-handshake authentication proposal 
> (https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00), 
> which currently requires a modified post-handshake Certificate message. This 
> proposed change would simplify the post-handshake auth proposal significantly 
> and generally make more sense as more certificate-specific extensions are 
> created.
> 
> Nick
> ___
> 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] Industry Concerns about TLS 1.3

[Florian Weimer]

* BITS Security:

> Deprecation of the RSA key exchange in TLS 1.3 will cause significant
> problems for financial institutions, almost all of whom are running
> TLS internally and have significant, security-critical investments in
> out-of-band TLS decryption.
>  
> Like many enterprises, financial institutions depend upon the ability
> to decrypt TLS traffic to implement data loss protection, intrusion
> detection and prevention, malware detection, packet capture and
> analysis, and DDoS mitigation.

We should have already seen this with changing defaults in crypto
libraries as part of security updates.  That should have broken
passive monitoring infrastructure, too.

Maybe some of the vendors can shed some light on this problem and tell
us if they ever have received pushback for rolling out
ECDHE-by-default.  (I know that some products have few capabilities
for centralized policy management, which is why defaults matter a lot
there.)

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

Re: [TLS] debugging tools [was: Industry Concerns about TLS 1.3]

[Florian Weimer]

* Hubert Kario:

> those secret keys are on the client machines and they will stay on client 
> machines
>
> making it hard to extract master key from process memory is just security 
> through obscurity, not something that will stop a determined attacker

I think extracting the master key is probably not what you want to do
anyway, just adding Systemtap probes to get cleartext copies
(preferably along with connection detail information) should be
sufficient.

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

Re: [TLS] Exporter output size

[Andrei Popov]

Also, it would be difficult to remove existing functionality, and get the 
callers to update. E.g. deprecation of TLS_UNIQUE is not going easy for 
apps/protocols.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, October 4, 2016 8:49 PM
To: Martin Thomson 
Cc: tls@ietf.org
Subject: Re: [TLS] Exporter output size

On Tue, Oct 4, 2016 at 6:32 PM, Martin Thomson 
> wrote:
After a bunch of discussion about the consequences of having
insufficient output from various stages of the hash functions... Could
we make an amendment to TLS 1.3 to force the output size of the
exporter to be the size of the underlying hash output?  That is,
remove the length parameter.  Or is a change to the API too
disruptive?

I don't think this is a good idea. There are plenty of reasons why you would 
want to
export values != hash_len (e.g., cryptographic keys). Putting a restriction 
here just
pushes the problem around

-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] [Editorial Errata Reported] RFC6066 (4817)

[Sean Turner]

Looks like this one can safely be accepted.

spt

> On Oct 03, 2016, at 13:47, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC6066,
> "Transport Layer Security (TLS) Extensions: Extension Definitions".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6066=4817
> 
> --
> Type: Editorial
> Reported by: ResponderIDs type is not defined anywhere. 
> 
> 
> Section: 8
> 
> Original Text
> -
> In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
> responders that the client trusts. 
> 
> Corrected Text
> --
> In the OCSPStatusRequest, the "ResponderID" provides a list of OCSP
> responders that the client trusts.
> 
> or clearer 
> 
> In OCSPStatusRequest, the "responder_id_list" provides a list of
> "ResponderID", OCSP responders that the client trusts.
> 
> Notes
> -
> ResponderIDs is not defined anywhere within the document.
> 
> Quote of this section in RFC6961 section 2.2 (p.4) seem to have fixed this.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC6066 (draft-ietf-tls-rfc4366-bis-12)
> --
> Title   : Transport Layer Security (TLS) Extensions: Extension 
> Definitions
> Publication Date: January 2011
> Author(s)   : D. Eastlake 3rd
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 

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

Re: [TLS] Prospects of draft-jay-tls-psk-identity-extension

[Jayaraghavendran k]

Hi Andi,

Thanks for your interest in the draft.

Yes. We will be definitely reviving the draft.

Just held up with some work. We should be able to upload the modified draft
in a week or two.

Regards,
Jay

On Wednesday 5 October 2016, Raja ashok  wrote:

> Hi Andreas,
>
>
>
> Last week received some comments from Ilari and David. We are working on
> the next version of this draft. We will upload it soon.
>
>
>
> Regards,
>
> Ashok
> --
>
> Raja Ashok VK
> 华为技术有限公司 Huawei Technologies Co., Ltd.
> [image: Company_logo]
>
> Phone:
> Fax:
> Mobile:
> Email:
> Huawei Technologies Co., Ltd.
> Bangalore, India
>
> http://www.huawei.com
> --
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
> *From:* Andreas Walz [mailto:andreas.w...@hs-offenburg.de
> ]
> *Sent:* 05 October 2016 17:45
> *To:* jayaraghavendra...@huawei.com
> ; Raja
> ashok
> *Subject:* Prospects of draft-jay-tls-psk-identity-extension
>
>
>
> Dear authors of draft-jay-tls-psk-identity-extension,
>
> I was wondering whether there is any plan to revive your draft on the
> TLS-PSK-identity-extension. I very much liked the idea and we also have a
> use case where it might be very helpful.
>
> Thanks for your answer.
>
> With best regards,
> Andi Walz
>
> ___
>
> Andreas Walz
> Research Engineer
> Institute of reliable Embedded Systems and Communication Electronics
> (ivESK)
> Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS1.3 + PSK with multiple identities

[Hannes Tschofenig]

Hi Andreas,

I am not sure that people ignore the redundant length fields on purpose.
I think that the strange syntax that TLS uses invites these types of
mistakes and I had run into those myself as well.

Ciao
Hannes


On 10/05/2016 02:03 PM, Andreas Walz wrote:
> Hi Olivier,
> 
> your findings are interesting as they pretty much match with what we
> have found when studying TLS implementations for embedded systems. In
> many implementations there is a tendency to ignore redundant length
> fields (or at least to not enforce consistency). There has been some
> discussion about this on the list, see thread "Suspicious behaviour of
> TLS server implementations".
> 
> We are currently refining our study and in the process of writing a
> paper. I hopefully can give more details on results soon.
> 
> Cheers,
> Andi
> 
> ___
> 
> Andreas Walz
> Research Engineer
> Institute of reliable Embedded Systems and Communication Electronics (ivESK)
> Offenburg University of Applied Sciences, 77652 Offenburg, Germany
> 
> 
 Olivier Levillain  10/04/16 5:51 AM >>>
> Hi list,
> 
> I have been working in the labs at ANSSI (the French Network and
> Information System Agency) for several years and I just defended my PhD
> thesis on the TLS ecosystem (documents are available at
> http://paperstreet.picty.org/~yeye/2016/phdthesis-Levillain16/).
> 
>>> On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote:
 On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
> More compact and makes the option where server sends some bad option
> more clear.
>>> Note that if we really want to be more compact, we might also observe
>>> that there is a redundant length field in the extension as sent by the
>>> client:
>>> case client_hello:
>>> PskIdentity identities<6..2^16-1>;
>>>
>>> Each extension has at least four bytes on the wire — the extension_type
>>> itself, and the length field of the extension_data in a uint16.
>>>
>>> If I am interpreting the spec correctly, then the data for the
>>> PreSharedKeyIdentity extension in the ClientHello then follows that
>>> with another uint16, which is *always* a value two lower than the one
>>> which immediately precedes it.
>>>
>>> e.g.
>>>
>>> 0x00 0x29 // ExtensionType extension_type == 41
>>> 0x00 0x14 // opaque extension_data<0..2^16-1>
>>> // This length field is entirely redundant:
>>> 0x00 0x12 // PskIdentity identities<6..2^16-1>
>>> // First identity:
>>> 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode
>>> 0x00 0x04 // opaque identity<0..2^16-1>
>>> 0x44 0x61 0x76 0x65 // "Dave"
>>> // Second identity:
>>> 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode
>>> 0x00 0x06 // opaque identity<0..2^16-1)>
>>> 0x43 0x68 0x6c 0x6f 0xc3 0xab // "Chloë"
>>>
>>> Do we care that the '0x00 0x12' bytes on my third line above are
>>> entirely redundant on the wire? Or have I interpreted it wrong?
>>>
>> Not enough to fix it, this is just the way TLS rolls.
> 
> Sorry if I am a little late to the party, but I noticed that even if
> this is generally true, I believe it has not always been enforced in TLS
> extensions.
> 
> In 2006, the IETF standardised the session tickets extension, allowing
> for session resumption without server-side state (RFC 4507).
> However, no TLS stack implements the specification correctly: even
> if the specification described the _content_ of the extension as
> a variable-length object (that is an opaque object prefixed by its
> length), every implementation ignores this second (useless) length
> field. The RFC 5077, published in 2008, fixes the gap
> between the specification and the implementations.
> 
> RFC 4507 :
> 
> The SessionTicket extension has been assigned
> the number 35. The format of the SessionTicket
> extension is given at the end of this section.
> 
> struct {
> opaque ticket<0..2^16-1>;
> } SessionTicket;
> 
> 00 23 Ticket Extension type 35
> 01 02 Length of extension contents
> 01 00 Length of ticket
> FF FF .. .. Actual ticket
> 
> RFC 5077
> 
> The SessionTicket extension has been assigned
> the number 35. The extension_data field of
> SessionTicket extension contains the ticket.
> 
> 00 23 Ticket Extension type 35
> 01 00 Length of extension contents (ticket)
> FF FF .. .. Actual ticket
> 
> 
> Best regards,
> olivier
> 
> ___
> 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
> 



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

Re: [TLS] Prospects of draft-jay-tls-psk-identity-extension

[Raja ashok]

Hi Andreas,

Last week received some comments from Ilari and David. We are working on the 
next version of this draft. We will upload it soon.

Regards,
Ashok

Raja Ashok VK
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
Huawei Technologies Co., Ltd.
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!
From: Andreas Walz [mailto:andreas.w...@hs-offenburg.de]
Sent: 05 October 2016 17:45
To: jayaraghavendra...@huawei.com; Raja ashok
Subject: Prospects of draft-jay-tls-psk-identity-extension

Dear authors of draft-jay-tls-psk-identity-extension,

I was wondering whether there is any plan to revive your draft on the 
TLS-PSK-identity-extension. I very much liked the idea and we also have a use 
case where it might be very helpful.

Thanks for your answer.

With best regards,
Andi Walz

___

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS1.3 + PSK with multiple identities

[Andreas Walz]

Hi Olivier,

your findings are interesting as they pretty much match with what we
have found when studying TLS implementations for embedded systems. In
many implementations there is a tendency to ignore redundant length
fields (or at least to not enforce consistency). There has been some
discussion about this on the list, see thread "Suspicious behaviour of
TLS server implementations".

We are currently refining our study and in the process of writing a
paper. I hopefully can give more details on results soon.

Cheers,
Andi 

___

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics
(ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany


>>> Olivier Levillain  10/04/16 5:51 AM
>>>
Hi list,

I have been working in the labs at ANSSI (the French Network and
Information System Agency) for several years and I just defended my PhD
thesis on the TLS ecosystem (documents are available at
http://paperstreet.picty.org/~yeye/2016/phdthesis-Levillain16/).

>> On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote:
>>> On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
 More compact and makes the option where server sends some bad
option
 more clear.
>> Note that if we really want to be more compact, we might also observe
>> that there is a redundant length field in the extension as sent by
the
>> client:
>>case client_hello:
>>PskIdentity identities<6..2^16-1>;
>>
>> Each extension has at least four bytes on the wire — the
extension_type
>> itself, and the length field of the extension_data in a uint16.
>>
>> If I am interpreting the spec correctly, then the data for the
>> PreSharedKeyIdentity extension in the ClientHello then follows that
>> with another uint16, which is *always* a value two lower than the one
>> which immediately precedes it.
>>
>> e.g.
>>
>>   0x00 0x29  // ExtensionType extension_type == 41
>>   0x00 0x14  // opaque extension_data<0..2^16-1>
>> // This length field is entirely redundant:
>> 0x00 0x12  // PskIdentity identities<6..2^16-1>
>>  // First identity:
>>   0x00 0x00  // PskKeyExchangeMode, PskAuthenticationMode
>>   0x00 0x04  // opaque identity<0..2^16-1>
>> 0x44 0x61 0x76 0x65 // "Dave"
>>  // Second identity:
>>   0x00 0x00  // PskKeyExchangeMode, PskAuthenticationMode
>>   0x00 0x06  // opaque identity<0..2^16-1)>
>> 0x43 0x68 0x6c 0x6f 0xc3 0xab // "Chloë"
>>
>> Do we care that the '0x00 0x12' bytes on my third line above are
>> entirely redundant on the wire? Or have I interpreted it wrong?
>>
> Not enough to fix it, this is just the way TLS rolls.

Sorry if I am a little late to the party, but I noticed that even if
this is generally true, I believe it has not always been enforced in TLS
extensions.

In 2006, the IETF standardised the session tickets extension, allowing
for session resumption without server-side state (RFC 4507).
However, no TLS stack implements the specification correctly: even
if the specification described the _content_ of the extension as
a variable-length object (that is an opaque object prefixed by its
length), every implementation ignores this second (useless) length
field.  The RFC 5077, published in 2008, fixes the gap
between the specification and the implementations.

RFC 4507 :

The SessionTicket extension has been assigned
the number 35.  The format of the SessionTicket
extension is given at the end of this section.

  struct {
opaque ticket<0..2^16-1>;
  } SessionTicket;

00 23  Ticket Extension type 35
01 02  Length of extension contents
01 00  Length of ticket
FF FF .. ..Actual ticket

RFC 5077

The SessionTicket extension has been assigned
the number 35.  The extension_data field of
SessionTicket extension contains the ticket.

00 23FF FF .. ..Actual ticket


Best regards,
olivier

___
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