Re: [TLS] Truncated HMAC: what to do with the MAC key?

[Dave Garrett]

On Saturday, July 08, 2017 12:38:18 am Peter Gutmann wrote:
> Andreas Walz  writes:
> >different TLS implementations do not seem to agree on how to implement
> >truncated HMAC
> 
> It also says something about the status of this capability if three of the
> four known implementations can't interoperate.  If it's taken fourteen years
> (RFC 3546 was 2003) for someone to notice that the implementations don't
> work/interoperate then maybe the capability should be marked as deprecated or
> obsolete or unused or something.

In progress; the Truncated HMAC TLS extension is prohibited in implementations 
that support TLS 1.3+ as of the current draft.

https://tools.ietf.org/html/draft-ietf-tls-tls13-21#page-127


Dave

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

Re: [TLS] Truncated HMAC: what to do with the MAC key?

[Peter Gutmann]

Andreas Walz  writes:

>different TLS implementations do not seem to agree on how to implement
>truncated HMAC

It also says something about the status of this capability if three of the
four known implementations can't interoperate.  If it's taken fourteen years
(RFC 3546 was 2003) for someone to notice that the implementations don't
work/interoperate then maybe the capability should be marked as deprecated or
obsolete or unused or something.

Just out of interest Andreas, why were you checking this?  In other words how
did it get noticed?

Peter.

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Timothy Jackson]

As an earlier poster asked, what advantage does this approach have over 
TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am 
familiar is able to terminate at TLS connection, inspect/copy/filter, and then 
encrypt on a new TLS sessions.

For high performance customers, the SSL accelerators can be sandwiched around 
the filter so all the crypto is done in hardware.

The ways to prevent TLS inspection are cert pinning and client cert auth. If 
this is only within one's data center, then those features can be disabled if 
necessary, no?

What use case am I missing that can't be achieved better by other means than 
static keys?

Thanks,

Tim

Sent from Email+ secured by MobileIron



From: "Ackermann, Michael" >
Date: Friday, July 7, 2017 at 7:06:55 PM
To: "Watson Ladd" >, 
"Christian Huitema" >
Cc: "tls@ietf.org" >
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Converting all session traffic to clear text is not a viable alternative for 
ANY enterprises or industries that I am aware of.  In particular those in 
financial sectors.
Security policies, legislation and in many cases just good practice would not 
allow for this.
We are compelled by these factors to encrypt all data in motion.But we 
still need to manage our applications, networks, servers and clients.Hence 
the need to decrypt traffic as outlined in this draft.

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Watson Ladd
Sent: Friday, July 7, 2017 9:40 PM
To: Christian Huitema 
Cc: tls@ietf.org
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema  wrote:
>
>
> On 7/7/2017 2:54 PM, Russ Housley wrote:
>> Stephen:
>> ...
>>> And also: I'm sorry to have to say it, but I consider that attempted
>>> weasel wording around the clear intent of 2804. The clear and real
>>> effect if your wiretapping proposal were standardised by the IETF
>>> would be that we'd be standardising ways in which TLS servers can be
>>> compelled into breaking TLS - it'd be a standard wiretapping API
>>> that'd be insisted upon in many places and would mean significantly
>>> degrading TLS (only *the* most important security protocol we
>>> maintain) and the community's perception of the IETF. It's all a
>>> shockingly bad idea.
>> I clearly disagree.  Otherwise, I would not have put any work into the draft.
> Russ,
>
> What are the specific mechanisms that would allow this technique to be
> used where you intend it, i.e. within a data center, and not where
> Stephen fears it would be, i.e., on the broad Internet? For example,
> what mechanism could a client use to guarantee that this sort of
> "static DH" intercept could NOT be used against them?

The server can send the plaintext to whomever it likes.

This is the solution enterprises can use today. Nothing can stop that from 
happening. So I don't see why static DH is a) so essentially necessary and b) 
so controversial.

>From a technical point I prefer using DH shares derived from
ServerRandom as this avoids certain bugs I've been known to exploit from time 
to time.

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



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

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


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.

 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.

___
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] draft-green-tls-static-dh-in-tls13-01

[Ackermann, Michael]

Converting all session traffic to clear text is not a viable alternative for 
ANY enterprises or industries that I am aware of.  In particular those in 
financial sectors.  
Security policies, legislation and in many cases just good practice would not 
allow for this. 
We are compelled by these factors to encrypt all data in motion.But we 
still need to manage our applications, networks, servers and clients.Hence 
the need to decrypt traffic as outlined in this draft.   

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Watson Ladd
Sent: Friday, July 7, 2017 9:40 PM
To: Christian Huitema 
Cc: tls@ietf.org
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema  wrote:
>
>
> On 7/7/2017 2:54 PM, Russ Housley wrote:
>> Stephen:
>> ...
>>> And also: I'm sorry to have to say it, but I consider that attempted 
>>> weasel wording around the clear intent of 2804. The clear and real 
>>> effect if your wiretapping proposal were standardised by the IETF 
>>> would be that we'd be standardising ways in which TLS servers can be 
>>> compelled into breaking TLS - it'd be a standard wiretapping API 
>>> that'd be insisted upon in many places and would mean significantly 
>>> degrading TLS (only *the* most important security protocol we 
>>> maintain) and the community's perception of the IETF. It's all a 
>>> shockingly bad idea.
>> I clearly disagree.  Otherwise, I would not have put any work into the draft.
> Russ,
>
> What are the specific mechanisms that would allow this technique to be 
> used where you intend it, i.e. within a data center, and not where 
> Stephen fears it would be, i.e., on the broad Internet? For example, 
> what mechanism could a client use to guarantee that this sort of 
> "static DH" intercept could NOT be used against them?

The server can send the plaintext to whomever it likes.

This is the solution enterprises can use today. Nothing can stop that from 
happening. So I don't see why static DH is a) so essentially necessary and b) 
so controversial.

>From a technical point I prefer using DH shares derived from
ServerRandom as this avoids certain bugs I've been known to exploit from time 
to time.

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



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

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


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Watson Ladd]

On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema  wrote:
>
>
> On 7/7/2017 2:54 PM, Russ Housley wrote:
>> Stephen:
>> ...
>>> And also: I'm sorry to have to say it, but I consider that
>>> attempted weasel wording around the clear intent of 2804. The
>>> clear and real effect if your wiretapping proposal were standardised
>>> by the IETF would be that we'd be standardising ways in which
>>> TLS servers can be compelled into breaking TLS - it'd be a standard
>>> wiretapping API that'd be insisted upon in many places and would
>>> mean significantly degrading TLS (only *the* most important
>>> security protocol we maintain) and the community's perception
>>> of the IETF. It's all a shockingly bad idea.
>> I clearly disagree.  Otherwise, I would not have put any work into the draft.
> Russ,
>
> What are the specific mechanisms that would allow this technique to be
> used where you
> intend it, i.e. within a data center, and not where Stephen fears it
> would be, i.e., on
> the broad Internet? For example, what mechanism could a client use to
> guarantee
> that this sort of "static DH" intercept could NOT be used against them?

The server can send the plaintext to whomever it likes.

This is the solution enterprises can use today. Nothing can stop that
from happening. So I don't see why static DH is a) so essentially
necessary and b) so controversial.

>From a technical point I prefer using DH shares derived from
ServerRandom as this avoids certain bugs I've been known to exploit
from time to time.

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



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Christian Huitema]

On 7/7/2017 2:54 PM, Russ Housley wrote:
> Stephen:
> ...
>> And also: I'm sorry to have to say it, but I consider that
>> attempted weasel wording around the clear intent of 2804. The
>> clear and real effect if your wiretapping proposal were standardised
>> by the IETF would be that we'd be standardising ways in which
>> TLS servers can be compelled into breaking TLS - it'd be a standard
>> wiretapping API that'd be insisted upon in many places and would
>> mean significantly degrading TLS (only *the* most important
>> security protocol we maintain) and the community's perception
>> of the IETF. It's all a shockingly bad idea.
> I clearly disagree.  Otherwise, I would not have put any work into the draft.
Russ,

What are the specific mechanisms that would allow this technique to be
used where you
intend it, i.e. within a data center, and not where Stephen fears it
would be, i.e., on
the broad Internet? For example, what mechanism could a client use to
guarantee
that this sort of "static DH" intercept could NOT be used against them?

-- 
Christian Huitema


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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Shumon Huque]

On Fri, Jul 7, 2017 at 7:05 PM, Viktor Dukhovni 
wrote:

>
> Once the client obtains a validated TLSA RRset for the service
> endpoint, it may (up to the TTLs of the provided records, validated
> to conform to the max ttl of the RRSIGs and not exceed the RRSIG
> expiration) simply not omit the extension in subsequent requests,
> and validate the server certificate per the cached TLSA RRs.
>

( assumed typo: s/not omit/omit/ )

This is quite a reasonable and simple optimization, and I think we should
document it in the draft. It may often be short circuited by TLS session
resumption, but it's so simple that it's probably worth doing.

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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Viktor Dukhovni]

On Fri, Jul 07, 2017 at 11:06:45AM -0400, Shumon Huque wrote:

> We've had this discussion numerous times over the life of this draft, and
> there was never any consensus for the client caching or not. An
> implementation could have the client cache the data, and only validate the
> portion of the chain that it needs to, without any wire protocol change.
> I'm okay with mentioning that possibility.
> 
> IMO, the real gain from having the client cache data, is that the server
> could then potentially send a much smaller DNSSEC chain. But this requires
> the client to signal what they've cached, and makes the protocol more
> complex. I would prefer to leave that to a future revision of the spec,
> after we've gained some operational experience with the current one.

