Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00

[Jim Schaad]

 

 

From: Mohit Sethi M  
Sent: Wednesday, July 8, 2020 1:03 AM
To: Jim Schaad ; Mohit Sethi M 
; draft-ietf-tls-external-psk-guida...@ietf.org
Cc: tls@ietf.org
Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00

 

Hi Jim,

On 7/6/20 7:06 PM, Jim Schaad wrote:

 
 

-Original Message-
From: Mohit Sethi M  <mailto:mohit.m.se...@ericsson.com> 

Sent: Monday, July 6, 2020 3:10 AM
To: Jim Schaad  <mailto:i...@augustcellars.com> ; 
draft-ietf-tls-external-psk-
guida...@ietf.org <mailto:guida...@ietf.org> 
Cc: tls@ietf.org <mailto:tls@ietf.org> 
Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00
 
Hi Jim,
 
Thanks for the review. A clarifying question in-line.
 
On 7/2/20 12:02 AM, Jim Schaad wrote:

* In section 4 there is a statement that switching the roles of
servers which use PSKs will lead to weakening of security properties.
As this is a common scenario today in situations where you are doing
server-to-server communication, it would be useful to discuss just how
and how much this weakening occurs.  This was a complete surprise to
me and I don't know if it was supposed to be one.  Are there mitigations that

can be made?

 
* In section 7, The first sentence does not read, also It seems a bit
difficult to have a MUST in there when most of the items below are SHOULDs.
That seems to be a dissonance.
 
* Section 7.1.1 - The idea of having domain name suffixes on PSKs
seems to me to be a bad idea as this would seem to lower privacy levels.

 
I think you are referring to the PSK identity and not to the PSK.
 
As you know, the Network Access Identifiers (NAIs) used in EAP typically need
the domain name suffix for roaming, federation, etc.

 
This is true, it is also true that EAP is very strong on saying that if you 
have a choice, always send an anonymous version of the NAI if you have to do it 
in the clear.  This means that the domain can be used for correlation, but you 
do not have the full identity for that purpose.
 
I think that the EMU group is going to need to look at what level of privacy 
protection it is going to desire when using a PSK, but in that case there is no 
need for having  a domain suffix as that information is provided elsewhere.   
This might require keeping the TLS tunneling as an option to deal with passive 
attacks.

You are absolutely right about the preference for using anonymous identities. 
draft-ietf-emu-eap-tls13 currently says the following about resumption: 

   It is RECOMMENDED to use a NAIs with the same realm in the resumption
   and the original full authentication.  This requirement allows EAP
   packets to be routable to the same destination as the original full
   authentication.  If this recommendation is not followed, resumption
   is likely to be impossible.  When NAI reuse can be done without
   privacy implications, it is RECOMMENDED to use the same anonymous NAI
   in the resumption, as was used in the original full authentication.
   E.g. the NAI @realm can safely be reused, while the NAI
   ZmxleG8=@realm cannot. 

This document and the ensuing discussion pertains only to external PSKs and 
external PSK identities. I think I incorrectly used the word "issue" in my 
previous email as a more correct choice would have been "agree/establish" (i.e. 
the server and client agree on an external PSK and an external PSK identity). 
RFC 8446 doesn't place any restrictions on external PSK identities (other than 
the fact that they are at least 1 byte). If we are going to discourage the use 
of domain names in external PSK identities, would that be sufficient? What 
prevents me from using an external PSK identity of the type: 
my_strong_secret_psk_with_amazon_server? 

I am not sure if we should recommend randomized external PSK identities of a 
certain minimum length. Perhaps it might be better to add a disclaimer about 
the privacy loss from carelessly chosen external PSK identities? 

[JLS] There are going to be three different cases for external PSK identities: 
The identity if factory provisioned and carried in a file to the server,  the 
identity is factory provisioned and read by the user from the device, and it is 
hand chosen.  The first two cases can definitely be randomized.  I don’t know 
that having a minimum length makes any difference.  This is not exactly a 
cryptographic property.  Another thing that might be done would be analogous to 
the PSK importer document and apply a one way hash from the typed in value to 
the value that is sent over the wire so on the wire it is just a random set of 
bytes.

Jim

 

--Mohit

 

 
 

 
I would like to understand the nature of the resulting privacy loss. Is it that 
a
passive attacker can now easily determine the server which issued the PSK
identity (and the server where it will eventually be used)?

 
While it I true that at least some of the privacy information has already been 
leaked in the PSK case, you know the address t

Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00

[Jim Schaad]

> -Original Message-
> From: Mohit Sethi M 
> Sent: Monday, July 6, 2020 3:10 AM
> To: Jim Schaad ; draft-ietf-tls-external-psk-
> guida...@ietf.org
> Cc: tls@ietf.org
> Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00
> 
> Hi Jim,
> 
> Thanks for the review. A clarifying question in-line.
> 
> On 7/2/20 12:02 AM, Jim Schaad wrote:
> > * In section 4 there is a statement that switching the roles of
> > servers which use PSKs will lead to weakening of security properties.
> > As this is a common scenario today in situations where you are doing
> > server-to-server communication, it would be useful to discuss just how
> > and how much this weakening occurs.  This was a complete surprise to
> > me and I don't know if it was supposed to be one.  Are there mitigations 
> > that
> can be made?
> >
> > * In section 7, The first sentence does not read, also It seems a bit
> > difficult to have a MUST in there when most of the items below are SHOULDs.
> > That seems to be a dissonance.
> >
> > * Section 7.1.1 - The idea of having domain name suffixes on PSKs
> > seems to me to be a bad idea as this would seem to lower privacy levels.
> 
> I think you are referring to the PSK identity and not to the PSK.
> 
> As you know, the Network Access Identifiers (NAIs) used in EAP typically need
> the domain name suffix for roaming, federation, etc.

This is true, it is also true that EAP is very strong on saying that if you 
have a choice, always send an anonymous version of the NAI if you have to do it 
in the clear.  This means that the domain can be used for correlation, but you 
do not have the full identity for that purpose.

I think that the EMU group is going to need to look at what level of privacy 
protection it is going to desire when using a PSK, but in that case there is no 
need for having  a domain suffix as that information is provided elsewhere.   
This might require keeping the TLS tunneling as an option to deal with passive 
attacks.

> 
> I would like to understand the nature of the resulting privacy loss. Is it 
> that a
> passive attacker can now easily determine the server which issued the PSK
> identity (and the server where it will eventually be used)?

While it I true that at least some of the privacy information has already been 
leaked in the PSK case, you know the address that is being talked to and the 
PSK identity that is passed.  If you look at using thigs like ESNI, doing this 
would appear to potentially give away the very information that is being hidden 
in that case.  

The other problem with having domain based KIDs is that you could easily get 
some amount of correlation between the KIDs that are assigned in different 
domains.  You could end up with mohit.ietf and mohit.amazon and it would be 
quite reasonable to assume that both of those identities are going to be for 
the same entity, just in different domains.

