[TLS] TLS 1.3 comments

[Yaron Sheffer]

  
  
Below a long list of comments, generally minor. The document is
already very good - we're making great progress!

  The record length field is limited by encrypted-length+2048.
Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an
expansion of greater than 1024 bytes".
  6: the definition of session contents should also contain
identities. The client's identity, if authenticated by cert, or
the peers' PSK identity.
  "Access denied" alert: the description starts with "a valid
certificate was received", but it may also apply to PSK.
  Handshake_failure alert seems to be synonymous with
insufficient_security (and Sec. 6.2.1 proves it...). Can we
clarify the difference, or deprecate one of them?
  Typo: "via a certificates".
  Server Configuration: how does the client know to whom the
configuration applies? For example if I connected to
"*.example.com" (a wildcard cert) and now I connect to
"srv.example.com", should I use the stored configuration?
  6.2.2: typo: has complete.
  6.3.2.3.2: it's time we specified that the recipient (in this
case, the server) MUST verify the received ECDHE public key (see
RFC 6989). This is mentioned in Appendix D but only for modular
DH.
  6.3.2.4: "identifier" should read "identity".
  6.3.4: "Perhaps have a whitelist of which extensions can be
unencrypted and everything else MUST be encrypted." - this
doesn't work, because we might come up in the future with an
extension that needs to be unprotected. Maybe we can say
"SHOULD" instead.
  6.3.7: expiration_date: there's no reason to force/assume time
synchronization between client and server. This can just as well
be relative time (number of seconds since negotiation), like
ticket_lifetime_hint.
  6.3.10: "If the client does not send any certificates, the
server MAY at its discretion either continue the handshake
without client authentication ... Also, if some aspect of the
certificate chain was unacceptable ... the server MAY at its
discretion either continue the handshake (considering the client
unauthenticated) or send a fatal alert." This is strange. There
is no way for the client to understand that the server considers
it unauthenticated and modify its behavior accordingly. A
warning alert would be appropriate here, even if in general we
don't like warning alerts.
  Typo: main-in-the-middle
  "Note that using non-anonymous key exchange without actually
verifying the key exchange is essentially equivalent to
anonymous key exchange, and the same precautions apply. " This
is not precisely true, because the other peer may not know that
you're not verifying the exchange, and so it might behave
differently.
  D.1.2: do we really need to worry about version rollback to
SSLv2? I suggest to remove this section.

Thanks,
    Yaron
  


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

Re: [TLS] TLS 1.3 comments

[Ilari Liusvaara]

On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:
> 
> Below a long list of comments, generally minor. The document is
> already very good - we're making great progress!

>   The record length field is limited by encrypted-length+2048.
> Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an
> expansion of greater than 1024 bytes".

Actually, I think both should be 256 (256-byte expansion from AEAD
is already quite much).

(This was proposed a while back).

>   6: the definition of session contents should also contain
> identities. The client's identity, if authenticated by cert, or
> the peers' PSK identity.

There is lots more missing as well, like symmetric crypto keys,
TLS-Exporter secret and TLS-Unique value.

IIRC the answer when I brought that up was that the whole thing
should be removed.

>   "Access denied" alert: the description starts with "a valid
> certificate was received", but it may also apply to PSK.

Agreed. Authorization failure.

>   Handshake_failure alert seems to be synonymous with
> insufficient_security (and Sec. 6.2.1 proves it...). Can we
> clarify the difference, or deprecate one of them?

>From my reading, the difference would be that if some negotiating
some required algorithm failed because none of the options is supported
at all, it is handshake_failure. If some algorithms would have been
supported but are disabled, it is insufficient_security.

Not sure if that makes any actual sense.

>   Server Configuration: how does the client know to whom the
> configuration applies? For example if I connected to
> "*.example.com" (a wildcard cert) and now I connect to
> "srv.example.com", should I use the stored configuration?

It actually gets more interesting when one has multiple potentially
applicable configurations and needs to tiebreak.

If there is only one config known, not much problem in trying that.

>   6.3.2.3.2: it's time we specified that the recipient (in this
> case, the server) MUST verify the received ECDHE public key (see
> RFC 6989). This is mentioned in Appendix D but only for modular
> DH.