Once the client obtains a validated TLSA RRset for the service
endpoint, it may (up to the TTLs of the provided records, validated
to conform to the max ttl of the RRSIGs and not exceed the RRSIG
expiration) simply not omit the extension in subsequent requests,
and validate the server certificate per the cached TLSA RRs.

This requires no complex protocoll machinery, just caching of the
validated TLSA RRset.  This is essentially the same as obtaining
validated TLSA records via DNS, where they are cached in the client's
resolver up to the relevant TTL.  Only here the client can choose
to cap the TTL to a lower value, and ask the server again sooner.
The client cannot as easily cap the maximum cache TTL of its
iterative resolver.

So, indeed I would not try to engineer partial caching, with the
client soliciting a portion of the complete set of validation
RRsets.  However, simple caching of the given server's validated
TLSA RRset for repeat visits is not unreasonable, if the client
implementation chooses to do that.

Servers may wish to cap their TLSA record TTLs knowing that they
may be cached by clients.  Clients might also save some CPU by
not revalidating previously validated RRsets, but they will not
avoid the overhead of receiving the full set of records from
the server.

-- 
Viktor.

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Russ Housley]

Stephen:


> You didn't refer to 2804 and the standards track. As an author
> do you really think this can be on the standards track and yet
> not obsolete 2804?
 
 Yes.
>>> 
>>> We disagree.
>>> 
 Section 3 of RFC 2804 offers pretty clear definition of 
 wiretapping, and that is not what is going on here.  In this 
 situation, all of the parties are part of the same organization, 
 under common key management.
>>> 
>>> That is one possible deployment. There is nothing in this proposal
>>> that limits it's use to that.
>>> 
 The server must explicitly accept and use the centrally managed
 (EC)DH key, so that party is completely aware and, in fact,
 enabling the other parties to decrypt the traffic.
>>> 
>>> Yes, and the server could equally be compelled to do that, in which
>>> case this technology would clearly be a standard form of
>>> wiretapping.
>>> 
>>> Claiming that is not the case would be incredible so I have no idea
>>> how you maintain that this isn't in conflict with 2804.
>> 
>> That does not follow the definition in Section 3 of RFC 2804.  
> 
> And also: I'm sorry to have to say it, but I consider that
> attempted weasel wording around the clear intent of 2804. The
> clear and real effect if your wiretapping proposal were standardised
> by the IETF would be that we'd be standardising ways in which
> TLS servers can be compelled into breaking TLS - it'd be a standard
> wiretapping API that'd be insisted upon in many places and would
> mean significantly degrading TLS (only *the* most important
> security protocol we maintain) and the community's perception
> of the IETF. It's all a shockingly bad idea.

I clearly disagree.  Otherwise, I would not have put any work into the draft.

Russ

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Stephen Farrell]

On 07/07/17 22:38, Russ Housley wrote:
> Stephen:
> 
 You didn't refer to 2804 and the standards track. As an author
 do you really think this can be on the standards track and yet
 not obsolete 2804?
>>> 
>>> Yes.
>> 
>> We disagree.
>> 
>>> Section 3 of RFC 2804 offers pretty clear definition of 
>>> wiretapping, and that is not what is going on here.  In this 
>>> situation, all of the parties are part of the same organization, 
>>> under common key management.
>> 
>> That is one possible deployment. There is nothing in this proposal
>> that limits it's use to that.
>> 
>>> The server must explicitly accept and use the centrally managed
>>> (EC)DH key, so that party is completely aware and, in fact,
>>> enabling the other parties to decrypt the traffic.
>> 
>> Yes, and the server could equally be compelled to do that, in which
>> case this technology would clearly be a standard form of
>> wiretapping.
>> 
>> Claiming that is not the case would be incredible so I have no idea
>> how you maintain that this isn't in conflict with 2804.
> 
> That does not follow the definition in Section 3 of RFC 2804.  

And also: I'm sorry to have to say it, but I consider that
attempted weasel wording around the clear intent of 2804. The
clear and real effect if your wiretapping proposal were standardised
by the IETF would be that we'd be standardising ways in which
TLS servers can be compelled into breaking TLS - it'd be a standard
wiretapping API that'd be insisted upon in many places and would
mean significantly degrading TLS (only *the* most important
security protocol we maintain) and the community's perception
of the IETF. It's all a shockingly bad idea.

S

PS: You might say that purely static DH can be detected by
the TLS client, but once we give in on this it'll be inevitable
that variants are derived that aren't detectable by the TLS
client.


> If one
> of the parties is "compelled" to install the centrally managed (EC)DH
> key, then the server is aware.  If you consider the server to be the
> sending party, then this situation does not meet number 1 in the
> definition.  If you consider the server to be the receiving party,
> then this situation does not meet number 2 in the definition.
> 
> To save everyone from looking it up, RFC 2804 says:
> 
> Wiretapping is what occurs when information passed across the 
> Internet from one party to one or more other parties is delivered to 
> a third party:
> 
> 1. Without the sending party knowing about the third party
> 
> 2. Without any of the recipient parties knowing about the delivery
> to the third party
> 
> 3. When the normal expectation of the sender is that the transmitted 
> information will only be seen by the recipient parties or parties 
> obliged to keep the information in confidence
> 
> 4. When the third party acts deliberately to target the transmission 
> of the first party, either because he is of interest, or because the
> second party's reception is of interest.
> 
> The term "party", as used here, can refer to one person, a group of 
> persons, or equipment acting on behalf of persons; the term "party" 
> is used for brevity.
> 
> Of course, many wiretaps will be bidirectional, monitoring traffic 
> sent by two or more parties to each other.
> 
> Thus, for instance, monitoring public newsgroups is not wiretapping 
> (condition 3 violated), random monitoring of a large population is 
> not wiretapping (condition 4 violated), a recipient passing on 
> private email is not wiretapping (condition 2 violated).
> 
> Russ
> 



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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Stephen Farrell]

On 07/07/17 22:38, Russ Housley wrote:
> Stephen:
> 
 You didn't refer to 2804 and the standards track. As an author
 do you really think this can be on the standards track and yet
 not obsolete 2804?
>>> 
>>> Yes.
>> 
>> We disagree.
>> 
>>> Section 3 of RFC 2804 offers pretty clear definition of 
>>> wiretapping, and that is not what is going on here.  In this 
>>> situation, all of the parties are part of the same organization, 
>>> under common key management.
>> 
>> That is one possible deployment. There is nothing in this proposal
>> that limits it's use to that.
>> 
>>> The server must explicitly accept and use the centrally managed
>>> (EC)DH key, so that party is completely aware and, in fact,
>>> enabling the other parties to decrypt the traffic.
>> 
>> Yes, and the server could equally be compelled to do that, in which
>> case this technology would clearly be a standard form of
>> wiretapping.
>> 
>> Claiming that is not the case would be incredible so I have no idea
>> how you maintain that this isn't in conflict with 2804.
> 
> That does not follow the definition in Section 3 of RFC 2804.  If one
> of the parties is "compelled" to install the centrally managed (EC)DH
> key, then the server is aware. 

CDNs.

Cheers,
S.

? If you consider the server to be the
> sending party, then this situation does not meet number 1 in the
> definition.  If you consider the server to be the receiving party,
> then this situation does not meet number 2 in the definition.
> 
> To save everyone from looking it up, RFC 2804 says:
> 
> Wiretapping is what occurs when information passed across the 
> Internet from one party to one or more other parties is delivered to 
> a third party:
> 
> 1. Without the sending party knowing about the third party
> 
> 2. Without any of the recipient parties knowing about the delivery
> to the third party
> 
> 3. When the normal expectation of the sender is that the transmitted 
> information will only be seen by the recipient parties or parties 
> obliged to keep the information in confidence
> 
> 4. When the third party acts deliberately to target the transmission 
> of the first party, either because he is of interest, or because the
> second party's reception is of interest.
> 
> The term "party", as used here, can refer to one person, a group of 
> persons, or equipment acting on behalf of persons; the term "party" 
> is used for brevity.
> 
> Of course, many wiretaps will be bidirectional, monitoring traffic 
> sent by two or more parties to each other.
> 
> Thus, for instance, monitoring public newsgroups is not wiretapping 
> (condition 3 violated), random monitoring of a large population is 
> not wiretapping (condition 4 violated), a recipient passing on 
> private email is not wiretapping (condition 2 violated).
> 
> Russ
> 



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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Russ Housley]

Stephen:

>>> You didn't refer to 2804 and the standards track. As an author do
>>> you really think this can be on the standards track and yet not
>>> obsolete 2804?
>> 
>> Yes. 
> 
> We disagree.
> 
>> Section 3 of RFC 2804 offers pretty clear definition of
>> wiretapping, and that is not what is going on here.  In this
>> situation, all of the parties are part of the same organization,
>> under common key management.  
> 
> That is one possible deployment. There is nothing in this
> proposal that limits it's use to that.
> 
>> The server must explicitly accept and
>> use the centrally managed (EC)DH key, so that party is completely
>> aware and, in fact, enabling the other parties to decrypt the
>> traffic.
> 
> Yes, and the server could equally be compelled to do that,
> in which case this technology would clearly be a standard
> form of wiretapping.
> 
> Claiming that is not the case would be incredible so I have
> no idea how you maintain that this isn't in conflict with
> 2804.

That does not follow the definition in Section 3 of RFC 2804.  If one of the 
parties is "compelled" to install the centrally managed (EC)DH key, then the 
server is aware.  If you consider the server to be the sending party, then this 
situation does not meet number 1 in the definition.  If you consider the server 
to be the receiving party, then this situation does not meet number 2 in the 
definition.