Jim


> 
> --Mohit
> 
> >
> > * Section 7.1.2 - There seem to me to be three different places where
> > collisions will occur.  The importer function could get a collision,
> > there could be collisions with pre-TLS 1.2 external identifiers and
> > there could be collision with resumption keys.  There has been a huge
> > discussion about this in the EMU group and I don't find the text here
> > to be sensible in term of whether this is or is not a problem.
> >
> > * Section 7.1.2 - One of the things that I kept meaning to get to and
> > just haven't done so yet, is dealing with the question of can the TLS
> > Key binders in the handshake to distinguish between multiple keys that
> > happen to have the same identity.  Perhaps you should look to see if
> > this does work and if it is safe.
> >
> > Jim
> >
> >

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

Re: [TLS] [Cfrg] Review of draft-ietf-tls-external-psk-guidance-00

[Jim Schaad]

Yes I did mean to send this to tls not cfrg - I had just sent mail there and
did not look hard.


> -Original Message-
> From: Christopher Wood 
> Sent: Wednesday, July 1, 2020 2:09 PM
> To: Jim Schaad 
> Subject: Re: [Cfrg] Review of draft-ietf-tls-external-psk-guidance-00
> 
> (-lists)
> 
> Hi Jim,
> 
> Before replying, did you mean to cc tls@ instead of cfrg@?
> 
> Thanks!
> Chris
> 
> On Wed, Jul 1, 2020, at 2:02 PM, Jim Schaad wrote:
> > * In section 4 there is a statement that switching the roles of
> > servers which use PSKs will lead to weakening of security properties.
> > As this is a common scenario today in situations where you are doing
> > server-to-server communication, it would be useful to discuss just how
> > and how much this weakening occurs.  This was a complete surprise to
> > me and I don't know if it was supposed to be one.  Are there mitigations
that
> can be made?
> >
> > * In section 7, The first sentence does not read, also It seems a bit
> > difficult to have a MUST in there when most of the items below are
SHOULDs.
> > That seems to be a dissonance.
> >
> > * Section 7.1.1 - The idea of having domain name suffixes on PSKs
> > seems to me to be a bad idea as this would seem to lower privacy levels.
> >
> > * Section 7.1.2 - There seem to me to be three different places where
> > collisions will occur.  The importer function could get a collision,
> > there could be collisions with pre-TLS 1.2 external identifiers and
> > there could be collision with resumption keys.  There has been a huge
> > discussion about this in the EMU group and I don't find the text here
> > to be sensible in term of whether this is or is not a problem.
> >
> > * Section 7.1.2 - One of the things that I kept meaning to get to and
> > just haven't done so yet, is dealing with the question of can the TLS
> > Key binders in the handshake to distinguish between multiple keys that
> > happen to have the same identity.  Perhaps you should look to see if
> > this does work and if it is safe.
> >
> > Jim
> >
> >
> > ___
> > Cfrg mailing list
> > c...@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
> >

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

Re: [TLS] something something certificate --- boiling a small lake

[Jim Schaad]

> -Original Message-
> From: Nico Williams 
> Sent: Saturday, June 27, 2020 3:51 PM
> To: Salz, Rich 
> Cc: Jim Schaad ; 'Michael Richardson'
> ; 'Brian Campbell' ;
> ietf-http...@w3.org; tls@ietf.org
> Subject: Re: [TLS] something something certificate --- boiling a small
lake
> 
> On Sat, Jun 27, 2020 at 06:17:18PM +, Salz, Rich wrote:
> > >Ah - Post-Handshake Authentication?
> >
> > Yeah, that.
> 
> There's no limit to how many of those there can be, correct?

As far as I know there is no limit.  There are going to be a large number of
arguments about what it means.

Jim


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

Re: [TLS] Adoption call for draft-rescorla-tls-ctls

[Jim Schaad]

I believe that this is a worth while effort.  I will be willing to review
and might contribute text

-Original Message-
From: TLS  On Behalf Of Sean Turner
Sent: Wednesday, November 20, 2019 9:36 PM
To: TLS List 
Subject: [TLS] Adoption call for draft-rescorla-tls-ctls