There is actually two kinds of verification:
- Validating received point is on curve.
- Validating that the received point is high-order.

CFRG Curve25519 and Curve448 specify the needed checks here.

As for Weierstrass stuff, some ECC libs have surprising presentations
for infinity (which is order-1) and allow importing invalid points, so
one has to be careful even with h=1.

>   6.3.4: "Perhaps have a whitelist of which extensions can be
> unencrypted and everything else MUST be encrypted." - this
> doesn't work, because we might come up in the future with an
> extension that needs to be unprotected. Maybe we can say
> "SHOULD" instead.

The registration procedure is "IETF consensus", so RFC updates: might
not work.

Also, it is unclear if extensions that introduce new messages or
otherwise modify the handshake after EncrpytedExtensions are to be in
ServerHello or EncryptedExtensions.

>   6.3.7: expiration_date: there's no reason to force/assume time
> synchronization between client and server. This can just as well
> be relative time (number of seconds since negotiation), like
> ticket_lifetime_hint.

IIRC, the reason why it was that was was publishing configurations off-band.

Also, I don't like that field being 32-bit if it is absolute time (even
if it isn't signed).

>   D.1.2: do we really need to worry about version rollback to
> SSLv2? I suggest to remove this section.

Well, it is not possible to even try to negotiate TLS 1.3 using SSLv2
compat. hello, since that can't transmit extensions, but at least one
extension is REQUIRED in order to successfully negotiate TLS 1.3.

And the second paragraph seems to be about RSA key exchange, which
isn't supported anymore in TLS 1.3.

Yes, the section looks like it could be removed.

But that isn't the only way rollback attacks can occur, also some
clients can be coaxed to downgrade by selectively blocking connections.
Unfortunately the intolerance to TLS 1.3 is so bad that many clients
will likely be willing to perform unauthenticated downgrade to TLS
1.2 (and FALLBACK_SCSV is useless here).



-Ilari

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Peter Gutmann]

So apart from being an interesting paper, it also points out (yet again) that
TLS has wy too many baggage suites and mechanisms that provide nothing but
an attack vector (it's not unique in this regard, other protocols also carry
around a vast amount of baggage and unnecessary flexibility whose only
apparent use is attack vectors, because certainly no implementation seems to
be using it.  SSH springs immediately to mind, TLS has all the baggage suites
and SSH has the unnecessary flexibility).

One thing that I'd really like to know is that given the non-PFS (EC)DH suites
were obviously a dumb idea and barely supported by anything (not just in terms
of TLS code, no public CA I know of will issue the required X9.42 certs,
although as the paper points out you can get ECDH ones that can be misused),
why did OpenSSL add support for them as late as 1.0.2?  Does anyone know why
they were added?

Peter.


From: Clemens Hlauschek [clemens.hlausc...@rise-world.com]
Sent: Wednesday, 12 August 2015 11:15
To: Peter Gutmann; tls@ietf.org
Subject: Re: [TLS] TLS and KCI vulnerable handshakes

On 08/11/2015 02:05 PM, Peter Gutmann wrote:
> Clemens Hlauschek  writes:
>
>> I published a paper today on KCI-attacks in TLS. This might be of interest to
>> the TLS WG.
>>
>> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
>
> Some comments on this, it looks like it requires a "cert with static (EC)DH
> key" in order to work, which would mean an X9.42 cert.  Since no (public) CA
> that I know of can handle or issue such certs, this probably provides a
> reasonable amount of defence against this attack...



Thanks for the critical reading. Actually, your point is touched upon in
the paper. Instead of an ECDH certificate, an ECDSA certificate can be
used by the attacker. The case for DH/DSS is different, and your point
is valid for this latter case. I am working on a video showcasing the
attack (Safari <-> Facebook), but if you decide that you still would not
trust our claims made in the paper, it would be trivial to reproduce the
attack: our MitM proof-of-concept implementation was realized with less
than 10 patched lines of the openssl/stunnel codebase.