To save everyone from looking it up, RFC 2804 says:

   Wiretapping is what occurs when information passed across the
   Internet from one party to one or more other parties is delivered to
   a third party:

   1. Without the sending party knowing about the third party

   2. Without any of the recipient parties knowing about the delivery to
  the third party

   3. When the normal expectation of the sender is that the transmitted
  information will only be seen by the recipient parties or parties
  obliged to keep the information in confidence

   4. When the third party acts deliberately to target the transmission
  of the first party, either because he is of interest, or because
  the second party's reception is of interest.

   The term "party", as used here, can refer to one person, a group of
   persons, or equipment acting on behalf of persons; the term "party"
   is used for brevity.

   Of course, many wiretaps will be bidirectional, monitoring traffic
   sent by two or more parties to each other.

   Thus, for instance, monitoring public newsgroups is not wiretapping
   (condition 3 violated), random monitoring of a large population is
   not wiretapping (condition 4 violated), a recipient passing on
   private email is not wiretapping (condition 2 violated).

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Stephen Farrell]

Hiya,

On 07/07/17 22:12, Russ Housley wrote:
> Stephen:
> 
>> You didn't refer to 2804 and the standards track. As an author do
>> you really think this can be on the standards track and yet not
>> obsolete 2804?
> 
> Yes. 

We disagree.

> Section 3 of RFC 2804 offers pretty clear definition of
> wiretapping, and that is not what is going on here.  In this
> situation, all of the parties are part of the same organization,
> under common key management.  

That is one possible deployment. There is nothing in this
proposal that limits it's use to that.

> The server must explicitly accept and
> use the centrally managed (EC)DH key, so that party is completely
> aware and, in fact, enabling the other parties to decrypt the
> traffic.

Yes, and the server could equally be compelled to do that,
in which case this technology would clearly be a standard
form of wiretapping.

Claiming that is not the case would be incredible so I have
no idea how you maintain that this isn't in conflict with
2804.

S.

> 
> Russ
> 
> 



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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Russ Housley]

Stephen:

> You didn't refer to 2804 and the standards track. As an
> author do you really think this can be on the standards
> track and yet not obsolete 2804?

Yes.  Section 3 of RFC 2804 offers pretty clear definition of wiretapping, and 
that is not what is going on here.  In this situation, all of the parties are 
part of the same organization, under common key management.  The server must 
explicitly accept and use the centrally managed (EC)DH key, so that party is 
completely aware and, in fact, enabling the other parties to decrypt the 
traffic.

Russ

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Stephen Farrell]

Russ,

You didn't refer to 2804 and the standards track. As an
author do you really think this can be on the standards
track and yet not obsolete 2804?

If you do, then I don't understand that. (And would argue
you are holding a counter-factual opinion.)

If you do not, then why does the draft say "standards
track"?

S.

PS: I disagree with other assertions below but the above
has to come first as we need to know if the authors are
or are not asking the IETF to change a major policy.

On 07/07/17 21:04, Russ Housley wrote:
> Stephen:
> 
>> On 07/07/17 19:40, Kyle Rose wrote:
>>> an informational draft submitted via the ISE
>>
>> ...has nothing to to with this WG and ought consume
>> no cycles on this list or in meetings.
>>
>> Yes, the ISE is the route 2804 envisages for documenting
>> wiretapping schemes such as this.
>>
>> The authors of this draft however chose to put "standards
>> track" in the header and some of those authors are very
>> very well aware of all the nuances here so that was not
>> a mistake is my conclusion. So I stand by my statement
>> that 2804 says no to this.
> 
> As Kyle quoted, RFC 2804 says that we should be talking about the design.  It 
> seems to me the only way to make this proposal more secure is to talk about 
> it.  And, the TLS WG has the people with the proper expertise for that 
> discussion.
> 
> The enterprise wants forward secrecy on the public Internet. Terminating the 
> TLS session at the load balancer preserves forward secrecy on the public 
> Internet.
> 
> We already had a discussion on this list about requiring a fresh ephemeral DH 
> key for every session.  The consensus was not to require it.  I understand 
> that there are already servers that use the same "ephemeral" DH key for more 
> than one session.  I gather that this is done for performance reasons.  
> 
> The conventions described in draft-green-tls-static-dh-in-tls13-01 for using 
> non-ephemeral DH keys has no impact on interoperability.  Discussion of that 
> topic could easily go in an Informational RFC.  Many Informational RFCs 
> describe crypto algorithms.  On the other hand, the protocol between the key 
> manager and the server for installing the non-ephemeral DH key has an impact 
> on interoperability, so it could be in a standards-track document.
> 
> In your response, you ignored a fairly significant point in my previous post.
> 
>   In some industries, there are regulatory requirements that cannot be
>   met without access to the plaintext.  Without some authorized access
>   mechanism, the enterprise will be forced to use plaintext within the
>   datacenter.  That seems like a worse alternative to me.
> 
> From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating 
> outdated crypto, like RC4 or MD5.  Instead, it is using exactly the same 
> crypto algorithms and key sizes as draft-ietf-tls-tls13.  Again, this seems 
> like a much better way forward than plaintext throughout the datacenter.
> 
> Russ
> 



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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Russ Housley]

Stephen:

> On 07/07/17 19:40, Kyle Rose wrote:
>> an informational draft submitted via the ISE
> 
> ...has nothing to to with this WG and ought consume
> no cycles on this list or in meetings.
> 
> Yes, the ISE is the route 2804 envisages for documenting
> wiretapping schemes such as this.
> 
> The authors of this draft however chose to put "standards
> track" in the header and some of those authors are very
> very well aware of all the nuances here so that was not
> a mistake is my conclusion. So I stand by my statement
> that 2804 says no to this.

As Kyle quoted, RFC 2804 says that we should be talking about the design.  It 
seems to me the only way to make this proposal more secure is to talk about it. 
 And, the TLS WG has the people with the proper expertise for that discussion.

The enterprise wants forward secrecy on the public Internet. Terminating the 
TLS session at the load balancer preserves forward secrecy on the public 
Internet.

We already had a discussion on this list about requiring a fresh ephemeral DH 
key for every session.  The consensus was not to require it.  I understand that 
there are already servers that use the same "ephemeral" DH key for more than 
one session.  I gather that this is done for performance reasons.  

The conventions described in draft-green-tls-static-dh-in-tls13-01 for using 
non-ephemeral DH keys has no impact on interoperability.  Discussion of that 
topic could easily go in an Informational RFC.  Many Informational RFCs 
describe crypto algorithms.  On the other hand, the protocol between the key 
manager and the server for installing the non-ephemeral DH key has an impact on 
interoperability, so it could be in a standards-track document.

In your response, you ignored a fairly significant point in my previous post.

In some industries, there are regulatory requirements that cannot be
met without access to the plaintext.  Without some authorized access
mechanism, the enterprise will be forced to use plaintext within the
datacenter.  That seems like a worse alternative to me.

>From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating 
>outdated crypto, like RC4 or MD5.  Instead, it is using exactly the same 
>crypto algorithms and key sizes as draft-ietf-tls-tls13.  Again, this seems 
>like a much better way forward than plaintext throughout the datacenter.

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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Shumon Huque]

On Fri, Jul 7, 2017 at 3:13 PM, Tom Ritter  wrote:

> As a note, I didn't see anything in this draft (from a quick read)
> that precludes any of DANE's Certificate Usage, Selector, or Matching
> Type fields. If that's not the case, perhaps someone can correct me.
>

Yes, that's correct. Is there any reason it should?

TLS applications are free to preclude the use of DANE parameters, but a
more general purpose protocol I feel probably should not. The draft does
refer several times to RFC 7671 (DANE updates and operational guidelines),
which has some recommendations which ought to be followed.


>A client must not be able to force a server to perform lookups on
>arbitrary domain names using this mechanism.  Therefore, a server
>MUST NOT construct chains for domain names other than its own.
>
> What about the reverse? Do we care about a server tricking a client
> into priming its DNS cache?


> -tom
>

Yes, we want to avoid that, but I would expect that any sane client
implementation, as a basic precaution, would only accept a DNSSEC chain
corresponding to the TLSA name that it expected to see. If the server
presented anything else, it would not be considered invalid. Similarly, if
the chain included embedded unexpected extraneous records, I would expect
the client implementation to ignore those (or even invalidate the whole
chain if it wanted to be more draconian). If necessary, we could have
explicit text about this.

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

Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

[Ilari Liusvaara]

On Fri, Jul 07, 2017 at 03:40:03PM -0400, Russ Housley wrote:
> > - PFS or pure-PSK only.
> > 
> > Small things can't do PFS unfortunately.
> 
> The TLS WG wants to work on a a way to combine a PSK with (EC)DH
> after the current specification is finished for quantum protection.

Well, PSK with DH does provode classical PFS.

And did you perhaps mean using PSK with DH and certificates? Because
both TLS 1.2 and TLS 1.3 can combine PSK with DH, but not all
three of PSK, DH and certificate all at once.



-Ilari

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

Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

[Russ Housley]

> - PFS or pure-PSK only.
> 
> Small things can't do PFS unfortunately.

The TLS WG wants to work on a a way to combine a PSK with (EC)DH after the 
current specification is finished for quantum protection.  Of course, that PSK 
must be distributed without any public-key crypto or it will not provide any 
quantum protection.

Russ

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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Tom Ritter]

As a note, I didn't see anything in this draft (from a quick read)
that precludes any of DANE's Certificate Usage, Selector, or Matching
Type fields. If that's not the case, perhaps someone can correct me.

   A client must not be able to force a server to perform lookups on
   arbitrary domain names using this mechanism.  Therefore, a server
   MUST NOT construct chains for domain names other than its own.

What about the reverse? Do we care about a server tricking a client
into priming its DNS cache?

-tom