At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG
and the LAKE BOF, which is now a chartered WG [3].  After some discussions,
the ADs suggested [4] that the TLS WG consider whether this draft be adopted
as a TLS WG item. LAKE could then later specify/refer/adopt/profile it, as
appropriate. The authors revised cTLS and presented the revised draft at
IETF 106 [5].  At IETF 106 there was support for adoption of cTLS as a WG
item.  To confirm this on the list: if you believe that the TLS WG should
not adopt this as a WG item, then please let the chairs know by posting a
message to the TLS list by 2359 UTC 13 December 2019 (and say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then
this will necessarily result in a WG rechartering discussions.  We would
have gotten to this rechartering discussion anyway now that DTLS 1.3 is
progressing out of the WG.

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/
[1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
[2] https://github.com/ekr/draft-rescorla-tls-ctls
[3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
[4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk
[5]
https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tl
s-13-00.pdf
___
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-kinnear-tls-client-net-address comments

[Jim Schaad]

I have not looked at this draft yet, but what about DTLS/UDP?

Jim


> -Original Message-
> From: TLS  On Behalf Of Tommy Pauly
> Sent: Wednesday, March 20, 2019 3:00 PM
> To: Martin Thomson 
> Cc: tls@ietf.org
> Subject: Re: [TLS] draft-kinnear-tls-client-net-address comments
> 
> The QUIC and TLS drafts were written together, and are quite similar as
you
> note. The intention is to use the TLS extension over TLS/TCP connections,
> and the QUIC extension for QUIC/UDP.
> 
> I agree that QUIC as a protocol benefits more from the extension than TLS
> does, but applications on top of both can benefit by detecting NATs, for
> making decisions about long-lived connections and privacy mitigations.
> 
> Thanks,
> Tommy
> 
> > On Mar 20, 2019, at 2:26 AM, Martin Thomson 
> wrote:
> >
> > I see a substantially similar draft in
draft-pauly-quic-address-extension.  I'd
> like to understand how these might be complementary, or whether the idea
> is to pursue only one.  The QUIC extension seems superior, if you have
QUIC.
> There are a lot more plausible reasons to want this information in QUIC
> though.
> >
> > Nits:
> >
> > The format of the extension is not ideal.  Wouldn't you want to know
which
> family it came from?
> 
> I think the intention was to use the length to infer the family.
> >
> > The term of art is reflexive address (or reflected address).
> 
> Thanks, good to know!
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] CWTs in TLS

[Jim Schaad]

Coming out of the EDHOC discussions, I was thinking about doing this as
well.  I will definitely read it before Prague.

 

Jim

 

 

From: TLS  On Behalf Of Hannes Tschofenig
Sent: Tuesday, March 12, 2019 1:59 AM
To: tls@ietf.org
Subject: [TLS] CWTs in TLS

 

Hi all,

 

I submitted a short document about the use of CBOR Web Tokens (CWTs) in TLS.
The document is quite simple in the sense that it registers a new
"certificate type" into an already existing registry. 

 

Here is the draft: https://tools.ietf.org/html/draft-tschofenig-tls-cwt-00 

 

At the moment, this is a bit of an experiment. We hope to get some code size
improvements over the use of X.509 certificates. 

 

Ciao

Hannes & Mathias

 

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you. 

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

Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client?

[Jim Schaad]

After thinking about this for a while, I would expect that sending an
external PSK w/ a ticket should be rare for those systems that are going to
want to do privacy protection.  Sending the external PSK would allow for
association of sessions that should not happen with just the ticket.

Jim


> -Original Message-
> From: TLS  On Behalf Of Martin Thomson
> Sent: Thursday, May 10, 2018 5:31 PM
> To:  
> Subject: Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the
client?
> 
> On Fri, May 11, 2018 at 9:08 AM Viktor Dukhovni 
> wrote:
> >   Should servers issue resumption tickets after an initial PSK
handshake?
> >   And if so, should resumption be preferred for any reason when the
client
> >   sends both a resumption ticket and the external PSK?
> 
> I don't think that we can codify anything here, but the angle I approach
this
> from is in terms of what safeguards are placed on keys.
> 
> Ticket keys are typically stored in volatile or temporary storage with
their
> relatively brief validity interval being the primary safeguard against
theft.
> That makes them easy to use, but they are consequently unusable over long
> periods of time.
> 
> If an external PSK has a need to be viable over longer periods, then
perhaps
> you want to use it less often.  That might be to avoid having to load it
into
> memory and risk it being readable, or it might be because the controls on
its
> use are more onerous.  For instance, some might require user input (for a
> PIN or the like), or have a performance cost involved in access.
> 
> All speculation, but there you go.
> 
> ___
> 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] TLS 1.3 multiple session tickets from the client?

[Jim Schaad]

> -Original Message-
> From: TLS  On Behalf Of Viktor Dukhovni
> Sent: Thursday, May 10, 2018 8:47 AM
> To: TLS WG 
> Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client?
> 
> 
> 
> > On May 10, 2018, at 10:17 AM, Eric Rescorla  wrote:
> >
> >> Do you prepend some new "magic" to the (RFC5077 or similar) session
> >> tickets?  Or just look for a matching STEK key name and let that be
> >> the "magic"?
> >
> > I would imagine, but NSS, at least, doesn't support external PSKs.
> 
> Good to know.  Does any implementation other than OpenSSL support
> external PSKs?  How do you distinguish between external PSKs and
> resumption PSKs?

This is going to be a lot more common with DTLS implementations.  I am not
sure how much resumption is going to be used for those cases.

Jim

> 
> --
>   Viktor.
> 
> ___
> 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] [DTLS]: how to handle unknown identity and bad psk ?

[Jim Schaad]

As a secondary issue related to this.  My client is currently implementing the 
handshake protocol a little too faithfully to the 1.2 DTLS specification.  
Since the client side reliability loop does not have any discussion on deciding 
that the server has gone dark or is just never going to respond there is an 
infinite loop that is created.  The client will always do a back off resend of 
the last set of handshake messages.

 

Jim

 

 

From: TLS  On Behalf Of Simon Bernard
Sent: Thursday, April 26, 2018 2:32 AM
To: Eric Rescorla 
Cc: tls@ietf.org
Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ?

 

Eric, thx a lot for your answer. 

We are discussing a lot about that with our community and there is still no 
consensus ...

So I come back to you to have clearer information to help us to make the good 
decision.

Using DTLS with PSK over UDP, without re-negotiation allowed :
- Is there known security issue about sending the same alert for both "unknown 
identity" and "bad_psk"(invalid record for handshake message) ?

"Discarding records aims to preserve current association", if we are able to 
preserve current association using :
- no renegotiation allowed,
- send alert for invalid record only for handshake record and if we have an 
ongoing handshake,
- In cases where a server believes it has an existing association on a given 
host/port quartet and it receives an epoch=0 ClientHello, destroy the existing 
association only if the client has demonstrated reachability by completing a 
cookie exchange.

Should it be OK ? 

Thx again for your time.

Simon

Le 06/04/2018 à 19:26, Eric Rescorla a écrit :

 

 

On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard  > wrote:

Hi,

We are implementing DTLS with PSK over UDP and I would like to know how 
"unknown identity" and "bad psk" should be handled

Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
(https://tools.ietf.org/html/rfc4279#section-2)

>   If the server does not recognize the PSK identity, it MAY respond
>   with an "unknown_psk_identity" alert message. Alternatively, if the
>   server wishes to hide the fact that the PSK identity was not known,
>   it MAY continue the protocol as if the PSK identity existed but the
>   key was incorrect: that is, respond with a "decrypt_error" alert.

In TLS the safer way seems to send a "decrypt_error" alert for both.

But in DTLS :
https://tools.ietf.org/html/rfc6347#section-4.1.2.7

>   In general, invalid records
>   SHOULD be silently discarded, thus preserving the association;
>   however, an error MAY be logged for diagnostic purposes.
>   Implementations which choose to generate an alert instead, MUST
>   generate fatal level alerts to avoid attacks where the attacker
>   repeatedly probes the implementation to see how it responds to
>   various types of error.  Note that if DTLS is run over UDP, then any
>   implementation which does this will be extremely susceptible to
>   denial-of-service (DoS) attacks because UDP forgery is so easy.
>   Thus, this practice is NOT RECOMMENDED for such transports.

Is this record layer recommendation for all type of record ? even HANDSHAKE(22) 
record (and so FINISHED message) or is it mainly for APPLICATION_DATA(23) 
record ?

Is it acceptable to send fatal alert "decrypt_error" in DTLS or should we just 
ignore bad credentials silently ?

 

Hi  Simon,

 

The advice in 4279 is basically "make an unknown identity look like a bad key". 
So the idea would be to just randomize the key and then get the TLS or 
DTLS-type behavior. I.e., with TLS you would send decrypt_error and in DTLS the 
handshake would just stall because you would drop packets.

 

-Ekr

 

--
Simon

___
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] Problem with DTLS 1.2 handshake

[Jim Schaad]

Yes, I am talking about the TLS record MAC.

 

In my case this was happening because of a misconfiguration on the PSK.  When 
we finally figured out that this was a MAC error on the record, then we 
immediately looked at the values of the PSK knowing that this was the most 
likely failure.  The fact that in the main handshake this leads to a large 
amount of retries by the client I am not sure that this is just a slower 
failure detection.  I agree that this is less of an issue for a simple rotate 
the keys problem.  I am slightly worried about having the same problem on a 
re-negotiation though.

 

Jim

 

 

From: Eric Rescorla <e...@rtfm.com> 
Sent: Monday, March 26, 2018 6:24 AM
To: Jim Schaad <i...@augustcellars.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Problem with DTLS 1.2 handshake

 

First, just for clarification, you mean the TLS record MAC on the Finished

rather than the TLS Finished MAC, right?

 

Assuming that is correct, then I believe this is reasonable behavior. It

makes the protocol somewhat more resistant to damaged bits on the wire.

Note that QUIC takes this position even further: every packet is integrity

protected (the initial packets use a key based on the CID). The primary

consequence of this is slower failure detection, but the kind of case you're

talking about primarily happens when there is an implementation error,

so not much in the field anyway.

 

-Ekr

 

 

On Mon, Mar 26, 2018 at 6:09 AM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

I appear to have run across an implementation that does not appear to
violate the specification, but which in my opinion is just plain wrong.

I am doing a handshake with PSK.  On the second flight from the client it
sends

[ChangeCipherSpec]
Finished

The server sees that the ChangeCipherSpec occurs and moves to use the keys.
It then attempts to validate the MAC on the Finished message and silently
ignores the Finish message because the MAC is incorrect and the text says
that it is legal to ignore packets which have a bad MAC.  This means that my
client re-sends the same flight to the server on and on because it never
gets a response and assumes that the packet must be getting lost in transit.


The document does not say that ignoring of bad MACs does not apply until the
Finished message is received and processed.  I am not sure, but I believe
the document needs to say that one cannot ignore a failed MAC on the first
block of data in any epoch and must error on those messages.

I have not looked to see if this is an issue for DTLS 1.3, but it could
easily be.

Jim


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

 

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

[TLS] Problem with DTLS 1.2 handshake

[Jim Schaad]

I appear to have run across an implementation that does not appear to
violate the specification, but which in my opinion is just plain wrong.

I am doing a handshake with PSK.  On the second flight from the client it
sends 

[ChangeCipherSpec]
Finished

The server sees that the ChangeCipherSpec occurs and moves to use the keys.
It then attempts to validate the MAC on the Finished message and silently
ignores the Finish message because the MAC is incorrect and the text says
that it is legal to ignore packets which have a bad MAC.  This means that my
client re-sends the same flight to the server on and on because it never
gets a response and assumes that the packet must be getting lost in transit.


The document does not say that ignoring of bad MACs does not apply until the
Finished message is received and processed.  I am not sure, but I believe
the document needs to say that one cannot ignore a failed MAC on the first
block of data in any epoch and must error on those messages.  

I have not looked to see if this is an issue for DTLS 1.3, but it could
easily be.

Jim


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

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

[Jim Schaad]

> -Original Message-
> From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com]
> Sent: Monday, February 19, 2018 9:51 AM
> To: Jim Schaad <i...@augustcellars.com>
> Cc: 'Martin Thomson' <martin.thom...@gmail.com>; tls@ietf.org; draft-ietf-
> tls-record-li...@ietf.org
> Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit
> 
> On Mon, Feb 19, 2018 at 09:27:14AM -0800, Jim Schaad wrote:
> >
> >
> > > -Original Message-
> > > From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com]
> > > Sent: Monday, February 19, 2018 9:18 AM
> > > To: Jim Schaad <i...@augustcellars.com>
> > > Cc: 'Martin Thomson' <martin.thom...@gmail.com>; tls@ietf.org;
> > > draft-ietf- tls-record-li...@ietf.org
> > > Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit
> > >
> > > On Mon, Feb 19, 2018 at 08:31:53AM -0800, Jim Schaad wrote:
> > > > Martin,
> > > >
> > > > I think that the wording I would prefer would be along the lines
> > > > of
> > > >
> > > > A server MUST NOT error on the value of the extension when a
> > > > higher TLS version is requested.  The server MUST use the minimum
> > > > of the requested value and the maximum value for the TLS version
> negotiated.
> > > > A server MAY error if a the value of the extension is exceeded for
> > > > the version of TLS requested.
> > >
> > > You need to consider the case where there is some unknown-to-server
> > > extension that happens to alter the limit.
> >
> > I am not sure how, as a that server, I could possibly do that.  I
> > can't act on something I don't understand.
> 
> Because the server can not know the semantics of unknown extensions, it has
> to assume any such can alter the maximum limit. Of course, when it comes to
> that, the server could just not error on too large limits regardless of other
> extensions.