See also RFC 4492:
"Note that there is no structural difference between ECDH and ECDSA
keys.  A certificate issuer may use X.509 v3 keyUsage and
extendedKeyUsage extensions to restrict the use of an ECC public key
to certain computations"

>
> In terms of the suggested countermeasures:
>
>> Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and
>> disable specifically the KeyAgreement flag
>
> Since the keyUsage flags are widely ignored by implementations, this won't
> provide the protection that the text implies.
>


In case of the vulnerable Safari / SecureTransport / Mac OS X clients,
it does make a difference, so having correct X509 KeyUsage settings is
the best (and only sensible for servers supporting ECDSA) recommendation
for server-side mitigation, from our perspective. The facebook.com
security teams very quickly implemented that change. While it is
certainly true that keyUsage flags are ignored by many implementations
(this is also mentioned in the paper), checking (it is ambiguous
according to the TLS specs whether it is mandatory for ECDH, but it is
mandatory for DH if the KeyUsage extension is present) seems to have
become more widespread recently.


Best,
Clemens

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

Re: [TLS] TLS Handshake message length too long

[Hubert Kario]

On Sunday 09 August 2015 16:41:19 dott...@gmail.com wrote:
> I have a question regarding the handshake message length.
> 
> The 'decode_error' alert in TLS 1.2 is defined as:
> 
>decode_error
>   A message could not be decoded because some field was out of the
>   specified range or the length of the message was incorrect. (...)
> 
> It says that the message "could not be decoded". What should happen
> if the specified message length is longer than needed? I.e. the message
> was successfully decoded, but the length of the message was incorrect:
> there is still some unknown data after the defined structure.

that is definitely error for the case of a "length of a field is longer than 
expected" or "there's more data in message than the length specifies"
 
> For example, a Finished message has a length of 40 bytes,
> but the 'verify_data' array has 32 bytes and there are 8 unknown bytes
> remaining in the received message. The 40 bytes I talk about here
> is the length specified in the Handshake message header.
> 
> Is this also a fatal error?

yes, always

> Should the implementation just drop those bytes and proceed?

definitely not, it should send a fatal alert, close connection and mark 
session as non resumable

> On the other hand, there is the 'illegal_parameter' alert:
> 
>illegal_parameter
>   A field in the handshake was out of range or inconsistent with
>   other fields.  This message is always fatal.
> 
> Is this alert suitable for the described scenario?

no, it's for values that are explicitly bound to some specific range (e.g. 
client_random length tag always needs to be 32)

verify_data has no range specified (it's opaque data), the negotiatied 
ciphersuite defines what length it has
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS epoch and resume session/handshake

[Simon Bernard]

I'm sorry to insist, but What did you mean by transport level connection 
? For me UDP was a connectionless protocol.


Simon

Le 31/07/2015 18:53, Eric Rescorla a écrit :



On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard 
mailto:cont...@simonbernard.eu>> wrote:


Thx.
What did you mean by connection ?


transport level connection.

A resume handshake is a new connection ?


You can also resume when you renegotiate.

-Ekr


Le 31/07/2015 16:54, Eric Rescorla a écrit :

The epoch is set to 0 at the start of each connection and then
incremented
with each handshake on that connection.

-Ekr

On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard
mailto:cont...@simonbernard.eu>
>> wrote:

Hi,

  I search in DTLS RFC 6347 if the epoch should be (re)set
to 0
when we start a resume handshake, or if we keep the last used
value, or the last used value+1 ? I can not any clue of
that in
the spec.
  Any idea ?

Thx
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] DTLS epoch and resume session/handshake

[Eric Rescorla]

Please see RFC 6347 S 4.2.8

-Ekr


On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard 
wrote:

> I'm sorry to insist, but What did you mean by transport level connection ?
> For me UDP was a connectionless protocol.
>
> Simon
>
>
> Le 31/07/2015 18:53, Eric Rescorla a écrit :
>
>
>
> On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard 
> wrote:
>
>> Thx.
>> What did you mean by connection ?
>>
>
> transport level connection.
>
>
>
>> A resume handshake is a new connection ?
>
>
> You can also resume when you renegotiate.
>
> -Ekr
>
>
>> Le 31/07/2015 16:54, Eric Rescorla a écrit :
>>
>>> The epoch is set to 0 at the start of each connection and then
>>> incremented
>>> with each handshake on that connection.
>>>
>>> -Ekr
>>>
>>> On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard >> > wrote:
>>>
>>> Hi,
>>>
>>>   I search in DTLS RFC 6347 if the epoch should be (re)set to 0
>>> when we start a resume handshake, or if we keep the last used
>>> value, or the last used value+1 ? I can not any clue of that in
>>> the spec.
>>>   Any idea ?
>>>
>>> Thx
>>> 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] TLS 1.3 comments

[Hubert Kario]

On Monday 17 August 2015 15:02:46 Ilari Liusvaara wrote:
> On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:
> > Below a long list of comments, generally minor. The document is
> > already very good - we're making great progress!
> > 
> >   The record length field is limited by encrypted-length+2048.
> >   
> > Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an
> > expansion of greater than 1024 bytes".
> 
> Actually, I think both should be 256 (256-byte expansion from AEAD
> is already quite much).
> 
> (This was proposed a while back).

I don't think this adds anything while introducing requirement of adding 
additional "if" to implementations that support also TLS1.2 and lower

> >   D.1.2: do we really need to worry about version rollback to
> >   
> > SSLv2? I suggest to remove this section.
> 
> Well, it is not possible to even try to negotiate TLS 1.3 using SSLv2
> compat. hello, since that can't transmit extensions, but at least one
> extension is REQUIRED in order to successfully negotiate TLS 1.3.
> 
> And the second paragraph seems to be about RSA key exchange, which
> isn't supported anymore in TLS 1.3.
> 
> Yes, the section looks like it could be removed.

OTOH, TLS1.3 is not a superset of TLS1.2 so we need to think about downgrade 
to TLS1.2. 

> But that isn't the only way rollback attacks can occur, also some
> clients can be coaxed to downgrade by selectively blocking connections.
> Unfortunately the intolerance to TLS 1.3 is so bad that many clients
> will likely be willing to perform unauthenticated downgrade to TLS
> 1.2 (and FALLBACK_SCSV is useless here).

how is it useless?

A server which support at most TLS1.2 that receives a TLS1.2 client hello with 
FALLBACK_SCSV MUST continue the connection with TLS1.2
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS and KCI vulnerable handshakes

[Viktor Dukhovni]

On Mon, Aug 17, 2015 at 12:38:54PM +, Peter Gutmann wrote:

> One thing that I'd really like to know is that given the non-PFS (EC)DH suites
> were obviously a dumb idea and barely supported by anything (not just in terms
> of TLS code, no public CA I know of will issue the required X9.42 certs,
> although as the paper points out you can get ECDH ones that can be misused),
> why did OpenSSL add support for them as late as 1.0.2?  Does anyone know why
> they were added?

I can't answer why, but I know what and when:

The cipher-suites that were added to 1.0.2 were fixed finite-field
DH ciphers, not fixed ECDH.

DH-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AESGCM(256) Mac=AEAD
DH-DSS-AES256-SHA   SSLv3 Kx=DH/DSS   Au=DH   Enc=AES(256)  Mac=SHA1
DH-DSS-AES256-SHA256TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AES(256)  Mac=SHA256
DH-DSS-CAMELLIA256-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=Camellia(256) Mac=SHA1
DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AESGCM(256) Mac=AEAD
DH-RSA-AES256-SHA   SSLv3 Kx=DH/RSA   Au=DH   Enc=AES(256)  Mac=SHA1
DH-RSA-AES256-SHA256TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AES(256)  Mac=SHA256
DH-RSA-CAMELLIA256-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=Camellia(256) Mac=SHA1
DH-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AESGCM(128) Mac=AEAD
DH-DSS-AES128-SHA   SSLv3 Kx=DH/DSS   Au=DH   Enc=AES(128)  Mac=SHA1
DH-DSS-AES128-SHA256TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AES(128)  Mac=SHA256
DH-DSS-CAMELLIA128-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=Camellia(128) Mac=SHA1
DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS   Au=DH   Enc=SEED(128) Mac=SHA1
DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AESGCM(128) Mac=AEAD
DH-RSA-AES128-SHA   SSLv3 Kx=DH/RSA   Au=DH   Enc=AES(128)  Mac=SHA1
DH-RSA-AES128-SHA256TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AES(128)  Mac=SHA256
DH-RSA-CAMELLIA128-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=Camellia(128) Mac=SHA1
DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA   Au=DH   Enc=SEED(128) Mac=SHA1
DH-DSS-DES-CBC3-SHA SSLv3 Kx=DH/DSS   Au=DH   Enc=3DES(168) Mac=SHA1
DH-RSA-DES-CBC3-SHA SSLv3 Kx=DH/RSA   Au=DH   Enc=3DES(168) Mac=SHA1
DH-DSS-DES-CBC-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=DES(56)   Mac=SHA1
DH-RSA-DES-CBC-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=DES(56)   Mac=SHA1