On 28 June 2017 at 16:15, Joseph Salowey  wrote:
> This is the working group last call for
> draft-ietf-tls-dnssec-chain-extension-04.  Please send you comments to the
> list by July 12, 2017.
>
> Thanks,
>
> J
>
> ___
> 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] Suggestions in draft-mavrogiannopoulos-tls-cid

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Ashok,

Thanks very much for your comments.

See inline.

Cheers, t

On 07/07/2017, 14:44, "Raja ashok" 
> wrote:

Hi Nikos, Hannes & Thomas,

This ConnectionID concept is really a useful feature for a client node which 
faces a change in transport and network layer. I am having few suggestions in 
the proposed draft, which are listed below.

1) In section 3 of this draft, explains about the modification in 
"DTLSCiphertext" structure. I feel instead of modifying existing DTLS and TLS 
record header, we can directly introduce a new record type (ContentType) for 
app data (application_data_with_cid(25)).

[tf] Why do you think a new record type would be better than the present 
construction?  (BTW, we would also need a new alert_with_cid, I guess.)

For this new record type, we can propose a modified record header for both TLS 
and DTLS.

[tf] If you are already modifying the record header, I am not sure why you also 
need to add new content type(s)?

2) More over section 3 says modification only in "DTLSCiphertext", not for 
"TLSCiphertext". I hope this CID mechanism should be used for both TLS and 
DTLS. Because this transport layer change problem is there for TLS based 
applications (HTTPS) also in Smartphone(when it switches from Wifi to LTE). But 
this TLS application problem is solved by MPTCP, but I dont think all 
webservers are supporting this MPTCP. So I feel CID is required for both TLS 
and DTLS.

[tf] In principle I’m not opposed to open the solution space to TLS, but we 
need to work out the implications.

3) As part of defining new record type, we can remove some unused fields like 
version, epoch. After removing epoch we can mandate that  both entity should 
not start renegotiation. Sample design for new record header with CID is 
mentioned below
struct {
uint8_t ContentType;
uint8_t CID_len;
CID cid;/* Length varies from 4 to 8 (or 16) */
uint48 sequence_number;
uint16_t record_length;
} DTLSRecordHeader;
opaque CID <4..8>;

struct {
uint8_t ContentType;
uint8_t CID_len;
CID cid;/* Length varies from 4 to 8 (or 16) */
uint16_t record_length;
} TLSRecordHeader;
opaque CID <4..8>;

4) Another option is we can keep CID_len as 4 bit to represent a CID of size. 
And this 4 bit can be placed in the MSB of the CID field.

uint8_t CID_len:4;
CID cid;/* Length varies from 28bit to 60 bit (or 124bit) */


5) Section 3.1 and 3.2 talks about the new extensions for negotiating this 
feature support. But I feel no need of new extensions to negotiate this, we can 
make client to add new SCSV cipher in its cipher list. If server accepts then 
after handshake the first application data send by server should be of type 
application_data_with_cid(25), which should hold the new record header with 
CID. The same CID should be used by client in the further messasge. If client 
sends the 1st application data after handshake, then it can send application 
data with default record type (application_data(23)). If the first application 
data record received from server is not of application_data_with_cid(25) means 
client should understand that server has not accepted the SCSV proposed. And 
client should continue app transfer with default record type 
(application_data(23)).

[tf] What is the problem with using a new extension?  How would negotiating 
parameters (e.g., CID type, CID length) work in your proposal?

Please provide your comments on this suggestion.

Regards,
Ashok



[ompany_logo]

Raja Ashok V K
Huawei Technologies
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!

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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Benjamin Kaduk]

On 07/07/2017 01:31 PM, Shumon Huque wrote:
> I'm not suggesting that we need to come up with a solution for this,
> but I believe the issue probably needs some sort of mention somewhere
> (in Security Considerations?).

Sounds good to me.

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Stephen Farrell]

On 07/07/17 19:40, Kyle Rose wrote:
> an informational draft submitted via the ISE

...has nothing to to with this WG and ought consume
no cycles on this list or in meetings.

Yes, the ISE is the route 2804 envisages for documenting
wiretapping schemes such as this.

The authors of this draft however chose to put "standards
track" in the header and some of those authors are very
very well aware of all the nuances here so that was not
a mistake is my conclusion. So I stand by my statement
that 2804 says no to this.

S.



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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Kyle Rose]

On Fri, Jul 7, 2017 at 2:21 PM, Stephen Farrell 
wrote:

> I find it really hard to believe anyone is convinced of that.
>
> Yes, one could chose to use this proposed wiretapping scheme
> like that but figure 3 in the draft makes if fully clear that
> this colluding or coerced wiretapping device can be anywhere
> on the Internet.
>
> 2804 says "no" here - are you proposing to obsolete that?


I don't think 2804 says any such thing. In fact, it explicitly states that:

q( On the other hand, the IETF believes that mechanisms designed to
 facilitate or enable wiretapping, or methods of using other
 facilities for such purposes, should be openly described, so as to
 ensure the maximum review of the mechanisms and ensure that they
 adhere as closely as possible to their design constraints. The IETF
 believes that the publication of such mechanisms, and the
 publication of known weaknesses in such mechanisms, is a Good
 Thing. )

My reading of 2804 is that the IETF takes no moral position on wiretapping;
recommends against it on technical grounds; and encourages documentation of
proposed or in-use mechanisms for wiretapping for the express purpose of
publicizing the flaws inherent in any such approach.

IMO, an informational draft submitted via the ISE seems completely
appropriate for something like this. I'll add that we've already gotten
good input toward better alternatives on this very thread, which suggests
that having these discussions out in the open is likely to result in better
practical outcomes for user populations that are, one way or the other,
going to be subject to systems like this. Discussing something does not
presuppose or imply agreement on the objectives.

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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Shumon Huque]

On Fri, Jul 7, 2017 at 11:59 AM, Benjamin Kaduk  wrote:

> On 06/28/2017 04:15 PM, Joseph Salowey wrote:
>
> This is the working group last call for 
> draft-ietf-tls-dnssec-chain-extension-04.
> Please send you comments to the list by July 12, 2017.
>
>
> Just a couple minor things I don't remember being mentioned already that I
> noticed in a quick read:
>
> When section 3.4 mentions that "this document describes the data structure
> in sufficient detail that implementors if they desire can write their own
> code to do this", it seems that this really on makes sense when the "this"
> is for the encoding side, not the decoding side.  That is, in that we
> expect future DNS clients to continue to process responses in the current
> format, but future DNS servers might generate responses that cannot be
> properly decoded just following this document.  (E.g., what would happen if
> NSEC5 became popular?)
>

I think it's best to take that sentence out. It's a remnant of much earlier
versions of the draft where we did describe the decoding (and validation)
side in more detail, whereas now a lot of the client side processing is
being referred to DNSSEC specs.

Regarding future DNSSEC protocol enhancements that may necessitate format
and protocol processing changes, maybe it's best to defer those to future
revisions of the spec. But feel free to propose any specific wording on
this topic for inclusion.

(NSEC5 adoption in DNSOP is still very much an open question. The other
possible enhancement that might need to be considered in the future is
records related to key transparency - "CT for DNSSEC", which could happen
someday.)


> In section 8:
>
>Mandating this extension for Raw Public Key
>authentication (where there are no X.509 certificates) could employ
>configuration mechanisms external to the TLS protocol
>
> this sentence structure is a little confusing; it might be better to say 
> something like "If needed, configuration mechanism external to the TLS 
> protocol could be used to mandate the use of this extension for Raw Public 
> Key authentication".
>
> -Ben
>
>
Yes, your suggested text sounds much better. We can incorporate that.

However, there is larger concern that I have with section 8 that probably
deserves working group discussion. This section might imply that there is a
(protocol resident) way to mandate the use of this extension, but I don't
think there is an easy way. Even in the case of X.509 certificates, the TLS
feature extension can only dictate the delivery of this extension when the
client has connected to the right server presenting that certificate.

A TLS client misdirected to a rogue TLS server (e.g. via DNS spoofing, a
routing attack, or other means) that has fraudulently acquired a public CA
issued certificate for the legitimate server name, could be induced to
establish a (PKIX) verified connection to that rogue server that precludes
DANE authentication, when in fact it was available.

Some TLS applications may desire to mandate DANE authentication where
available, and protect themselves against malicious or tricked CAs. What is
the best way to accommodate them? TLS clients could keep a whitelist of
DANE servers, which doesn't scale very far; they could use TOFU/HPKP like
methods: add DANE supporting sites to a whitelist dynamically as they are
seen, etc.

Some other applications use the presence of an authenticated TLSA record to
enforce DANE authentication (RFC 7672 for SMTP STARTTLS). The last time
this was discussed in the context of tls-dnssec-chain, it was argued that
this "mandatory use" was not a semantic that the generic TLSA record
provides, so only specific applications should specify that behavior. But
if a specific TLS application using this extension did want to specify this
behavior, how could it happen?

In a hypothetical world where all TLS clients & servers understood this
extension, we could have required the TLS server to either (1) present the
dnssec_chain for their TLSA record, or (2) present a dnssec_chain that
demonstrates that there is no secure TLSA record, or that there is no
secure delegation to the zone. I think this would solve the problem, but
this isn't practical any time soon (or perhaps ever).

I'm not suggesting that we need to come up with a solution for this, but I
believe the issue probably needs some sort of mention somewhere (in
Security Considerations?).

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Stephen Farrell]

Hi Russ,

On 07/07/17 17:35, Russ Housley wrote:
> Repeating from above, the non-ephemeral DH keys are associated only
> with sessions that are inside the enterprise datacenter.

I find it really hard to believe anyone is convinced of that.