But if the server does not understand the new extension, then it would not be 
returned to the client so that the client would understand how the server 
decided on what the maximum value that it is going to use for the client is.  
The client can then abort the connection if it does not like the new limit.  
However, I think that this would only affect the MAY in the proposed text.

Jim

> 
> 
> -Ilari

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

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

[Jim Schaad]

> -Original Message-
> From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com]
> Sent: Monday, February 19, 2018 9:18 AM
> To: Jim Schaad <i...@augustcellars.com>
> Cc: 'Martin Thomson' <martin.thom...@gmail.com>; tls@ietf.org; draft-ietf-
> tls-record-li...@ietf.org
> Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit
> 
> On Mon, Feb 19, 2018 at 08:31:53AM -0800, Jim Schaad wrote:
> > Martin,
> >
> > I think that the wording I would prefer would be along the lines of
> >
> > A server MUST NOT error on the value of the extension when a higher
> > TLS version is requested.  The server MUST use the minimum of the
> > requested value and the maximum value for the TLS version negotiated.
> > A server MAY error if a the value of the extension is exceeded for the
> > version of TLS requested.
> 
> You need to consider the case where there is some unknown-to-server
> extension that happens to alter the limit.

I am not sure how, as a that server, I could possibly do that.  I can't act on 
something I don't understand.

Jim

> 
> 
> -Ilari

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

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

[Jim Schaad]

Martin,

I think that the wording I would prefer would be along the lines of 

A server MUST NOT error on the value of the extension when a higher TLS version 
is requested.  The server MUST use the minimum of the requested value and the 
maximum value for the TLS version negotiated.  A server MAY error if a the 
value of the extension is exceeded for the version of TLS requested.

> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Monday, February 19, 2018 2:15 AM
> To: Jim Schaad <i...@augustcellars.com>; <tls@ietf.org> <tls@ietf.org>
> Cc: draft-ietf-tls-record-li...@ietf.org
> Subject: Re: Mail regarding draft-ietf-tls-record-limit
> 
> (+tls@)
> 
> This is a good question Jim and one that I thought through during
> implementation, but failed to capture in the doc.
> 
> Basically, there is no way to validate the extension if the client includes an
> unknown version of TLS or an extension that it doesn't understand.  A client
> can know because it should understand the protocol as negotiated.
> 
> The text currently says "an endpoint MUST NOT send a value higher than the
> protocol-defined maximum record size unless explicitly allowed by such a
> future version or extension"  I think that we should add "A server MUST NOT
> enforce this restriction; a client might advertise a higher limit that is 
> enabled
> by an extension or version the server does not understand."
> 
> Does that make sense?
> 
> 
> On Mon, Feb 19, 2018 at 5:51 PM, Jim Schaad <i...@augustcellars.com>
> wrote:
> > I was looking at this document relative to a specific question for
> > Kathleen, and I had one thing that I would like you to look at and see
> > if you think it is clear enough.
> >
> > I have a server that is TLS 1.2, a client that is TLS 1.2 & 1.3.   It sends
> > a hello w/ and extension value of 2^14+1.  It is not completely clear
> > to me that the server should accept this as a legal value and compute
> > the min of it and the maximum 1.2 value as the value to use when
> > sending messages to the client rather than producing an error message
> > because the value is too large.
> >
> > Jim
> >
> >

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