The relevant code was added to the 1.0.2 dev branch in Apr of 2012,
backporting said code from the "master" branch where fixed DH
support was enabled in January of 2012.

On a related note, for what it's worth ECDSA certs are constrained
by keyUsage if the extension is present.

-- 
Viktor.

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Viktor Dukhovni]

On Mon, Aug 17, 2015 at 03:18:14PM +, Viktor Dukhovni wrote:

> The relevant code was added to the 1.0.2 dev branch in Apr of 2012,
> backporting said code from the "master" branch where fixed DH
> support was enabled in January of 2012.
> 
> On a related note, for what it's worth ECDSA certs are constrained
> by keyUsage if the extension is present.

My thoughts on these from the openssl-team list (non-public) from
May of 2015:

  * Remove.  Frankly, I think all the static DH ciphers (even non-export)
are useless bloat.  Nobody uses them, and they lead to large client
HELLO messages, and interop issues.

I'd like to see them all deprecated, that'd be 42 fewer useless
ciphersuites.

  * > Oh - except DH only. I think we need to keep static ECDH. I've been told
> there are some servers out there that are configured to do static ECDH
> with their ECDSA cert.

Whatever for?  Why go to all that trouble to defeat forward secrecy?

And now there are additional reasons to drop support for these from
"master".  Making incompatible changes in 1.0.2 patch releases is
perhaps not an option (unless removal of DHr/DHd/ECDHr/ECDHe can
be reasonably positioned as a bug fix).

-- 
Viktor.

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Peter Gutmann]

Viktor Dukhovni  writes:

>I can't answer why, but I know what and when:

I was trying to avoid finger-pointing so I didn't go through the changelog to
see whodunnit, I was more interested in the motivation.  Same for Apple, why
would you implement something that pretty much no-one else (at the time)
supported, and for good reason?

Having said that though:

DH-DSS-CAMELLIA256-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=Camellia(256) Mac=SHA1
DH-DSS-CAMELLIA128-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=Camellia(128) Mac=SHA1
DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS   Au=DH   Enc=SEED(128) Mac=SHA1
DH-DSS-DES-CBC-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=DES(56)   Mac=SHA1
DH-RSA-DES-CBC-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=DES(56)   Mac=SHA1

that sort of stuff just compounds the WTF.  Static DH + DSA + single DES, added 
in 2012.
W. T. F.

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Salz, Rich]

> I was more interested in the motivation.  Same for Apple,
> why would you implement something that pretty much no-one else (at the
> time) supported, and for good reason?

Perhaps because this was a year before Snowden and the mindset was 
unquestioning complete RFC implementation?

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Viktor Dukhovni]