Yes, one could chose to use this proposed wiretapping scheme
like that but figure 3 in the draft makes if fully clear that
this colluding or coerced wiretapping device can be anywhere
on the Internet.

2804 says "no" here - are you proposing to obsolete that? If
so, being up-front about that is IMO a pre-requisite and talk
of "datacentres" avoided as the misdirection that it is.

Again, I hope the chairs do not devote/waste more time on this
until there is a demonstrated IETF consensus to obsolete 2804.
We cannot honestly have both this and that.

S.



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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Russ Housley]

Watson:

>> This document is extremely well written and describes the needs of
>> enterprises well,  IMHO.I believe and have heard,  there are similar
>> needs beyond the enterprise realm,  but since we are the only ones formally
>> expressing concerns, so be it.
> 
> Why does the IETF need to be involved, given this solution exists?

I would like there to be one way for the key manager to load the non-ephemeral 
key into the server and the authorized decrypt parties.  Without an RFC, I fear 
there will be many ways that this is handled, with varying levels of security.

Russ

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Andrei Popov]

Would the Informational track be an acceptable compromise? This does not have 
to be a product of the TLS working group.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, July 7, 2017 10:17 AM
To: Russ Housley ; Richard Barnes 
Cc: IETF TLS ; Matthew Green 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

I think there is little doubt that the draft is technically sound.

The question is, should the IETF "endorse" this by saying it is a product of 
the TLS working group?  That will certainly send a mixed message to some.  As 
we heard around around Seoul, not adopting might send a message to some 
industries that we are not interested in helping to solve their problems.

It is a fraught issue.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Salz, Rich]

I think there is little doubt that the draft is technically sound.

The question is, should the IETF “endorse” this by saying it is a product of 
the TLS working group?  That will certainly send a mixed message to some.  As 
we heard around around Seoul, not adopting might send a message to some 
industries that we are not interested in helping to solve their problems.

It is a fraught issue.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Richard Barnes]

On Fri, Jul 7, 2017 at 12:35 PM, Russ Housley  wrote:

> Richard:
>
> Without taking a position on whether this group should take on this work,
> a couple of questions about alternative approaches (sorry if these have
> been answered before):
>
> 1. It seems like the requirement here is that the DH private key be
> *predictable* by the monitoring box based on some static configuration.
> That is, it seems like you could have keys that are predictable to the
> monitoring device, but still vary over time, something like setting the
> private key from a KDF(SecretSharedWithMonitoringDevice, ServerRandom).
> Without having done much analysis, this seems more conservative than making
> things entirely static. Is there a reason to prefer the purely static
> approach besides simplicity?
>
>
> Please see Section 6 of the draft.  The non-ephemeral DH keys MUST have a
> validity period.  The keys are expected to change over time.
>

OK, then why not have this happen automatically (e.g., by folding in
ServerRandom) rather than doing the provisioning process over and over?



>
> 2. You could avoid changing how the DH works altogether by simply
> exporting the DH private key, encrypted with a key shared with the
> monitoring device, in a server extension.  (Not in EncryptedExtensions,
> obviously.)  This would also have the benefit of explicitly signaling when
> such monitoring is in use.  The only real challenge here is that the client
> would have to offer the extension in order for the server to be able to
> send it, which I expect things like browsers would be unlikely to do.
> However, given that the target of this draft seems to be intra-data-center
> TLS, perhaps this is a workable requirement?
>
>
> In most common deployment case, the load balancer at the edge of the
> enterprise datacenter will terminate the TLS session and start a new one.
> The TLS session that protects the traffic on the public Internet works
> exactly as described in draft-ietf-tls-tls13.  The non-ephemeral DH keys
> are associated only with sessions that are inside the enterprise
> datacenter.  So, you are right, no browser will be at either end of any of
> these TLS sessions.  There is no change to the way that the protocol makes
> use of the DH key.  The drft-green, the server need to look in a table to
> choose a valid non-ephemeral DH key.  In your proposal, the server need to
> wrap the ephemeral DH private key in a key-enceyption key.  Both solutions
> require the distribution of some key (either the non-ephemenral DH key or
> the key-encryption key) to the parties that are authorized to see the
> traffic.
>

Yes, I understand that all of the solutions in this space will require some
static configuration.  What I'm trying to do is minimize the degree to
which that static-ness reduces the entropy in the TLS handshake.

In the "fold in ServerRandom" version, the static information gets tempered
with per-session random information.  In the "smuggle out the private key"
version, the static information doesn't even touch the base TLS handshake;
it's only used for wrapping the DH private key.

I agree that the "smuggle out the private key" still has a static component
that you would want to refresh.  However, it's minimal, in the sense that
you're going to need to authenticate the monitoring box to the TLS server
somehow anyway (even if just for provisioning).  And it seems like a
cleaner separation to have the static component as something off to the
side of the main handshake, rather than having to make invasive changes to
the handshake code.

--Richard




>
>
> Stephen:
>
> I don't believe the WG should adopt this as it goes
> against rfc2804 and encourages bad behaviour. We
> ought not be helping to normalise broken crypto. I'm
> happy to repeat that at the mic in Prague but would
> be even happier if this draft were not discussed
> there - these attempts to weaken security have IMO
> already taken up too much time and too many cycles.
>
>
> Repeating from above, the non-ephemeral DH keys are associated only with
> sessions that are inside the enterprise datacenter.  In some industries,
> there are regulatory requirements that cannot be met without access to the
> plaintext.  Without some authorized access mechanism, the enterprise will
> be forced to use plaintext within the datacenter.  That seems like a worse
> alternative to me.
>
> Russ
>
>
> On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green 
> wrote:
>
>> The need for enterprise datacenters to access TLS 1.3 plaintext for
>> security and operational requirements has been under discussion since
>> shortly before the Seoul IETF meeting. This draft provides current thinking
>> about the way to facilitate plain text access based on the use of static
>> (EC)DH keys on the servers. These keys have a lifetime; they get replaced
>> on a regular schedule. A key manager in the datacenter generates and
>> distributes these keys.  The Asymmetric 

Re: [TLS] Suggestions in draft-mavrogiannopoulos-tls-cid

[Ilari Liusvaara]

On Fri, Jul 07, 2017 at 01:44:41PM +, Raja ashok wrote:
> Hi Nikos, Hannes & Thomas,
> 
> This ConnectionID concept is really a useful feature for a client
> node which faces a change in transport and network layer. I am
> having few suggestions in the proposed draft, which are listed below.
> 
> 1) In section 3 of this draft, explains about the modification in
> "DTLSCiphertext" structure. I feel instead of modifying existing
> DTLS and TLS record header, we can directly introduce a new record
> type (ContentType) for app data (application_data_with_cid(25)).
> For this new record type, we can propose a modified record header
> for both TLS and DTLS.

IMO, it is property of connection if CID is used, and what CID to use
(including any possible backup CID or two).

> 2) More over section 3 says modification only in "DTLSCiphertext",
> not for "TLSCiphertext". I hope this CID mechanism should be used
> for both TLS and DTLS. Because this transport layer change problem
> is there for TLS based applications (HTTPS) also in Smartphone(
> when it switches from Wifi to LTE). But this TLS application problem
> is solved by MPTCP, but I dont think all webservers are supporting
> this MPTCP. So I feel CID is required for both TLS and DTLS.

Deploying CID with TLS over TCP is bit nontrivial. The following
factors need to be considered:

- TLS assumes only single stream of application data.
- DoS by invalid address change.
- Datastream integerity in dirty switch.

The last one is pretty nasty.

> 3) As part of defining new record type, we can remove some unused
> fields like version, epoch. After removing epoch we can mandate that
>  both entity should not start renegotiation. Sample design for new
> record header with CID is mentioned below

DTLS 1.3 uses epoch field for rekeying. It is however uncler if it
needs 2 octets for epoch, or if just sending the lowest octet of
the epoch would be OK.

> 5) Section 3.1 and 3.2 talks about the new extensions for
> negotiating this feature support. But I feel no need of new
>extensions to negotiate this, we can make client to add new SCSV
> cipher in its cipher list.

Ugh, no SCSVs. This isn't some critical security fix that has to work
even with bad TLS stacks that don't support extensions.


-Ilari

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

Re: [TLS] draft-ietf-tls-tls13-21 posted

[Benjamin Kaduk]

On 07/03/2017 07:01 PM, Eric Rescorla wrote:
> Currently the extension table says that server_certificate_type goes
> in the Certificate message, whereas client_certificate_type does
> not. My reasoning for the latter is that the extensions are attached
> to individual certificate elements, so it was non-sensical to have a
> situation where you might have cert A be X.509 and cert B be PGP.  I
> think we should just change server_certificate_type to go in EE, and
> then maybe in future if people want something cleverer they can add it
> then. I didn't want to do this without WG discussion, but I think we
> should and if people don't object I'll do it in a -22.
>

Seems worth doing.


[snip]

>
> [0] Note that this is a bit tricky when you are also streaming
> Early Data.

I'm not sure what this footnote was supposed to refer to.

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Russ Housley]

Richard:

> Without taking a position on whether this group should take on this work, a 
> couple of questions about alternative approaches (sorry if these have been 
> answered before):
> 
> 1. It seems like the requirement here is that the DH private key be 
> *predictable* by the monitoring box based on some static configuration.  That 
> is, it seems like you could have keys that are predictable to the monitoring 
> device, but still vary over time, something like setting the private key from 
> a KDF(SecretSharedWithMonitoringDevice, ServerRandom). Without having done 
> much analysis, this seems more conservative than making things entirely 
> static. Is there a reason to prefer the purely static approach besides 
> simplicity?

Please see Section 6 of the draft.  The non-ephemeral DH keys MUST have a 
validity period.  The keys are expected to change over time.