Re: [TLS] Should CCM_8 CSs be Recommended?

[Jim Schaad]

How much of a problem with people are we going to get into if the IoT profiles 
for the IETF go and say "You MUST use this algorithm which the IETF does not 
recommend?"

I think that this is very likely to get some strong push back from people I 
that is the case.  Reluctantly I think that we need to keep the recommendation 
on this algorithms.



> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner
> Sent: Tuesday, October 3, 2017 3:54 PM
> To:  
> Subject: [TLS] Should CCM_8 CSs be Recommended?
> 
> In the IANA registries draft (https://github.com/tlswg/draft-ietf-tls-iana-
> registry-updates), we’ve added a recommended column to the Cipher Suites
> (CSs) registry (and some others).  Right now, the criteria for getting a
> recommended mark is AEAD ciphers with strong authentication standards
> track ciphers.  While that’s great generally, the list we’ve got five CSs that
> gave Joe and I pause:
> 
> TLS_DHE_RSA_WITH_AES_128_CCM_8
> TLS_DHE_RSA_WITH_AES_256_CCM_8
> TLS_PSK_DHE_WITH_AES_128_CCM_8
> TLS_PSK_DHE_WITH_AES_256_CCM_8
> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256
> 
> The CCM_8 CSs have a significantly truncated authentication tag that
> represents a security trade-off that may not be appropriate for general
> environment.  In other words, this might be great for some IoT device but we
> should not generally be recommending these.
> 
> We’re recommending that these five suites be dropped from the
> recommended list.  Please let us know what you think.
> 
> J
> (editor hats on)
> ___
> 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] Using both External PSK and (EC)DH in TLS 1.3

[Jim Schaad]

 

 

From: Eric Rescorla [mailto:e...@rtfm.com] 
Sent: Saturday, March 25, 2017 6:40 AM
To: Jim Schaad <i...@augustcellars.com>
Cc: Russ Housley <hous...@vigilsec.com>; IETF TLS <tls@ietf.org>
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

 

 

 

On Fri, Mar 24, 2017 at 8:14 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

EKR – I think that is the wrong answer because of the resume case.

 

Why? It seems like for Russ'a application, you would inject the static PSK 
initially

and then it would be implicitly part of any resumption so no need to reinject it

to obtain PQ safety.

 

It seems odd to me that you would want to use a different key agree algorithm 
when you are doing the initial negotiation as opposed to the resumption.   
Depending on how the static PSK is specified, it might need to be restated for 
the resumption as well.

 

Jim

 

 

-Ekr

 

However, I would expect that the external PSK would be appended or otherwise 
munge into the computed secret (assuming DH) and would be consumed as part of 
that processing.  No additional slot needed.

 

jim

 

From: TLS [mailto:tls-boun...@ietf.org <mailto:tls-boun...@ietf.org> ] On 
Behalf Of Eric Rescorla
Sent: Friday, March 24, 2017 12:19 PM
To: Russ Housley <hous...@vigilsec.com <mailto:hous...@vigilsec.com> >
Cc: IETF TLS <tls@ietf.org <mailto:tls@ietf.org> >
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

 

Why would the external PSK not just go into he PSK slot.

 

-Ekr

 

 

On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley <hous...@vigilsec.com 
<mailto:hous...@vigilsec.com> > wrote:


> I agree with David here. Specifically, I think.
>
> - The base specification should continue to forbid certificates in 
> combination with PSK
> - We should at some point contemplate an extension that allows the use of 
> certificates in combination with PSK
> - The base spec should be factored in such a way as to make that extension 
> easy.


While I agree that we do not want to delay the TLS 1.3 specification to sort 
this out; however, I do not think we have provided the hook to make this future 
extension easy.   Looking at the key schedule in -19, I think we can provide 
the hook without being disruptive.  My goal is to minimize the pain to 
implementing the extension in the future by putting a straightforward hook in 
today:

 0
 |
 v
   PSK ->  HKDF-Extract = Early Secret
 |
 +-> Derive-Secret(.,
 | "external psk binder key" |
 | "resumption psk binder key",
 | "")
 | = binder_key
 |
 +-> Derive-Secret(., "client early traffic secret",
 | ClientHello)
 | = client_early_traffic_secret
 |
 +-> Derive-Secret(., "early exporter master secret",
 | ClientHello)
 | = early_exporter_secret
 v
   Derive-Secret(., "derived secret", "")
 |
 v
(EC)DHE -> HKDF-Extract = Handshake Secret
 |
 +-> Derive-Secret(., "client handshake traffic secret",
 | ClientHello...ServerHello)
 | = client_handshake_traffic_secret
 |
 +-> Derive-Secret(., "server handshake traffic secret",
 | ClientHello...ServerHello)
 | = server_handshake_traffic_secret
 v
   Derive-Secret(., "derived secret", "")
 |
 v
ExtPSK OR 0 -> HKDF-Extract = Master Secret
 |
 +-> Derive-Secret(., "client application traffic secret",
 | ClientHello...Server Finished)
 | = client_traffic_secret_0
 |
 +-> Derive-Secret(., "server application traffic secret",
 | ClientHello...Server Finished)
 | = server_traffic_secret_0
 |
 +-> Derive-Secret(., "exporter master secret",
 | ClientHello...Server Finished)
 | = exporter_secret
 |
 +-> Derive-Secret(., "

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Jim Schaad]

EKR – I think that is the wrong answer because of the resume case.

 

However, I would expect that the external PSK would be appended or otherwise 
munge into the computed secret (assuming DH) and would be consumed as part of 
that processing.  No additional slot needed.

 

jim

 

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, March 24, 2017 12:19 PM
To: Russ Housley 
Cc: IETF TLS 
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

 

Why would the external PSK not just go into he PSK slot.

 

-Ekr

 

 

On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley  > wrote:


> I agree with David here. Specifically, I think.
>
> - The base specification should continue to forbid certificates in 
> combination with PSK
> - We should at some point contemplate an extension that allows the use of 
> certificates in combination with PSK
> - The base spec should be factored in such a way as to make that extension 
> easy.