On Mon, Aug 17, 2015 at 03:53:59PM +, Peter Gutmann wrote:
> Viktor Dukhovni  writes:
> 
> >I can't answer why, but I know what and when:
> 
> I was trying to avoid finger-pointing so I didn't go through the changelog to
> see whodunnit, I was more interested in the motivation.  Same for Apple, why
> would you implement something that pretty much no-one else (at the time)
> supported, and for good reason?
> 
> Having said that though:
> 
> DH-DSS-CAMELLIA256-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=Camellia(256) Mac=SHA1
> DH-DSS-CAMELLIA128-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=Camellia(128) Mac=SHA1
> DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS   Au=DH   Enc=SEED(128) Mac=SHA1
> DH-DSS-DES-CBC-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=DES(56)   Mac=SHA1
> DH-RSA-DES-CBC-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=DES(56)   Mac=SHA1
> 
> that sort of stuff just compounds the WTF.  Static DH + DSA + single DES, 
> added in 2012.
> W. T. F.

The mechanics of how it happened are simple enough.  The ciphers
were there all along for around a decade or so, but they were all
disabled because the key exchage method was not implemented.

What happened in 2012 is that the key exchange got implemented, so
presto-magic a new single-DES fixed-DH cipher.

I'd like to see more attention paid to changes that explicitly or
implicitly introduce new ciphers that fall into the WTF category.

I hope we'll be able to exercise more discretion going forward.

That said, has https://tools.ietf.org/html/rfc5469 been sufficiently
well publicized?  I've seen a lot of discussion around the deprecation
of RC4, but DES and IDEA seem to have lingered on...

--
Viktor.

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

Re: [TLS] DTLS epoch and resume session/handshake

[Simon Bernard]

I re-readed this paragraph and it's still not clear, what did you mean 
by connection at transport layer for UDP.


I well understand that if a server receive a clientHello with epoch=0, 
this means that a new handshake should be done.


But I still don't know what happends in a ResumeHandshake use case.

In fact, my use case is a client behind a NAT which communicate 
periodically. at each period, its IP/Port could changed (because of 
NAT), so we would like to resume handshake each time.

1) Does it make sense ?
2) If yes, should we do the resume handhsake with epoch = 0 or continue 
with previous epoch ?



Le 17/08/2015 16:24, Eric Rescorla a écrit :

Please see RFC 6347 S 4.2.8

-Ekr


On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard 
mailto:cont...@simonbernard.eu>> wrote:


I'm sorry to insist, but What did you mean by transport level
connection ? For me UDP was a connectionless protocol.

Simon


Le 31/07/2015 18:53, Eric Rescorla a écrit :



On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard
mailto:cont...@simonbernard.eu>> wrote:

Thx.
What did you mean by connection ?


transport level connection.

A resume handshake is a new connection ?


You can also resume when you renegotiate.

-Ekr


Le 31/07/2015 16:54, Eric Rescorla a écrit :

The epoch is set to 0 at the start of each connection and
then incremented
with each handshake on that connection.

-Ekr

On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard
mailto:cont...@simonbernard.eu>
>> wrote:

Hi,

  I search in DTLS RFC 6347 if the epoch should be
(re)set to 0
when we start a resume handshake, or if we keep the
last used
value, or the last used value+1 ? I can not any clue
of that in
the spec.
  Any idea ?

Thx
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] DTLS epoch and resume session/handshake

[Eric Rescorla]

On Mon, Aug 17, 2015 at 9:20 AM, Simon Bernard 
wrote:

> I re-readed this paragraph and it's still not clear, what did you mean by
> connection at transport layer for UDP.
>
> I well understand that if a server receive a clientHello with epoch=0,
> this means that a new handshake should be done.
>
> But I still don't know what happends in a ResumeHandshake use case.
>
> In fact, my use case is a client behind a NAT which communicate
> periodically. at each period, its IP/Port could changed (because of NAT),
> so we would like to resume handshake each time.
> 1) Does it make sense ?
> 2) If yes, should we do the resume handhsake with epoch = 0 or continue
> with previous epoch ?
>

Resumption isn't relevant here.

If you are renegotiating (i.e., the ClientHello will be encrypted under a
previous cipher
suite) then you have epoch > 0. Otherwise, epoch = 0.

-Ekr