> 2. You could avoid changing how the DH works altogether by simply exporting 
> the DH private key, encrypted with a key shared with the monitoring device, 
> in a server extension.  (Not in EncryptedExtensions, obviously.)  This would 
> also have the benefit of explicitly signaling when such monitoring is in use. 
>  The only real challenge here is that the client would have to offer the 
> extension in order for the server to be able to send it, which I expect 
> things like browsers would be unlikely to do.  However, given that the target 
> of this draft seems to be intra-data-center TLS, perhaps this is a workable 
> requirement?

In most common deployment case, the load balancer at the edge of the enterprise 
datacenter will terminate the TLS session and start a new one.  The TLS session 
that protects the traffic on the public Internet works exactly as described in 
draft-ietf-tls-tls13.  The non-ephemeral DH keys are associated only with 
sessions that are inside the enterprise datacenter.  So, you are right, no 
browser will be at either end of any of these TLS sessions.  There is no change 
to the way that the protocol makes use of the DH key.  The drft-green, the 
server need to look in a table to choose a valid non-ephemeral DH key.  In your 
proposal, the server need to wrap the ephemeral DH private key in a 
key-enceyption key.  Both solutions require the distribution of some key 
(either the non-ephemenral DH key or the key-encryption key) to the parties 
that are authorized to see the traffic.


Stephen:

> I don't believe the WG should adopt this as it goes
> against rfc2804 and encourages bad behaviour. We
> ought not be helping to normalise broken crypto. I'm
> happy to repeat that at the mic in Prague but would
> be even happier if this draft were not discussed
> there - these attempts to weaken security have IMO
> already taken up too much time and too many cycles.


Repeating from above, the non-ephemeral DH keys are associated only with 
sessions that are inside the enterprise datacenter.  In some industries, there 
are regulatory requirements that cannot be met without access to the plaintext. 
 Without some authorized access mechanism, the enterprise will be forced to use 
plaintext within the datacenter.  That seems like a worse alternative to me.

Russ


> On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green  > wrote:
> The need for enterprise datacenters to access TLS 1.3 plaintext for security 
> and operational requirements has been under discussion since shortly before 
> the Seoul IETF meeting. This draft provides current thinking about the way to 
> facilitate plain text access based on the use of static (EC)DH keys on the 
> servers. These keys have a lifetime; they get replaced on a regular schedule. 
> A key manager in the datacenter generates and distributes these keys.  The 
> Asymmetric Key Package [RFC5958] format is used to transfer and load the keys 
> wherever they are authorized for use.
> 
> We have asked for a few minutes to talk about this draft in the TLS WG 
> session at the upcoming Prague IETF. Please take a look so we can have a 
> productive discussion.  Of course, we're eager to start that discussion on 
> the mail list in advance of the meeting.
> 
> The draft can be found here:
> 
> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 
> 
> 
> Thanks for your attention,
> Matt, Ralph, Paul, Steve, and Russ

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

Re: [TLS] Truncated HMAC: what to do with the MAC key?

[Benjamin Kaduk]

On 07/07/2017 09:25 AM, Andreas Walz wrote:
> Dear all,
>
> today I encountered something that confuses me: different TLS
> implementations do not seem to agree on how to implement truncated
> HMAC. All implementations I tested truncate the HMAC output correctly,
> but they seem to use different MAC keys. When truncated HMAC is
> negotiated:
>
> -> MatrixSSL does not change the length of the MAC key but zeros all
> its bytes beyond index 10,
> -> mbedTLS truncates the MAC key to length 10,
> -> WolfSSL does not touch the MAC key at all.
>
> From RFC 6066 I would infer that the MAC key should not be affected by
> the negotiation of the truncated HMAC extension (as WolfSSL is
> implementing it). Is that correct?

I agree with your reading of RFC 6066 (and RFC 2104).

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

Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

[Ilari Liusvaara]

On Fri, Jul 07, 2017 at 03:14:10PM +, Salz, Rich wrote:
> > Just as a clarification, all new RFCs should ideally meet all of the 
> > following
> > criteria:
> > * AEAD only
> > * PFS only
> > * TLS 1.2 and 1.3 support
> > * no TLS 1.0 or 1.1 support (let alone SSL)
> > * no use of broken hashes (MD5, SHA1, etc.)
> 
> That's a good idea.
> 
> Want to throw together a quick draft for curdle or AD-sponsored SAAG?

Well, my own view is (with explanations):

- AEAD only.

TLS streammode has all ciphers deprecated, and furthermore contains a
design mistake. TLS blockmode padding is outside MAC, which makes
implementing such modes securely very hard. This leaves just AEAD
ciphers.

- No use of broken, dubious, <128-bit keylength or <128-bit blocklength
  ciphers.

These probably won't last long until becoming attack vectors (RC4
anyone, that was dubious back in late 90s, when TLS 1.0 was done).

- PFS or pure-PSK only.

Small things can't do PFS unforunately.

- No use of l < 2^241 for key exchange.

Such key exchanges provode <120 bits of security (or thereabouts).
I used 2^241, since this is between the values used by methods claiming
to be "128-bit secure" and "112-bit secure" (or even weaker).

- Security of any key exchange method against classical attacks has to
  be well established.

No key exchanges that are dubious against non-quantum attacks. Impiles
hybrid PQC exchanges,if relevant. I have seen a dubious key exchange
method just catastrophically fail.

- Support TLS 1.3 (unless it is a security fix for earlier TLS, in that
  case it has to co-exist with TLS 1.3).

The current version of TLS in the relevant timeframe will be 1.3.

- No fallbacks for TLS 1.0 or 1.1.

Don't waste effort on TLS 1.0 or 1.1. Use any new features in TLS 1.2
(e.g., not having to define key exchange methods for signature methods)
if those make things simpler.

- No use of broken, dubious, unusual (including usage mode) or <128-bit
  secure hashes.

These probably won't last long, or will be headache to find
implementations for (e.g., try finding implementation of Skein that
supports any more exotic use of datatyping than the native MAC mode,
the reference implementation does not).




-Ilari

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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Shumon Huque]

On Fri, Jul 7, 2017 at 11:34 AM, Jim Reid  wrote:

>
> > On 7 Jul 2017, at 16:06, Shumon Huque  wrote:
> >
> > IMO, the real gain from having the client cache data, is that the server
> could then potentially send a much smaller DNSSEC chain. But this requires
> the client to signal what they've cached, and makes the protocol more
> complex. I would prefer to leave that to a future revision of the spec,
> after we've gained some operational experience with the current one.
>
> Shumon, I think the biggest gain would be fewer RRSIGs for the client to
> validate. Having the server send a smaller DNSSEC chain (and perhaps add
> something to the protocol for a client to signal that) probably won’t have
> the right cost/benefit optics. YMMV. It would be a Good Thing if a TLS
> client didn’t need to revalidate everything in the chain for tlsa.foo.com
> after closing and reopening a TLS session to that end-point or it could
> start at the previously validated delegation for .com when the TLS server
> returned the full chain for tlsa.bar.com.
>
> As you hint at, it would be good to get more data and operational
> expertise.
>

Okay, absent any strenuous objections, I propose that we mention that the
client may cache data from the chain. For the case of a TLS client
re-connecting to the same end point, most likely TLS session resumption
would be used (thus dnssec_chain re-validation wouldn't be needed) so this
optimization doesn't gain anything. But yes, it would help save the client
some signature validation work in the case of tlsa.foo.com to tlsa.bar.com.

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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Jim Reid]

> On 7 Jul 2017, at 16:06, Shumon Huque  wrote:
> 
> IMO, the real gain from having the client cache data, is that the server 
> could then potentially send a much smaller DNSSEC chain. But this requires 
> the client to signal what they've cached, and makes the protocol more 
> complex. I would prefer to leave that to a future revision of the spec, after 
> we've gained some operational experience with the current one.

Shumon, I think the biggest gain would be fewer RRSIGs for the client to 
validate. Having the server send a smaller DNSSEC chain (and perhaps add 
something to the protocol for a client to signal that) probably won’t have the 
right cost/benefit optics. YMMV. It would be a Good Thing if a TLS client 
didn’t need to revalidate everything in the chain for tlsa.foo.com after 
closing and reopening a TLS session to that end-point or it could start at the 
previously validated delegation for .com when the TLS server returned the full 
chain for tlsa.bar.com.

As you hint at, it would be good to get more data and operational expertise. 

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

Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

[Salz, Rich]

> Just as a clarification, all new RFCs should ideally meet all of the following
> criteria:
> * AEAD only
> * PFS only
> * TLS 1.2 and 1.3 support
> * no TLS 1.0 or 1.1 support (let alone SSL)
> * no use of broken hashes (MD5, SHA1, etc.)

That's a good idea.

Want to throw together a quick draft for curdle or AD-sponsored SAAG?

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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Shumon Huque]

On Fri, Jul 7, 2017 at 10:11 AM, Jim Reid  wrote:

>
> > On 5 Jul 2017, at 18:12, Viktor Dukhovni  wrote:
> >
> > On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote:
> >
> >> 1) There probably needs to be clearer guidance about the use cases for
> >> this extension and the trade-offs between TLS clients doing DNSSEC
> >> validation for themselves instead of sending DNS lookups to a validating
> >> resolver server. How does an application developer decide which approach
> >> would or wouldn't be appropriate?
> >
> > On today's Internet, DNSSEC is not generally available to end-user
> > devices.  There are too many "last mile" problems.  Thus, while
> > direct acquisition of DANE TLSA records works for (e.g.) dedicated
> > SMTP servers, any end-user application that wants to do DANE TLS
> > needs to use the proposed extension.
>
> I am too painfully aware of those last mile issues.
>
> IMO the draft could be clearer about the fact it’s aimed at TLS clients
> that don’t have access to or a trust relationship with a validating DNS
> resolver.