While I agree that we do not want to delay the TLS 1.3 specification to sort 
this out; however, I do not think we have provided the hook to make this future 
extension easy.   Looking at the key schedule in -19, I think we can provide 
the hook without being disruptive.  My goal is to minimize the pain to 
implementing the extension in the future by putting a straightforward hook in 
today:

 0
 |
 v
   PSK ->  HKDF-Extract = Early Secret
 |
 +-> Derive-Secret(.,
 | "external psk binder key" |
 | "resumption psk binder key",
 | "")
 | = binder_key
 |
 +-> Derive-Secret(., "client early traffic secret",
 | ClientHello)
 | = client_early_traffic_secret
 |
 +-> Derive-Secret(., "early exporter master secret",
 | ClientHello)
 | = early_exporter_secret
 v
   Derive-Secret(., "derived secret", "")
 |
 v
(EC)DHE -> HKDF-Extract = Handshake Secret
 |
 +-> Derive-Secret(., "client handshake traffic secret",
 | ClientHello...ServerHello)
 | = client_handshake_traffic_secret
 |
 +-> Derive-Secret(., "server handshake traffic secret",
 | ClientHello...ServerHello)
 | = server_handshake_traffic_secret
 v
   Derive-Secret(., "derived secret", "")
 |
 v
ExtPSK OR 0 -> HKDF-Extract = Master Secret
 |
 +-> Derive-Secret(., "client application traffic secret",
 | ClientHello...Server Finished)
 | = client_traffic_secret_0
 |
 +-> Derive-Secret(., "server application traffic secret",
 | ClientHello...Server Finished)
 | = server_traffic_secret_0
 |
 +-> Derive-Secret(., "exporter master secret",
 | ClientHello...Server Finished)
 | = exporter_secret
 |
 +-> Derive-Secret(., "resumption master secret",
   ClientHello...Client Finished)
   = resumption_master_secret


The only change is "ExtPSK OR 0” in the HKDF-Extract for the Master Secret 
computation.

The Section 4.1.1 can call out this place for the future specification:

OLD:

   -  When authenticating via a certificate, the server will send the
  Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
  messages.  In TLS 1.3 as defined by this document, either a PSK or
  a certificate is always used, but not both.  Future documents may
  define how to use them together.

NEW:

   -  When authenticating via a certificate, the server will send the
  Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
  messages.  In TLS 1.3 as defined by this document, either a PSK or
  a certificate is always used, but not both.  So, the ExtPSK is not
  used in the key schedule (Section 7.1).  Future documents may
  define how to use them together and tell how the ExtPSK is
  handled in the key schedule.

Russ



 

___
TLS mailing list
TLS@ietf.org

Re: [TLS] BoringSSL's TLS test suite

[Jim Schaad]

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Henrick Hellström
> Sent: Sunday, September 25, 2016 4:35 PM
> To: David Benjamin ; Adam Langley
> 
> Cc: tls@ietf.org
> Subject: Re: [TLS] BoringSSL's TLS test suite
> 
> On 2016-09-25 23:55, David Benjamin wrote:
> > I believe we are also correct per spec. My interpretation of these
> > documents is that the general AlgorithmIdentifier structure may or may
> > not include parameters. However, whether a given parameter value or
> > omitting parameters altogether is legal is a question for the
> > particular algorithm. It's not overriding but plugging into the general
> framework.
> 
> THe ITU-T X.690 standard for DER might require some close reading to
interpret,
> and this is obviously a topic for debate. I would presume that the use of
> "default" in lower caps in section 11.5, refers to both the DEFAULT and
the
> OPTIONAL keyword:

OPTIONAL and DEFAULT are not the same things.  A DEFAULT value is omitted
but not an OPTIONAL value.  A single field cannot be both OPTIONAL and
DEFAULT.

Jim