>
> Le 17/08/2015 16:24, Eric Rescorla a écrit :
>
> Please see RFC 6347 S 4.2.8
>
> -Ekr
>
>
> On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard 
> wrote:
>
>> I'm sorry to insist, but What did you mean by transport level connection
>> ? For me UDP was a connectionless protocol.
>>
>> Simon
>>
>>
>> Le 31/07/2015 18:53, Eric Rescorla a écrit :
>>
>>
>>
>> On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard 
>> wrote:
>>
>>> Thx.
>>> What did you mean by connection ?
>>>
>>
>> transport level connection.
>>
>>
>>
>>> A resume handshake is a new connection ?
>>
>>
>> You can also resume when you renegotiate.
>>
>> -Ekr
>>
>>
>>> Le 31/07/2015 16:54, Eric Rescorla a écrit :
>>>
 The epoch is set to 0 at the start of each connection and then
 incremented
 with each handshake on that connection.

 -Ekr

 On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard >>> > wrote:

 Hi,

   I search in DTLS RFC 6347 if the epoch should be (re)set to 0
 when we start a resume handshake, or if we keep the last used
 value, or the last used value+1 ? I can not any clue of that in
 the spec.
   Any idea ?

 Thx
 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] TLS 1.3 comments

[Martin Thomson]

On 17 August 2015 at 05:02, Ilari Liusvaara  wrote:
>
> Actually, I think both should be 256 (256-byte expansion from AEAD
> is already quite much).


Pull request or it didn't happen ;)

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

Re: [TLS] TLS 1.3 comments

[Viktor Dukhovni]

On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:

>  * Server Configuration: how does the client know to whom the
>configuration applies? For example if I connected to
>"*.example.com" (a wildcard cert) and now I connect to
>"srv.example.com", should I use the stored configuration?

Clients don't "connect to *.example.com", they connect to a specific
server, one of whose "presented identities" might be "*.example.com".

Since clients don't a priori know which certificates correspond to
which reference identities, they can't apply a configuration to
anything other than the exact peer for which it was obtained.

Section 6.2.2 speaks of "the server", and I think this needs to be
taken literally.  Not some set of servers, but "the server".  Of
course load-balancers might hide multiple servers behind a single
transport end-point, in which case the client may not be able to
distinguish between them, and it is then up to the server administrators
to ensure that any configurations are sufficiently "portable"
between the servers in the pool.

This is similar to the question of when to reuse cached sessions.
Postfix, for example, does not reuse a session established to one
IP address for a multi-homed host, to communicate with "the same"
host on another IP address (which might not in fact be the same
host).  [ Even further, Postfix avoids re-using sessions when the
SMTP conversation prior to STARTTLS shows a different server name
in the EHLO reply. ]

So I think the current language is largely fine, with "the server"
meaning whatever the client uses to identify a single peer as best
it can.

-- 
Viktor.

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

Re: [TLS] TLS 1.3 comments

[Yaron Sheffer]

My original mail had some 15 comments, some trivial, some not. Do you 
expect 15 PRs?


Thanks,
Yaron

On 08/17/2015 10:37 AM, Martin Thomson wrote:

On 17 August 2015 at 05:02, Ilari Liusvaara  wrote:


Actually, I think both should be 256 (256-byte expansion from AEAD
is already quite much).



Pull request or it didn't happen ;)



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

Re: [TLS] TLS 1.3 comments

[Martin Thomson]

Expect? No. That you sent an email is already highly useful.

A PR makes feedback even more useful.  For truly trivial stuff, rolling
them up into a single PR is probably even more so.
On Aug 17, 2015 12:01 PM, "Yaron Sheffer"  wrote:

> My original mail had some 15 comments, some trivial, some not. Do you
> expect 15 PRs?
>
> Thanks,
> Yaron
>
> On 08/17/2015 10:37 AM, Martin Thomson wrote:
>
>> On 17 August 2015 at 05:02, Ilari Liusvaara 
>> wrote:
>>
>>>
>>> Actually, I think both should be 256 (256-byte expansion from AEAD
>>> is already quite much).
>>>
>>
>>
>> Pull request or it didn't happen ;)
>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Fall '15 TLS Interim

[Sean Turner (via Doodle)]

Hi there,

Sean Turner (turn...@ieca.com) invites you to participate in the
Doodle poll "Fall '15 TLS Interim."

This is a doodle poll for a 2-day TLS interim meeting.  We're
currently planning for Seattle, Washington.  The exact location in
Seattle is still TBD, but we've already got two offers.  Please
indicate your availability in the poll by 2015-08-21.  After reviewing
the poll we'll get the more formal announcement out.

Participate now
https://doodle.com/vwq53h5em9igv35e?tmail=poll_invitecontact_participant_invitation_with_message&tlink=pollbtn

What is Doodle? Doodle is a web service that helps Sean Turner to find
a suitable date for meeting with a group of people. Learn more about
how Doodle works.
(https://doodle.com/features?tlink=checkOutLink&tmail=poll_invitecontact_participant_invitation_with_message)

--

You have received this e-mail because "Sean Turner" has invited you to
participate in the Doodle poll "Fall '15 TLS Interim."



Doodle is also available for iOS and Android.


Doodle AG, Werdstrasse 21, 8021 Zürich
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 comments

[Dave Garrett]

On Monday, August 17, 2015 06:22:04 am Yaron Sheffer wrote:
> The record length field is limited by encrypted-length+2048. Shouldn't it be 
> 1024? - "Each AEAD cipher MUST NOT produce an expansion of greater than 1024 
> bytes".

See: https://github.com/tlswg/tls13-spec/issues/55

> Handshake_failure alert seems to be synonymous with insufficient_security 
> (and Sec. 6.2.1 proves it...). Can we clarify the difference, or deprecate 
> one of them?

See: https://github.com/tlswg/tls13-spec/pull/201/commits

A PR for the typos would be appreciated. I'd suggest having the typos in a 
separate PR from any other proposed changes.


Dave


PS
I recommend against citing sections by number. The numbers can change; the 
sections can change completely. Cite by draft number & section, or preferably 
via a link to a section in a page. Also note that there are a few different 
things that can be considered the "latest" draft, so always specify which one 
to be clear. (e.g. numbered draft, GitHub current draft, PR drafts, WIP branch 
drafts, etc.)

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

Re: [TLS] TLS and KCI vulnerable handshakes

[Clemens Hlauschek]

On 08/11/2015 02:05 PM, Peter Gutmann wrote:
> Clemens Hlauschek  writes:
> 
>> I published a paper today on KCI-attacks in TLS. This might be of interest to
>> the TLS WG.
>>
>> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
> 
> Some comments on this, it looks like it requires a "cert with static (EC)DH
> key" in order to work, which would mean an X9.42 cert.  Since no (public) CA
> that I know of can handle or issue such certs, this probably provides a
> reasonable amount of defence against this attack...



Thanks for the critical reading. Actually, your point is touched upon in
the paper. Instead of an ECDH certificate, an ECDSA certificate can be
used by the attacker. The case for DH/DSS is different, and your point
is valid for this latter case. I am working on a video showcasing the
attack (Safari <-> Facebook), but if you decide that you still would not
trust our claims made in the paper, it would be trivial to reproduce the
attack: our MitM proof-of-concept implementation was realized with less
than 10 patched lines of the openssl/stunnel codebase.


See also RFC 4492:
"Note that there is no structural difference between ECDH and ECDSA
keys.  A certificate issuer may use X.509 v3 keyUsage and
extendedKeyUsage extensions to restrict the use of an ECC public key
to certain computations"

> 
> In terms of the suggested countermeasures:
> 
>> Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and
>> disable specifically the KeyAgreement flag
> 
> Since the keyUsage flags are widely ignored by implementations, this won't
> provide the protection that the text implies.
> 


In case of the vulnerable Safari / SecureTransport / Mac OS X clients,
it does make a difference, so having correct X509 KeyUsage settings is
the best (and only sensible for servers supporting ECDSA) recommendation
for server-side mitigation, from our perspective. The facebook.com
security teams very quickly implemented that change. While it is
certainly true that keyUsage flags are ignored by many implementations
(this is also mentioned in the paper), checking (it is ambiguous
according to the TLS specs whether it is mandatory for ECDH, but it is
mandatory for DH if the KeyUsage extension is present) seems to have
become more widespread recently.


Best,
Clemens

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