It is not aimed solely at those clients.

The intro mentions 3 things: (1) TLS clients don't need to do any
additional DNS lookups for DANE/DNSSEC - the latency issue, (2) TLS clients
don't need to deal with breakage caused by middlebox/last mile issues if
they tried to do those lookups, and (3) they don't have secure access to a
validating resolver. If an application has any subset of these issues, it
might be candidate user of this extension.


> > Perhaps you're asking whether once the relevant records are obtained,
> > their validation should be via library calls to a suitable API, or
> > via a suitable protocol to the local resolver?
>
> No. I couldn’t care less about API issues or how the RRSIGs get validated.
> They’re implentation details for the implementation detail. I am uneasy at
> the prospect of every TLS client application include what will be
> essentially its own validating DNS resolver when there could/should be one
> of these already running on the device itself.
>

Maybe some day all end user machines will have a validating resolver, but
this isn't remotely close to a reality today.


> > Except that the records will be warm in the server's cache, since
> > many clients will be asking it for the *same* data.  The same is
> > not as likely to be true at the client.  So there is indeed a likely
> > latency reduction in farming out the lookups to the server.
>
> OK.
>
> It might be helpful to explicitly say “TLS server” rather than “server” to
> avoid confusion or ambiguity. Sometimes this is obvious from the context.
> But at other places in the draft “server” could be read as “DNS server”.
>

Ok, we can look through the text and disambiguate where needed.


> >> 4) It's not clear if TLS clients can or should cache the DNS data (and
> >> the resulting validations?) returned though this extension.
> >
> > The server will return TTLs, and caching per those TTLs is no less
> > appropriate than it is in DNS generally.
>
> Is there some reason why this isn’t in the draft?


We've had this discussion numerous times over the life of this draft, and
there was never any consensus for the client caching or not. An
implementation could have the client cache the data, and only validate the
portion of the chain that it needs to, without any wire protocol change.
I'm okay with mentioning that possibility.

IMO, the real gain from having the client cache data, is that the server
could then potentially send a much smaller DNSSEC chain. But this requires
the client to signal what they've cached, and makes the protocol more
complex. I would prefer to leave that to a future revision of the spec,
after we've gained some operational experience with the current one.

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Watson Ladd]

On Fri, Jul 7, 2017 at 7:40 AM, Ackermann, Michael  wrote:
> Matt
>
> This document is extremely well written and describes the needs of
> enterprises well,  IMHO.I believe and have heard,  there are similar
> needs beyond the enterprise realm,  but since we are the only ones formally
> expressing concerns, so be it.

Why does the IETF need to be involved, given this solution exists?

>
>
>
> The detail on the implementation,  as well as the details on why other
> alternative solutions are not viable/sufficient,  is very good and will help
> focus any related conversations.
>
>
>
> I very much hope this can be on the agenda at IETF 99.
>
> Thanks for your very productive efforts on this.
>
> Mike
>
>
>
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Matthew Green
> Sent: Friday, July 7, 2017 3:03 AM
> To: tls@ietf.org
> Subject: [TLS] draft-green-tls-static-dh-in-tls13-01
>
>
>
> The need for enterprise datacenters to access TLS 1.3 plaintext for security
> and operational requirements has been under discussion since shortly before
> the Seoul IETF meeting. This draft provides current thinking about the way
> to facilitate plain text access based on the use of static (EC)DH keys on
> the servers. These keys have a lifetime; they get replaced on a regular
> schedule. A key manager in the datacenter generates and distributes these
> keys.  The Asymmetric Key Package [RFC5958] format is used to transfer and
> load the keys wherever they are authorized for use.
>
>
>
> We have asked for a few minutes to talk about this draft in the TLS WG
> session at the upcoming Prague IETF. Please take a look so we can have a
> productive discussion.  Of course, we're eager to start that discussion on
> the mail list in advance of the meeting.
>
>
>
> The draft can be found here:
>
>
>
> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01
>
>
>
> Thanks for your attention,
>
> Matt, Ralph, Paul, Steve, and Russ
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic mail
> or telephone, of any unintended receipt and delete the original message
> without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Ackermann, Michael]

Matt
This document is extremely well written and describes the needs of enterprises 
well,  IMHO.I believe and have heard,  there are similar needs beyond the 
enterprise realm,  but since we are the only ones formally expressing concerns, 
so be it.

The detail on the implementation,  as well as the details on why other 
alternative solutions are not viable/sufficient,  is very good and will help 
focus any related conversations.

I very much hope this can be on the agenda at IETF 99.
Thanks for your very productive efforts on this.
Mike

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Matthew Green
Sent: Friday, July 7, 2017 3:03 AM
To: tls@ietf.org
Subject: [TLS] draft-green-tls-static-dh-in-tls13-01

The need for enterprise datacenters to access TLS 1.3 plaintext for security 
and operational requirements has been under discussion since shortly before the 
Seoul IETF meeting. This draft provides current thinking about the way to 
facilitate plain text access based on the use of static (EC)DH keys on the 
servers. These keys have a lifetime; they get replaced on a regular schedule. A 
key manager in the datacenter generates and distributes these keys.  The 
Asymmetric Key Package [RFC5958] format is used to transfer and load the keys 
wherever they are authorized for use.

We have asked for a few minutes to talk about this draft in the TLS WG session 
at the upcoming Prague IETF. Please take a look so we can have a productive 
discussion.  Of course, we're eager to start that discussion on the mail list 
in advance of the meeting.

The draft can be found here:

https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01

Thanks for your attention,
Matt, Ralph, Paul, Steve, and Russ


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Truncated HMAC: what to do with the MAC key?

[Andreas Walz]

Dear all,

today I encountered something that confuses me: different TLS
implementations do not seem to agree on how to implement truncated HMAC.
All implementations I tested truncate the HMAC output correctly, but
they seem to use different MAC keys. When truncated HMAC is negotiated:

-> MatrixSSL does not change the length of the MAC key but zeros all its
bytes beyond index 10,
-> mbedTLS truncates the MAC key to length 10,
-> WolfSSL does not touch the MAC key at all.

>From RFC 6066 I would infer that the MAC key should not be affected by
the negotiation of the truncated HMAC extension (as WolfSSL is
implementing it). Is that correct?

Thank you very much!
Cheers



___

Andreas Walz
Email: andreas.w...@hs-offenburg.de

Institute of reliable Embedded Systems and Communication Electronics
(ivESK)
Homepage: http://ivesk.hs-offenburg.de/

University of Applied Sciences Offenburg
Offenburg University of Applied SciencesOffenburg University of Applied
SciencesOffenburg University of Applied SciencesOffenburg University of
Applied Sciences



Badstraße 24
77652 Offenburg
Germany


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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Jim Reid]

> On 7 Jul 2017, at 02:47, Shumon Huque  wrote:
> 
> I assume you're referring to the examples in Appendix D (Test Vectors)?

Yes.

> These are working examples that implementers can test code against. But it 
> looks like the testbed involved in these examples uses combined signing keys 
> (i.e. ones that are both the zone's secure entry point and the ZSK). Perhaps 
> we should use an example with the KSK/ZSK split to make them look more like 
> the real world. Let me discuss with Willem Toorop (co-author) who generated 
> these ...

Willem told me he’d used the KSK as the ZSK for cosmetic reasons. Examples 
showing the KSK/ZSK split would show how things generally work the real world.


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

Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Jim Reid]

> On 5 Jul 2017, at 18:12, Viktor Dukhovni  wrote:
> 
> On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote:
> 
>> 1) There probably needs to be clearer guidance about the use cases for
>> this extension and the trade-offs between TLS clients doing DNSSEC
>> validation for themselves instead of sending DNS lookups to a validating
>> resolver server. How does an application developer decide which approach
>> would or wouldn't be appropriate?
> 
> On today's Internet, DNSSEC is not generally available to end-user
> devices.  There are too many "last mile" problems.  Thus, while
> direct acquisition of DANE TLSA records works for (e.g.) dedicated
> SMTP servers, any end-user application that wants to do DANE TLS
> needs to use the proposed extension.

I am too painfully aware of those last mile issues.
 
IMO the draft could be clearer about the fact it’s aimed at TLS clients that 
don’t have access to or a trust relationship with a validating DNS resolver. It 
might also be worthwhile explaining the trade-offs between the DNSSEC lookup 
and TLS chaining approaches and how an implementer or operator can choose 
between them when/if both are available. Though if the spec was to say “don’t 
bother with DNSSEC lookups at all and just use this chaining extension”, that 
would be fine.

> Perhaps you're asking whether once the relevant records are obtained,
> their validation should be via library calls to a suitable API, or
> via a suitable protocol to the local resolver?

No. I couldn’t care less about API issues or how the RRSIGs get validated. 
They’re implentation details for the implementation detail. I am uneasy at the 
prospect of every TLS client application include what will be essentially its 
own validating DNS resolver when there could/should be one of these already 
running on the device itself.

> Except that the records will be warm in the server's cache, since
> many clients will be asking it for the *same* data.  The same is
> not as likely to be true at the client.  So there is indeed a likely
> latency reduction in farming out the lookups to the server.

OK.

It might be helpful to explicitly say “TLS server” rather than “server” to 
avoid confusion or ambiguity. Sometimes this is obvious from the context. But 
at other places in the draft “server” could be read as “DNS server”.

>> 4) It's not clear if TLS clients can or should cache the DNS data (and
>> the resulting validations?) returned though this extension.
> 
> The server will return TTLs, and caching per those TTLs is no less
> appropriate than it is in DNS generally.