> 
>11.5   Set and sequence components with default value
>The encoding of a set value or sequence value shall not include an
>encoding for any component value which is equal to its default value.
> 
> After all, this is the only interpretation that is consistent with the
description in
> section 12.5 of DER as unambiguous.
> 
> Since NULL is always empty, it should be omitted when OPTIONAL, given the
> above interpretation. But is it optional? The 1988 syntax did not feature
> information objects and classes, hence the use of the ANY keyword.
> 
> Luckily the ASN.1 modules were updated in RFC 5912 to modern ASN.1 syntax.
> There you have these declarations:
> 
> --  SIGNATURE-ALGORITHM
> --
> --  Describes the basic properties of a signature algorithm
> --
> --   - contains the OID identifying the signature algorithm
> --   - contains a type definition for the value structure of
> --  the signature; if absent, implies that no ASN.1
> --  encoding is performed on the value
> --   - if present, contains the type for the algorithm
> --   parameters; if absent, implies no parameters
> --   - parameter presence requirement
> --   - The set of hash algorithms used with this
> --  signature algorithm
> --   - the set of public key algorithms for this
> --  signature algorithm
> --   - contains the object describing how the S/MIME
> --  capabilities are presented.
> --
> --  Example:
> --  sig-RSA-PSS SIGNATURE-ALGORITHM ::= {
> -- IDENTIFIER id-RSASSA-PSS
> -- PARAMS TYPE RSASSA-PSS-params ARE required
> -- HASHES { mda-sha1 | mda-md5, ... }
> -- PUBLIC-KEYS { pk-rsa | pk-rsa-pss }
> -- }
> 
> 
> SIGNATURE-ALGORITHM ::= CLASS {
>   OBJECT IDENTIFIER UNIQUE,
>OPTIONAL,
>   OPTIONAL,
>ParamOptions DEFAULT absent,
>  DIGEST-ALGORITHM OPTIONAL,
> PUBLIC-KEY OPTIONAL,
>SMIME-CAPS OPTIONAL
> } WITH SYNTAX {
>  IDENTIFIER 
>  [VALUE ]
>  [PARAMS [TYPE ] ARE  ]
>  [HASHES ]
>  [PUBLIC-KEYS ]
> 
> AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
>  SEQUENCE {
>  algorithm   ALGORITHM-TYPE.({AlgorithmSet}),
>  parameters  ALGORITHM-TYPE.
> ({AlgorithmSet}{@algorithm}) OPTIONAL
>  }
> 
> pk-rsa PUBLIC-KEY ::= {
>  IDENTIFIER rsaEncryption
>  KEY RSAPublicKey
>  PARAMS TYPE NULL ARE absent
>  -- Private key format not in this module --
>  CERT-KEY-USAGE {digitalSignature, nonRepudiation,
>  keyEncipherment, dataEncipherment, keyCertSign, cRLSign}
> }
> 
> Hence, the correct encoding is for NULL to be absent.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

[TLS] FW: [Cfrg] ISE needs reviewers/ reviews for draft-harkins-tls-dragonfly-00

[Jim Schaad]

This may be a more relevant list to try and get reviewers on.  Please think
about doing a review.

Jim


> -Original Message-
> From: Cfrg [mailto:cfrg-boun...@irtf.org] On Behalf Of Nevil Brownlee
> Sent: Tuesday, September 06, 2016 4:06 PM
> To: c...@irtf.org; ISE 
> Subject: [Cfrg] ISE needs reviewers/ reviews for
draft-harkins-tls-dragonfly-00
> 
> 
> Hi CFRG folk:
> 
> Dan Harkins has submitted this draft to the Independent Stream, so now I'm
> looking for reviews of it.  Any comments on this draft, especially in the
form of
> brief reviewers - or offers to do a full review - would be much
appreciated.
> 
> Please send comments, reviews or offers to review to me, that's ISE  i...@rfc-editor.org>
> 
> Cheers, Nevil
> 
> --
> Nevil Brownlee (ISE), rfc-...@rfc-editor.org
> 
> ___
> Cfrg mailing list
> c...@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

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

Re: [TLS] KeyUpdate and unbounded write obligations

[Jim Schaad]

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Keith Winstein
> Sent: Thursday, August 18, 2016 11:21 AM
> To: David Benjamin 
> Cc: tls@ietf.org
> Subject: Re: [TLS] KeyUpdate and unbounded write obligations
> 
> It sounds like there are four properties in play here:
> 
> P1: Either side can rekey its outgoing traffic whenever it wants.
> 
> P2: Either side can "force an update to the entire connection," i.e.
> can ask the other side to rekey *its* outgoing traffic.
> 
> P3: A side can learn that P1 has been read by the other side.

If you are not getting any traffic back, it seems that this might a problem.
P1 + P3 causing P4.  Unless you are willing to not know the difference
between traffic getting lost and traffic being processed.

Jim

> 
> P4: Neither side can cause the other to accrue an unbounded deferred write
> obligation; in fact the maximum accruable deferred write obligation is one
> KeyUpdate.
> 
> The current draft has P1 and P2 only.
> 
> My view: all four properties are important.
> 
> I've previously argued for the benefit of P3.
> 
> Re: P2, there seems to be some disagreement about the value. I think it is
-- one
> endpoint may well have knowledge (about the traffic or its future
susceptibility
> to compromise) that makes it want to ratchet the session. Forward secrecy
is
> not only valuable to the sender. I don't think it's enough to recommend
that
> each side rekey its own direction occasionally.
> 
> I don't think it's a particularly hard design or implementation challenge
to get all
> four properties.
> 
> Here a simple explicit and verbose design as a straw-man, that gets P1,
P2, P3,
> and P4:
> 
> 1) As David proposes, separate the tracks and have two KeyUpdate ladders.
> 
> 2) Define KeyUpdate like this:
> 
>struct {
>uint64 desired_minimum_receive_generation;
>uint64 current_receive_generation;
>} KeyUpdate;
> 
> Language: "An implementation MAY update its send keys by sending a
> KeyUpdate. An implementation MAY request that the other side update its
send
> keys by increasing the desired_minimum_receive_generation. An
> implementation MUST NOT set desired_minimum_receive_generation to be
> greater than its current_receive_generation plus one."
> 
> "Upon receiving a KeyUpdate, the receiver MUST increment their receiving
> generation by one. If the desired_minimum_receive_generation
> is greater than its current send generation, the receiver MUST update its
send
> keys and send a KeyUpdate. If the desired_minimum_receive_generation is
> greater than the current send generation plus one, the receiver SHOULD
abort."
> 
> -Keith
> 
> On Thu, Aug 18, 2016 at 10:26 AM, David Benjamin 
> wrote:
> > On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk 
> wrote:
> >>
> >> On 08/17/2016 11:29 PM, David Benjamin wrote:
> >>
> >> However, we lose the "free" (really at the cost of this unboundedness
> >> problem) generation-based bidirectional KeyUpdate sync. Depending on
> >> what we want out of KeyUpdate, I can imagine a few options:
> >>
> >>
> >> My recollection is that the only reason we have KeyUpdate is to avoid
> >> going over the limit for amount of ciphertext encrypted in the same
> >> key within our safety margin (recall the analyses debating whether
> >> such limits would even be reachable for the ciphers currently in use,
> >> as well as the disagreement as to what the safety margin should be).
> >>
> >>
> >> - Don't. KeyUpdates are unilateral. Recommend in the spec to
> >> KeyUpdate every N records or so and leave it at that. (I think this
> >> is the best option on grounds of simplicity, assuming it meets the
> >> primary needs of KeyUpdate.)
> >>
> >>
> >> If we're in a world where implementations are considering leaving out
> >> the required "catch up" KeyUpdate, we may want to consider
> >> alternative options to put in the spec that are easier to implement.
> >> That is, we can write the spec in various ways to get the
> >> functionality that both write directions get the key updates needed
> >> to avoid the ciphertext limit, and we are reliant on implementations to
follow
> the spec in order to get that safety property.
> >> So, given that we can only get the safety property if all
> >> implementations follow the spec, why not just ... require
> >> implementations to track the amount sent and rekey if it's too close
> >> to the limit?  That is consistent with a unilateral/unidirectional
> >> KeyUpdate, and having per-connection byte/record counters does not seem
> to be a huge overhead.
> >>
> >> Keeping the two write directions' keys independent would also avoid
> >> conflict when the two peers disagree on how often a rekey is
> >> necessary (as might happen if a resource-constrained device decided
> >> to not implement byte counters and just rekey after every N records,
> >> which is "free" since you need to track serial numbers anyway).
> >
> >
> 

Re: [TLS] PR #493: Multiple concurrent tickets

[Jim Schaad]

What about the choice of, randomly use any of the tickets but don’t re-use a 
ticket?  I am not sure why using them in a specific order is better or worse.  
Even if you assign a specific ticket to a reconnect, I would expect that timing 
of issues might make the server see the tickets out of order so that it needs 
to deal with the fact that they come in randomly. 

 

Jim

 

 

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Saturday, June 04, 2016 8:51 AM
To: tls@ietf.org
Subject: [TLS] PR #493: Multiple concurrent tickets

 

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

 

Currently the server can send multiple tickets but we don't say anything about 
the semantics.

So, say a server sends tickets T_1, T_2, T_3... T_n, and the client wants to 
initiate m < n connections, should he use:

 

- only T_n

- T_1...T_m

- T_n, T_n-1, ... T_n-m+1

 

The intuition I have had is that we want the third option (latest wins, but 
allow multiples for linkability) but the spec doesn't say and there aren't any 
semantics that tell you, so I think we want some way for the server to say 
"these group of tickets are all co-valid".

 

I've just created PR#493, which provides an explicit mechanism for this, 
"ticket generations". Tickets with the same generation M are co-valid and a 
ticket with generation N expires all tickets with generation M < N. The nice 
thing about this encoding is that a client can implement the old "one ticket at 
a time" behavior by just ignoring the generation and taking the last ticket.

 

I wanted to call out to cryptographers/analysts that this formalizes the 
existing practice (going back to RFC 5077) of having multiple ticket values 
tied to the same basic secret (though less so with 1.3 because tickets issued 
on connection N+1 don't have the same RMS as those on connection N). If there 
is a problem with this, that would be good to know.

 

Barring major objections, I'll merge this Thursday.

 

 

-Ekr

 

 

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

Re: [TLS] NewSessionTicketFormat - for PSK

[Jim Schaad]

 

 

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Monday, April 25, 2016 11:10 AM
To: Jim Schaad <i...@augustcellars.com>
Cc: tls@ietf.org
Subject: Re: [TLS] NewSessionTicketFormat - for PSK

 

 

 

On Mon, Apr 25, 2016 at 11:07 AM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

I was looking at how TLS 1.3 was going to fit into an upgrade from the
existing 1.2 version that is used for RADIUS and having vague memories of
what was going on during the F2F meeting and I ended up with the following
question.

We are planning to indicate in the NewSessionTicket items such as if early
data is going to be allowed.  Do we need to make some statements someplace
about if early data is going to be accepted for a pure PSK (or PSK-ECDH)
configuration either as an marker that it needs to be configured into the
client or as a indication sent back from the server to the client that it
will or will not accept early data when connecting?  

 

There is no way to do do early data with PSK-ECDH because the data is

encrypted under the PSK only.

 

-Ekr

 

What about the case of just pure PSK?  

 

I also assume that there is nothing to stop from getting a ticket if I connect 
using PSK to begin with.

 

Jim

 

 

 

 Does this apply to
some of the other fields that were being discussed as being encoded into the
ticket as well?

Jim


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

 

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

[TLS] Analysis of encrypting the headers - what is the length

[Jim Schaad]

I will start by re-iterating my initial position that I would prefer that
the DTLS and TLS analysis is going to be the same in terms of masking the
header information.  So I decided to do some thought experiments about what
happens if the length were to be encrypted and how many different situations
does this not appear to help the situation.

DTLS  - Given that most DTLS situations are going to want to keep the block
of data sent small, there is no to little incentive to send multiple DTLS
blocks in a single UDP packet.  This means that the length of the encrypted
data is going to be easily found based on the length of the UDP packet.
One can probably make some significantly accurate guesses about what the
header fields are going to be for a DTLS packet, but I would assume that
even if the key could be determined it would not compromise the keys used in
protecting the D/TLS content itself.

TLS w/ lock step protocol - Think about using TLS with a lock step protocol
such as exists for POP where you always have a situation where the client
sends a request and the server sends a response.  Even with the length field
encrypted a traffic analysis is going to be able to determine the length of
all of many of the messages based on the amount of data that is flowing from
each of the end-points.  Thus with POP I can make a good guess about the
length your password just by looking at the traffic being sent in terms of
raw byte counts even without the length being directly available.

TLS w/ time breaks between operations - Think about doing browsing on a web
site.  I read a page, which takes time, and then I click a link.  Looking
just at the traffic flow I can make a really good guess about the length of
the link that you just sent to the server based on the number of bytes that
are sent from the client to the server before the server starts chattering.
Any protocol where there are going to be times where there is silence
followed by a request and then responses is going to all for a relatively
easy guess about the length of the request based just on the number of bytes
in the stream.

These are all situations where if one say - My attack model is that exposing
the length of the encrypted data allows the attacker to obtain significant
information about what I am sending - then the simple expedient of
encrypting the header information is clearly insufficient to deal with the
attack proposed.  Additional steps need to be taken as well.  For example
sending all of the randomly updating adware back on the same TLS channel to
prevent time breaks from occurring.  (What a horrid idea of using adware as
a method of preventing attacks.)

I believe that this is the type of analysis that Peter is looking for in
terms of what is the attack you are trying to prevent, what does the
proposed remedy actually do what you think it does.  The situations above
would all appear to be better dealt with padding of the plain text in some
manner rather than encrypting the length field.

Jim


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

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Jim Schaad]

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Jacob Appelbaum
> Sent: Monday, November 30, 2015 5:36 PM
> To: tls@ietf.org
> Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after
all?
> 
> On 12/1/15, Viktor Dukhovni  wrote:
> > On Mon, Nov 30, 2015 at 10:34:27AM +, Peter Gutmann wrote:
> >
> >> Bryan A Ford  writes:
> >>
> >> >It would work just as well and in exactly the same way if the AEAD
> >> >is replaced with the traditional Encrypt-then-MAC construction, for
> >> >example.
> >>
> >> No it wouldn't, unless the encrypt part is a stream cipher.  You're
> >> still locked into using an AEAD stream cipher or the equivalent of an
> >> AEAD stream cipher built with encrypt+MAC.  It won't work with, for
> >> example, the OCB AEAD mode, or CBC + MAC.
> >
> > I think we should focus on what would get TLS 1.3 to be adopted:
> >
> > * Reasonably implementable in libraries that support older
> >   versions alongside TLS 1.3.
> >
> 
> That doesn't change with Bryan's suggestion, I think.
> 
> > * Interoperable in the field with various capital-intensive
> >   middle boxen.
> 
> Which would those be? And what is the definition of capital-intensive for
those
> watching on the sidelines?
> 
> >
> > This suggests focusing on solidifying the core protocol, and a healthy
> > dose of skepticism around bells and whistles.  If the protocol is
> > overloaded with too many (alright even more) incompatible innovations,
> > the net effect is likely less security due to substantially delayed
> > deployment of the key improvements.
> 
> This seems borderline absurd. The TLS protocol is doing a major version
revision.
> 
> > Encrypting message lengths looks rather marginal from this
> > perspective, and quite likely to hinder interoperability and delay
> > both implementation and upgrades.  However cool an idea this might be,
> > this does not look to me like the right time to add this feature to
> > TLS.
> 
> I don't think it will hinder interoperability and not one person has even
named a
> single device that would have issues with it. I think the only thing that
comes
> close is when I've named a classified US government surveillance program
> (XKeyscore) that would probably have trouble with it.
> 
> We should add Bryan's feature and not pander to non-specific concerns
about
> middleboxes that should be considered as adversaries.
> 
> >
> > At this point, TLS 1.3 is rather feature rich, and it is I think time
> > to focus on reviewing the already agreed changes (maybe even drop some
> > if they look inessential).  Make it solid, trim the fat, get it out
> > the door in a usable form.
> 
> That is part of what is happening in Bryan's suggestion. He found a
reasonably
> practical way to encrypt record headers. His suggestion will make TLS more
> secure. His suggestion includes a review of a part of the previous state
of TLS
> 1.3 with a proposed improvement.

I would strongly prefer that the analysis for TLS and DTLS no be too
different.  This approach will not work for DTLS given that packets can
arrive out of order and multiple times.

Jim

> 
> No one is debating it on the cryptographic merits which is surprising.
> 
> All the best,
> Jacob
> 
> ___
> 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