Is there some reason why this isn’t in the draft?

>> 5) How does a TLS client behave when its DNSSEC validation of a TLSA record
>> or whatever fails? Can/should it give up or fall back to conventional
>> validation of the certificate via a CA?
> 
> This is application/configuration dependent.

That probably needs to be captured in the document too.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-21 posted

[Matt Caswell]

On 4 July 2017 at 01:01, Eric Rescorla  wrote:
> Hi folks,
>
> I just published draft-21, which incorporates the discussions we've
> been having about 0-RTT replay.

FYI, OpenSSL master branch is now draft-21 compliant.

Matt

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

[TLS] Suggestions in draft-mavrogiannopoulos-tls-cid

[Raja ashok]

Hi Nikos, Hannes & Thomas,

This ConnectionID concept is really a useful feature for a client node which 
faces a change in transport and network layer. I am having few suggestions in 
the proposed draft, which are listed below.

1) In section 3 of this draft, explains about the modification in 
"DTLSCiphertext" structure. I feel instead of modifying existing DTLS and TLS 
record header, we can directly introduce a new record type (ContentType) for 
app data (application_data_with_cid(25)). For this new record type, we can 
propose a modified record header for both TLS and DTLS.

2) More over section 3 says modification only in "DTLSCiphertext", not for 
"TLSCiphertext". I hope this CID mechanism should be used for both TLS and 
DTLS. Because this transport layer change problem is there for TLS based 
applications (HTTPS) also in Smartphone(when it switches from Wifi to LTE). But 
this TLS application problem is solved by MPTCP, but I dont think all 
webservers are supporting this MPTCP. So I feel CID is required for both TLS 
and DTLS.

3) As part of defining new record type, we can remove some unused fields like 
version, epoch. After removing epoch we can mandate that  both entity should 
not start renegotiation. Sample design for new record header with CID is 
mentioned below
struct {
uint8_t ContentType;
uint8_t CID_len;
CID cid;/* Length varies from 4 to 8 (or 16) */
uint48 sequence_number;
uint16_t record_length;
} DTLSRecordHeader;
opaque CID <4..8>;

struct {
uint8_t ContentType;
uint8_t CID_len;
CID cid;/* Length varies from 4 to 8 (or 16) */
uint16_t record_length;
} TLSRecordHeader;
opaque CID <4..8>;

4) Another option is we can keep CID_len as 4 bit to represent a CID of size. 
And this 4 bit can be placed in the MSB of the CID field.

uint8_t CID_len:4;
CID cid;/* Length varies from 28bit to 60 bit (or 124bit) */


5) Section 3.1 and 3.2 talks about the new extensions for negotiating this 
feature support. But I feel no need of new extensions to negotiate this, we can 
make client to add new SCSV cipher in its cipher list. If server accepts then 
after handshake the first application data send by server should be of type 
application_data_with_cid(25), which should hold the new record header with 
CID. The same CID should be used by client in the further messasge. If client 
sends the 1st application data after handshake, then it can send application 
data with default record type (application_data(23)). If the first application 
data record received from server is not of application_data_with_cid(25) means 
client should understand that server has not accepted the SCSV proposed. And 
client should continue app transfer with default record type 
(application_data(23)).

Please provide your comments on this suggestion.

Regards,
Ashok



[Company_logo]

Raja Ashok V K
Huawei Technologies
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!

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Richard Barnes]

Without taking a position on whether this group should take on this work, a
couple of questions about alternative approaches (sorry if these have been
answered before):

1. It seems like the requirement here is that the DH private key be
*predictable* by the monitoring box based on some static configuration.
That is, it seems like you could have keys that are predictable to the
monitoring device, but still vary over time, something like setting the
private key from a KDF(SecretSharedWithMonitoringDevice, ServerRandom).
Without having done much analysis, this seems more conservative than making
things entirely static. Is there a reason to prefer the purely static
approach besides simplicity?

2. You could avoid changing how the DH works altogether by simply exporting
the DH private key, encrypted with a key shared with the monitoring device,
in a server extension.  (Not in EncryptedExtensions, obviously.)  This
would also have the benefit of explicitly signaling when such monitoring is
in use.  The only real challenge here is that the client would have to
offer the extension in order for the server to be able to send it, which I
expect things like browsers would be unlikely to do.  However, given that
the target of this draft seems to be intra-data-center TLS, perhaps this is
a workable requirement?

Thanks,
--Richard


On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green 
wrote:

> The need for enterprise datacenters to access TLS 1.3 plaintext for
> security and operational requirements has been under discussion since
> shortly before the Seoul IETF meeting. This draft provides current thinking
> about the way to facilitate plain text access based on the use of static
> (EC)DH keys on the servers. These keys have a lifetime; they get replaced
> on a regular schedule. A key manager in the datacenter generates and
> distributes these keys.  The Asymmetric Key Package [RFC5958] format is
> used to transfer and load the keys wherever they are authorized for use.
>
> We have asked for a few minutes to talk about this draft in the TLS WG
> session at the upcoming Prague IETF. Please take a look so we can have a
> productive discussion.  Of course, we're eager to start that discussion on
> the mail list in advance of the meeting.
>
> The draft can be found here:
>
> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01
>
> Thanks for your attention,
> Matt, Ralph, Paul, Steve, and Russ
>
> ___
> 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] draft-ietf-tls-tls13-21 posted

[Matt Caswell]

On 5 July 2017 at 11:35, Eric Rescorla  wrote:
>
> Yes, that might not be a terrible idea. I'd also be open to replacing
> the hashes of 0 with an n-byte length 0 string. It's a tiny paper
> cut (and a wire format change), but would make things slightly simpler .


I'm not entirely sure what you mean be the "hashes of 0". Are you
referring to the 0 length input passed to Derive-Secret in the various
Derive-Secret(., "derived", "") instances (and also for the
binder_key)?

Matt

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Stephen Farrell]

I don't believe the WG should adopt this as it goes
against rfc2804 and encourages bad behaviour. We
ought not be helping to normalise broken crypto. I'm
happy to repeat that at the mic in Prague but would
be even happier if this draft were not discussed
there - these attempts to weaken security have IMO
already taken up too much time and too many cycles.

S.

On 07/07/17 08:02, Matthew Green wrote:
> The need for enterprise datacenters to access TLS 1.3 plaintext for
> security and operational requirements has been under discussion since
> shortly before the Seoul IETF meeting. This draft provides current thinking
> about the way to facilitate plain text access based on the use of static
> (EC)DH keys on the servers. These keys have a lifetime; they get replaced
> on a regular schedule. A key manager in the datacenter generates and
> distributes these keys.  The Asymmetric Key Package [RFC5958] format is
> used to transfer and load the keys wherever they are authorized for use.
> 
> We have asked for a few minutes to talk about this draft in the TLS WG
> session at the upcoming Prague IETF. Please take a look so we can have a
> productive discussion.  Of course, we're eager to start that discussion on
> the mail list in advance of the meeting.
> 
> The draft can be found here:
> 
> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01
> 
> Thanks for your attention,
> Matt, Ralph, Paul, Steve, and Russ
> 
> 
> 
> ___
> 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] signature algorithm ID re-use

[Nikos Mavrogiannopoulos]

On Wed, Jul 5, 2017 at 12:50 AM, Martin Thomson 
wrote:

> On 4 July 2017 at 07:43, Nikos Mavrogiannopoulos  wrote:
> > So my question is why not go for the simpler approach and create new
> > identifiers for the new signature algorithms? (similarly to RSA-PSS).
> > Is there an advantage of re-using the ECDSA signature algorithm
> > identifiers to mean something different in TLS 1.3? Was there some
> > discussion on the topic on the list?
>
>
> This was fairly extensively litigated.  I remember Hannes asking
> exactly the same question, but I forget which in-person meeting it
> was.  It might have been IETF 97.
>
> Unfortunately, any search I do on this subject turns up the hundreds
> of emails on using signature algorithms for selecting certificates.
>
> What I've found is that this isn't that difficult to implement
> correctly, even across versions.  As David Benjamin suggested in
> earlier emails, you can change to using a 16-bit codepoint in your
> code.  Then you add a curve-matching restriction if the selected
> version is TLS 1.3 (or greater).
>

Well, it depends on the definition of correctly :) You can certainly have
interoperation following something similar to what you describe, however
the question is what about semantics. How do you translate that to the
user? If one is careful with semantics and would like to let the user
specify a policy of allowed operations/signature algorithms, he would have
to specify two different signature algorithms, one for ecdsa with any
curve, and another for the restricted to secp256r1, and then make sure that
what is sent over the wire will be interpreted according to the policy by a
TLS 1.2 or a TLS 1.3 server (which I find it quite impossible for any
policy which requires anything else than a single curve and signature
algorithm).

That's why my question is on what is the advantage of the code point
re-use, because I see only disadvantages.

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

[TLS] draft-green-tls-static-dh-in-tls13-01

[Matthew Green]

The need for enterprise datacenters to access TLS 1.3 plaintext for
security and operational requirements has been under discussion since
shortly before the Seoul IETF meeting. This draft provides current thinking
about the way to facilitate plain text access based on the use of static
(EC)DH keys on the servers. These keys have a lifetime; they get replaced
on a regular schedule. A key manager in the datacenter generates and
distributes these keys.  The Asymmetric Key Package [RFC5958] format is
used to transfer and load the keys wherever they are authorized for use.

We have asked for a few minutes to talk about this draft in the TLS WG
session at the upcoming Prague IETF. Please take a look so we can have a
productive discussion.  Of course, we're eager to start that discussion on
the mail list in advance of the meeting.

The draft can be found here:

https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01

Thanks for your attention,
Matt, Ralph, Paul, Steve, and Russ
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls