Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

[Adam Langley]

On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny
 wrote:
>>provokes me to bring it up. Here's the crux of it; is it really a
>>security win to recommend the AEAD cipher suites for TLS 1.2 users?

I'm skeptical about the benefit of padding to 16 bytes. While it does
increase the size classes in your Wikipedia example, Wikipedia pages
trigger subresource loads, which also have a size and page-to-page
navigation leaks more information. My takeaway from reading
traffic-analysis papers over the years is that countermeasures are
surprisingly difficult.

On the other hand, the CBC cipher suites are fundamentally broken,
rather slow and, in an attempt to fix them, are now very complex. So I
don't believe that the benefits of padding to 16 bytes comes close to
justifying the use of the CBC modes. Over the coming years I hope that
CBC modes are killed off in the same fashion that RC4 now has been in
several browsers.

Padding at the application-level (e.g. HTTP) is probably the easiest,
reasonable place to add padding (if there's a scheme with solid
justification). Sure, one doesn't get "automatic" padding that using
CBC modes might (somewhat) get you, but I still don't think CBC is a
good tradeoff.


Cheers

AGL

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

Re: [TLS] Include Speck block cipher?

[Tom Ritter]

On 17 March 2016 at 21:09, Martin Thomson  wrote:
> On 18 March 2016 at 12:37, Mike Hamburg  wrote:
>> No.  The goal should be to remove ciphers, not add new ones, unless we have
>> a really compelling reason.
>
> A necessary, but sufficient set of reasons might include:
>
> 1. thorough cryptanalysis
> 2. advantages over existing ciphers on important metrics like security
> and speed, though this would likely need to be significant at this
> point
> 3. interest in implementation
>
> Speck is 0 from 3.

I might make it .5 for 3. Speck is specifically designed to be a
lightweight cipher for constrained devices. With RC4 dead in the water
- we don't have one of those. (Unless ChaCha20 is better than
Speck/Simon/related...)

That said, we'd still need the other 2.5 - and no, I'm not supporting it either.

-tom

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

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Paterson, Kenny]

Hi

On 16/03/2016 15:02, "TLS on behalf of Watson Ladd"  wrote:

>On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
> wrote:
>> After a number of, uh, gentle reminders from people who have been
>>waiting for
>> this, I've finally got around to posting the TLS-LTS draft I mentioned
>>a while
>> back.  It's now available as:
>>
>> http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt
>>
>> Abstract:
>>
>>This document specifies a profile of TLS 1.2 for long-term support,
>>one that represents what's already deployed for TLS 1.2 but with the
>>security holes and bugs fixed.  This represents a stable, known-good
>>profile that can be deployed now to systems that can't can't roll out
>>patches every month or two when the next attack on TLS is published.
>>
>> Several people have already commented on it off-list while it was being
>> written, it's now open for general comments...
>
>Several comments:



>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more
>extensively analyzed then TLS 1.2. It's almost like you don't believe
>cryptography exists: that is a body of knowledge that can demonstrate
>that protocols are secure, and which has been applied to the draft.

This is patently untrue. There is a vast body of research analysing TLS
1.2 and earlier. A good survey article is here:

https://eprint.iacr.org/2013/049


(but even this is quite out of date in several respects). The literature
for TLS 1.3 is growing, but is an order of magnitude smaller in size. It
is pretty much represented in its entirety by the list of presentations at
the recent TRON workshop:

http://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-n
ot-tron-workshop-programme


As far as I know, the only complete analysis so far is this one:

http://tls13tamarin.github.io/TLS13Tamarin/


(full disclosure: two of my PhD students are involved). However, even
there, the analysis is symbolic and does not include 0-RTT (IIRC).

Maybe you'd care to revise your bold statement above?

Cheers

Kenny 

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

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Paterson, Kenny]

Hi

On 16/03/2016 18:44, "Watson Ladd"  wrote:

>On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny
> wrote:
>> Hi
>>
>> On 16/03/2016 15:02, "TLS on behalf of Watson Ladd"
>>> on behalf of watsonbl...@gmail.com> wrote:
>>
>> 
>>
>>>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more
>>>extensively analyzed then TLS 1.2. It's almost like you don't believe
>>>cryptography exists: that is a body of knowledge that can demonstrate
>>>that protocols are secure, and which has been applied to the draft.
>>
>> This is patently untrue. There is a vast body of research analysing TLS
>> 1.2 and earlier. A good survey article is here:
>>
>> https://eprint.iacr.org/2013/049
>
>There's a vast literature, but much of it makes simplifying
>assumptions or doesn't address the complete protocol.

Correct, but that does not make it irrelevant or valueless. Or are you
actually saying that it does? Quite a sweeping presumption; see
immediately below.

>The first really
>complete analysis was miTLS AFAIK.

Yes, and even there the analysis was done step by step, spread out over a
series of papers which gradually built up the complexity of the code-base
being handled. And, in parallel, various other groups were doing hand
proofs of abstractions of the core protocol. And I believe it's fair to
say - from having discussed it extensively with the people involved - that
the miTLS final analysis benefitted a lot from the experience gained by
the teams doing the hand proofs, going right back to a paper in 2002 by
Jonsson and Kaliski Jr.

My point is that the TLS 1.2 "final" analysis represented by the miTLS
work was the culmination of a long line of research involving many people
and influenced by many sources.

> Furthermore, a lot of the barriers
>to analysis in TLS 1.2 got removed in TLS 1.3.

Unfortunately, some of them may be coming back again. But again, this has
nothing to do with the argument you were making.

>The question is not how
>many papers are written, but how much the papers can say about the
>protocol as implemented. And from that perspective TLS 1.3's Tamarin
>model is a fairly important step, where the equivalent steps in TLS
>1.2 got reached only much later.

The timing is entirely irrelevant to the argument you were making.

I agree though that it's about the depth and reach of the analysis. And
from this perspective, I'd say that TLS 1.3 is still way behind TLS 1.2,
despite the very nice analyses done by Sam and Thyla (and their
collaborators), by Hugo & Hoeteck, and by Felix & co.

I could go further, but I expect that, by now, only you and I are actually
reading this.

>It's true 0-RTT isn't included: so don't do it. But I think if we
>subset (not add additional implementation requirements) TLS 1.3
>appropriately we end up with a long-term profile that's more useable
>than if we subset TLS 1.2, and definitely more than adding to the set
>of mechanisms. I think claims that TLS 1.3 outside of 0-RTT is likely
>to have crypto weaknesses due to newness are vastly overstated.

I didn't make that claim.

Cheers

Kenny

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

"If I have seen further it is by standing on the shoulders of Giants"
-- Newton, in a letter to Robert Hooke


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

Re: [TLS] Include Speck block cipher?

[Salz, Rich]

There is no serious proposal to use Speck in TLS 1.3.  One major reason is that 
there is insufficient cryptanalysis of it.

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

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

[Colm MacCárthaigh]

On Wed, Mar 16, 2016 at 2:30 PM, Adam Langley 
wrote:

> On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny
>  wrote:
> >>provokes me to bring it up. Here's the crux of it; is it really a
> >>security win to recommend the AEAD cipher suites for TLS 1.2 users?
>
> I'm skeptical about the benefit of padding to 16 bytes. While it does
> increase the size classes in your Wikipedia example, Wikipedia pages
> trigger subresource loads, which also have a size and page-to-page
> navigation leaks more information. My takeaway from reading
> traffic-analysis papers over the years is that countermeasures are
> surprisingly difficult.
>

16-bytes is small, I wish it were much bigger, but it may elevate things to
where you even need to form a sub resource attack and increases the size of
the graph/fingerprint that you need to maintain to form the sub-resource
attack. I doubt it would thwart a large actor for very long, but it would
help against smaller ones and I'm guessing that it might block some
specific attacks like the autocompletion one mentioned in the paper.


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

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Dave Garrett]

https://tools.ietf.org/html/draft-gutmann-tls-lts-01#section-3.2

>   TLS-LTS adds a hash of the domain parameters into the master secret
>   to protect against the use of manipulated curves/domain parameters:
>
>   o  TLS-LTS implementations MUST include a SHA-256 hash of the EDH or
>  ECDH parameters in the master secret computation by concatenating
>  the hash to the pre_master_secret value.  In the case of EDH, the
>  value that's hashed is the ServerDHParams structure.  In the case
>  of ECDH the value that's hashed is the ServerECDHParams structure.
>  This means that the master_secret computation becomes:
>
>   master_secret = PRF(pre_master_secret || param_hash, "master secret",
>   ClientHello.random + ServerHello.random)
>   [0..47];

It would be a lot simpler, safer, and interoperable to just mandate use of the 
Extended Master Secret Extension [RFC 7627].

https://tools.ietf.org/html/rfc7627


Dave

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

Re: [TLS] Simple, secure 0-RTT for the masses

[Colm MacCárthaigh]

On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara 
wrote:

> > Benefits Forward Secrecy and Idempotence:
> >
> > * Client and server should erase the existing ticket upon use.
> >
> > (a captured early data section is mooted for replay quite quickly in the
> > default "good" case)
>
> The best that can be done w.r.t. "forward secrecy" is to erase the
> decryption-capable key used for 0-RTT on both sides, and never sending
> it on the wire, even encrypted.
>

That's why I favor resuming connections where they left off, and cranking a
PRF to generate new keys; but it's not compatible with tickets at all -
works only with some kind of session store.


> > * Make early data and application data separate record layer content
> types.
> > Make it clear that they do not form a continuous stream; you can't simply
> > concatenate them at the application level and bolt on to existing
> protocols
> > such as HTTP, SMTP, etc.
>
> You mean inner (encrypted) content type, right (outer content type would
> still be 23[TLS PROTECTED DATA]?
>

Yep, sorry.


> > * Advise that clients using 0RTT SHOULD occasionally send duplicate early
> > data handshakes. As a normal part of the protocol, a well behaved client
> > should intentionally do what an attacker might do and send the whole
> > section twice, causing the server to resolve the duplication. Keep the
> > anti-bodies strong.
>
> Such duplication does not occur in attack conditions. The duplication
> from attack conditions takes two forms:
>
> - Duplication of 0-RTT data into 1-RTT data of _different_ connection.
>

I think using a different content type solves this; the early data is
illegal in the 1-RTT phase and the content type would distinguish it.


> - Duplication of 0-RTT data into 0-RTT data of _different_ connection.
>
> In both cases, the connections are different, not the same. And this
> makes a difference if e.g. protocol banners are sent as 0-RTT (and
> such may very well be critical for latency).
>

The client would do what an attacker would; occasionally duplicate the
handshake including early data, so it would use a different connection for
it. The purpose here is to force a kind of "continuous testing in
production" that means the protocol really really does have to have
idempodence solved.

As an aside: an application protocol where latency is so sensitive that
0RTT is attractive would hardly have its own back-and-forth with banners in
the first place.

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

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Peter Gutmann]

Wan-Teh Chang  writes:

>This is the procedure specified in PKCS #1 v2.1 (RFC 3447), Section 8.2.2,
>with the additional requirement that the comparison in Step 4 be constant-
>time, right?

Good catch, thanks!  I've added it to the draft.

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

Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

[Andrei Popov]

Hi Henry,

Extension_data field can be zero-length:
opaque extension_data<0..2^16-1>;

The TLS 1.3 draft specifies matching rules for two extensions: KU and EKU and 
then says:
"Separate specifications may define matching rules for other certificate 
extensions."

Which means that you should be able to specify matching rules e.g. for SAN or 
IAN where zero-length extension_data is interpreted as a wildcard. Getting 
TLS/PKI implementations to implement this new specification is a different 
matter, of course.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Henry Story
Sent: Wednesday, March 16, 2016 5:01 AM
To: Eric Rescorla 
Cc:  
Subject: Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?


On 8 Mar 2016, at 09:30, Eric Rescorla > 
wrote:

CertificateRequest already allows you to pass an arbitrary number of
extensions by OID.

http://tlswg.github.io/tls13-spec/#certificate-request

What more do you think you need?

Perhaps what would be needed in addition would be wildcard support.

Eg, it would be useful to say: Give me certificates that contain an extension 
without
specifying the value of the extension. Eg: give me a certificate that contains a
SAN or IAN, I don't care what value of those are.

Is that allowed? I don't see anything regarding it when reading that section. 
But
I may be missing something.



-Ekr


On Tue, Mar 8, 2016 at 12:22 AM, Henry Story 
> wrote:
Hi,


  I was reading with interest M. Thomson and M. Bishop's
"Reactive Certificate-Based Client Authentication" draft RFC [1].
In the section 2.3 "The CERTIFICATE_REQUEST Frame"

[[
  CA-Count and Certificate-Authorities:  "Certificate-Authorities" is a
  series of distinguished names of acceptable certificate
  authorities, represented in DER-encoded [X690] format.  These
  distinguished names may specify a desired distinguished name for a
  root CA or for a subordinate CA; thus, this message can be used to
  describe known roots as well as a desired authorization space.
  The number of such structures is given by the 16-bit "CA-Count"
  field, which MAY be zero.  If the "CA-Count" field is zero, then
  the client MAY send any certificate that meets the rest of the
  selection criteria in the "CERTIFICATE_REQUEST", unless there is
  some external arrangement to the contrary.
]]

Would it not be possible to extend that so that one could also pass
issuer Alternative Names, and not just DNs?

Using DNs made sense when it was thought that LDAP and X500 would
end up being the protocols for global directories. This turned out
not to be the case. It turned out that DNs were a special case of
what could be termed a URI (even though DNs are not in URI format).
And many (most?) URIs can refer to agents, least but not last
http(s) URLs (See the WebID spec [2] for a nice diagram of how this
works conceptually and the WebID-TLS spec for one way this can be tied
to TLS [3]).

If TLS1.3 could start moving away from sole reliance on DNs this
would open quite a lot of possibilities, including the ability to
build institutional Webs of trust for CAs (ie trust anchors could
list CAs by reference at one or more levels of indirection), and CAs
could also describe themselves at their URI.

Those last two paragraphs are just hints of some possibilities that
could emerge from moving away from DNs that I can think of. Others
members of this group will certainly find other possibilities.

In any case it seems that the time for DNs is passed, and that
one should perhaps move away from reliance on those and generalise
this part of TLS.

Henry



[1] 
https://tools.ietf.org/html/draft-thomson-http2-client-certs-01
[2] 
https://www.w3.org/2005/Incubator/webid/spec/identity/#overview
[3] 

Re: [TLS] Include Speck block cipher?

[Eric Rescorla]

Piling on, I can't see why we would want to do this

-Ekr


On Thu, Mar 17, 2016 at 7:09 PM, Martin Thomson 
wrote:

> On 18 March 2016 at 12:37, Mike Hamburg  wrote:
> > No.  The goal should be to remove ciphers, not add new ones, unless we
> have
> > a really compelling reason.
>
> A necessary, but sufficient set of reasons might include:
>
> 1. thorough cryptanalysis
> 2. advantages over existing ciphers on important metrics like security
> and speed, though this would likely need to be significant at this
> point
> 3. interest in implementation
>
> Speck is 0 from 3.
>
> ___
> 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] Include Speck block cipher?

[Efthymios Iosifides]

Hello all.

I have just found on the ietf archives an email discussion about the
inclusion of the SPECK Cipher
in the tls standards.
It's reference is below :
https://www.ietf.org/mail-archive/web/tls/current/msg13824.html

Even though that this cipher originates from the NSA one cannot find a
whitepaper that describes it's full cryptanalysis. In the above discussion
Mr. Strömbergson somehow perfunctorily presents two whitepapers that
describe the SPECK's cryptanalysis. Although we shall keep in mind that
these papers describe a limited round cryptanalysis. Also we shall not
forget that a similar cryptanalysis has taken place for the famous AES.
Therefore i personally do not see any actual arguments apart from the facts
that concerns the algorithm's  provenance for not including it in a future
tls specification. In conclusion even by this day the SPECK cipher has not
been yet fully cryptanalyzed succesfully.

Thank you!


Yours sincerely,
Efthimios Iosifides
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Wan-Teh Chang]

On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
 wrote:
> After a number of, uh, gentle reminders from people who have been waiting for
> this, I've finally got around to posting the TLS-LTS draft I mentioned a while
> back.  It's now available as:
>
> http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt

Section 3.4. "Implementation Issues" says:

   TLS-LTS requires that RSA signature verification be done as encode-
   then-compare, which fixes all known padding-manipulation issues:

   o  TLS-LTS implementations MUST verify RSA signatures by using
  encode-then-compare, meaning that they encode the expected
  signature result and perform a constant-time compare against the
  recovered signature data.

This is the procedure specified in PKCS #1 v2.1 (RFC 3447), Section
8.2.2, with the additional requirement that the comparison in Step 4
be constant-time, right?

https://tools.ietf.org/html/rfc3447#section-8.2.2

and the alternative procedure outlined in the Note at the end of that
section shall not be used?

   Note.  Another way to implement the signature verification operation
   is to apply a "decoding" operation (not specified in this document)
   to the encoded message to recover the underlying hash value, and then
   to compare it to a newly computed hash value.  This has the advantage
   that it requires less intermediate storage (two hash values rather
   than two encoded messages), but the disadvantage that it requires
   additional code.

Thanks,
Wan-Teh Chang

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

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Watson Ladd]

On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny
 wrote:
> Hi
>
> On 16/03/2016 15:02, "TLS on behalf of Watson Ladd"  on behalf of watsonbl...@gmail.com> wrote:
>
>>On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
>> wrote:
>>> After a number of, uh, gentle reminders from people who have been
>>>waiting for
>>> this, I've finally got around to posting the TLS-LTS draft I mentioned
>>>a while
>>> back.  It's now available as:
>>>
>>> http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt
>>>
>>> Abstract:
>>>
>>>This document specifies a profile of TLS 1.2 for long-term support,
>>>one that represents what's already deployed for TLS 1.2 but with the
>>>security holes and bugs fixed.  This represents a stable, known-good
>>>profile that can be deployed now to systems that can't can't roll out
>>>patches every month or two when the next attack on TLS is published.
>>>
>>> Several people have already commented on it off-list while it was being
>>> written, it's now open for general comments...
>>
>>Several comments:
>
> 
>
>>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more
>>extensively analyzed then TLS 1.2. It's almost like you don't believe
>>cryptography exists: that is a body of knowledge that can demonstrate
>>that protocols are secure, and which has been applied to the draft.
>
> This is patently untrue. There is a vast body of research analysing TLS
> 1.2 and earlier. A good survey article is here:
>
> https://eprint.iacr.org/2013/049

There's a vast literature, but much of it makes simplifying
assumptions or doesn't address the complete protocol. The first really
complete analysis was miTLS AFAIK. Furthermore, a lot of the barriers
to analysis in TLS 1.2 got removed in TLS 1.3. The question is not how
many papers are written, but how much the papers can say about the
protocol as implemented. And from that perspective TLS 1.3's Tamarin
model is a fairly important step, where the equivalent steps in TLS
1.2 got reached only much later.

It's true 0-RTT isn't included: so don't do it. But I think if we
subset (not add additional implementation requirements) TLS 1.3
appropriately we end up with a long-term profile that's more useable
than if we subset TLS 1.2, and definitely more than adding to the set
of mechanisms. I think claims that TLS 1.3 outside of 0-RTT is likely
to have crypto weaknesses due to newness are vastly overstated.

>



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

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

[TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted)

[Watson Ladd]

On Fri, Mar 18, 2016 at 1:57 AM, Peter Gutmann
 wrote:
> Watson Ladd  writes:
>
>>As written supporting this draft requires adopting the encrypt-then-MAC
>>extension. But there already is a widely implemented secure way to use MACs
>>in TLS: AES-GCM.
>
> This is there as an option if you want it.  Since it offers no length hiding,
> it's completely unacceptable to some users, for example one protocol uses TLS
> to communicate monitoring commands to remote gear, they're very short and
> fixed-length, different for each command, so if you use GCM you may as well be
> sending plaintext.  In addition GCM is incredibly brittle, get the IV handling
> wrong and you get a complete, catastrophic loss of both integrity and
> confidentiality.  The worst that happens with CBC, even with a complete abuse
> like using an all-zero IV, is that you drop back to ECB mode.

Then use a padding extension that solves all problems, instead of
relying on a side effect of CBC mode. Why do we want this to look
different from TLS, instead of a subset of widely deployed things ala
UTA?

Furthermore, GCM only requires adding a counter for each packet, which
you have to do anyway. If you want, specify GCM-SIV.
>
>>Likewise, this draft modifies the way the master secret is computed, despite
>>a widely implemented different solution to the problem, namely the EMS triple
>>handshake fix.
>
> Firstly, that solves an entirely different problem, and secondly I don't
> recall ever seeing EMS support in any embedded device, it may be widely
> implemented in Windows and OpenSSL but I don't know how much further it goes.

What is your master secret change solving? I don't see how EMS is
solving an entirely different problem, but maybe that's because I
don't understand what your change is solving.

>
>>The use of uncompressed points makes off-curve attacks much easier than with
>>compressed points.
>
> Everything uses uncompressed points at the moment without any problems, and
> compressed points are patented.

At RWC 2016 one of the presentations decrypted connections to a server
by exploiting off-curve point attacks. Your draft claims that
verifying signatures before sending will address an ECC security
threat. I don't see what threat that addresses, and there is a much
worse one that is left unaddressed, namely off-curve point attacks. We
should mandate no reuse of ephemerals to help with that.

>
>>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more extensively
>>analyzed then TLS 1.2.
>
> As the rationale points out, the mechanisms in SSL were also very heavily
> analysed when they were released.  It didn't protect the protocol from 20
> years of subsequent attacks, which we've leared about over those 20 years of
> implementation and deployment experience.  With TLS 1.3 we have zero
> implementation and deployment experience.  Do you really believe there will
> never be any attacks on it after it's rolled out?

Deployment does not affect the protocol's amenability to analysis, or
the degree of analysis it should receive. The actual history of TLS
1.2 and earlier analysis shows that many of the vaunted "attacks" are
the result of old publications being dusted off, due to the anemic
response of the security industry to the attacks, and that there's an
actual body of knowledge

The use of predictable IVs in TLS 1.0 was first commented on by
Rogaway in 1995. (I'm hunting down the source, but this is from a
presentation of Patterson) That should have immediately resulted in a
protocol change but didn't. Did it really take 20 years to realize
this was a problem? Or was it 20 years of ignoring the problem until
exploitation?

In 1998 Bleichenbacher noted that PKCS 1.5 encryption is dangerous.
TLS could use much better simpler designs which hash the ciphertext
and plaintext together, but didn't. Today we still haven't killed a
nearly 20 year old attack.

That TLS doesn't sign enough when using DH was an observation made in
2004. Sadly I don't recall who did it. It wasn't fixed over two
revisions, and culminates in Logjam. Did this require deployment to be
observed?

Lastly, it's the primitives but the protocol that is the proper unit
of analysis. With TLS 1.3 we have a symbolic model and have a
considerable amount of examination of the cryptographic security. That
should give far more confidence than 20 years of being run: computers
don't analyse the protocols they run.

Sincerely,
Watson
>
> Peter.



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

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

Re: [TLS] Include Speck block cipher?

[Martin Thomson]

On 18 March 2016 at 12:37, Mike Hamburg  wrote:
> No.  The goal should be to remove ciphers, not add new ones, unless we have
> a really compelling reason.

A necessary, but sufficient set of reasons might include:

1. thorough cryptanalysis
2. advantages over existing ciphers on important metrics like security
and speed, though this would likely need to be significant at this
point
3. interest in implementation

Speck is 0 from 3.

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

Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

[Henry Story]

> On 8 Mar 2016, at 09:30, Eric Rescorla  wrote:
> 
> CertificateRequest already allows you to pass an arbitrary number of
> extensions by OID.
> 
> http://tlswg.github.io/tls13-spec/#certificate-request 
> 
> 
> What more do you think you need?

Perhaps what would be needed in addition would be wildcard support.

Eg, it would be useful to say: Give me certificates that contain an extension 
without
specifying the value of the extension. Eg: give me a certificate that contains 
a 
SAN or IAN, I don't care what value of those are.

Is that allowed? I don't see anything regarding it when reading that section. 
But
I may be missing something.

> 
> -Ekr
> 
> 
> On Tue, Mar 8, 2016 at 12:22 AM, Henry Story  > wrote:
> Hi,
> 
> 
>   I was reading with interest M. Thomson and M. Bishop's
> "Reactive Certificate-Based Client Authentication" draft RFC [1].
> In the section 2.3 "The CERTIFICATE_REQUEST Frame"
> 
> [[
>   CA-Count and Certificate-Authorities:  "Certificate-Authorities" is a
>   series of distinguished names of acceptable certificate
>   authorities, represented in DER-encoded [X690] format.  These
>   distinguished names may specify a desired distinguished name for a
>   root CA or for a subordinate CA; thus, this message can be used to
>   describe known roots as well as a desired authorization space.
>   The number of such structures is given by the 16-bit "CA-Count"
>   field, which MAY be zero.  If the "CA-Count" field is zero, then
>   the client MAY send any certificate that meets the rest of the
>   selection criteria in the "CERTIFICATE_REQUEST", unless there is
>   some external arrangement to the contrary.
> ]]
> 
> Would it not be possible to extend that so that one could also pass
> issuer Alternative Names, and not just DNs?
> 
> Using DNs made sense when it was thought that LDAP and X500 would
> end up being the protocols for global directories. This turned out
> not to be the case. It turned out that DNs were a special case of
> what could be termed a URI (even though DNs are not in URI format).
> And many (most?) URIs can refer to agents, least but not last
> http(s) URLs (See the WebID spec [2] for a nice diagram of how this
> works conceptually and the WebID-TLS spec for one way this can be tied
> to TLS [3]).
> 
> If TLS1.3 could start moving away from sole reliance on DNs this
> would open quite a lot of possibilities, including the ability to
> build institutional Webs of trust for CAs (ie trust anchors could
> list CAs by reference at one or more levels of indirection), and CAs
> could also describe themselves at their URI.
> 
> Those last two paragraphs are just hints of some possibilities that
> could emerge from moving away from DNs that I can think of. Others
> members of this group will certainly find other possibilities.
> 
> In any case it seems that the time for DNs is passed, and that
> one should perhaps move away from reliance on those and generalise
> this part of TLS.
> 
> Henry
> 
> 
> 
> [1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01 
> 
> [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview 
> 
> [3] https://www.w3.org/2005/Incubator/webid/spec/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] Are the AEAD cipher suites a security trade-off win with TLS1.2?

[Martin Rex]

Alexandre Anzala-Yamajako wrote:
>
> IMO, the layer creating the plaintext shouldn't have to pad it for security
> that's the job of the TLS layer.

Yep.  And retrofitting random padding into TLS (all protocol versions, all
PDUs) could be actually pretty simple and straightforward.

http://www.ietf.org/mail-archive/web/tls/current/msg11626.html

-Martin

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

[TLS] TLS 1.2 Long-term Support Profile draft posted

[Peter Gutmann]

After a number of, uh, gentle reminders from people who have been waiting for
this, I've finally got around to posting the TLS-LTS draft I mentioned a while
back.  It's now available as:

http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt

Abstract:

   This document specifies a profile of TLS 1.2 for long-term support,
   one that represents what's already deployed for TLS 1.2 but with the
   security holes and bugs fixed.  This represents a stable, known-good
   profile that can be deployed now to systems that can't can't roll out
   patches every month or two when the next attack on TLS is published.

Several people have already commented on it off-list while it was being
written, it's now open for general comments...

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

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Peter Gutmann]

Hubert Kario  writes:

>also, if it really is supposed to be Long Term Support, why it doesn't say
>anything about implementation explicitly being able to handle big key sizes?
>both RSA and DHE?

I've deliberately avoided getting into that because it's such a rathole,
you've got everything from the NIST numerologists at one extreme to the "good
enough for now" folks at the other, and you'll never get any consensus because
there are completely different worldviews involved.  A possible median is:

Implementations SHOULD choose public-key algorithm key sizes that are
appropriate for the situation, weighted by the value of the information being
protected, the probability of an attack, and the ability of the hardware to
deal with large keys.  For example a SCADA system being used to switch a
ventilator on and off doesn't require anywhere near the keysize-based security
of a system used to transfer classified information.  One way to avoid having
to use very large public keys is to switch keys periodically.  This can be
done by regenerating DH parameters in a background thread and rolling them
over from time to time, or if this isn't possible, by pre-generating a
selection of DH parameters and choosing one at random for each new handshake,
or again rolling them over from time to time.

>I might have missed, but where is the specification of the acceptable
>signature algorithms (hash especially) on Server and Client Key Exchange
>messages?

That's implicit in the cipher suites, RSA or ECDSA + SHA256.

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

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Watson Ladd]

On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
 wrote:
> After a number of, uh, gentle reminders from people who have been waiting for
> this, I've finally got around to posting the TLS-LTS draft I mentioned a while
> back.  It's now available as:
>
> http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt
>
> Abstract:
>
>This document specifies a profile of TLS 1.2 for long-term support,
>one that represents what's already deployed for TLS 1.2 but with the
>security holes and bugs fixed.  This represents a stable, known-good
>profile that can be deployed now to systems that can't can't roll out
>patches every month or two when the next attack on TLS is published.
>
> Several people have already commented on it off-list while it was being
> written, it's now open for general comments...

Several comments:

As written supporting this draft requires adopting the
encrypt-then-MAC extension. But there already is a widely implemented
secure way to use MACs in TLS: AES-GCM. Likewise, this draft modifies
the way the master secret is computed, despite a widely implemented
different solution to the problem, namely the EMS triple handshake
fix. I don't see why these other solutions should be adopted over the
ones that already are there.

The use of uncompressed points makes off-curve attacks much easier
than with compressed points. Recommendations to not reuse randoms for
ECDH and to use Curve25519 would actually solve the problems, instead
of what the draft has right now.

The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more
extensively analyzed then TLS 1.2. It's almost like you don't believe
cryptography exists: that is a body of knowledge that can demonstrate
that protocols are secure, and which has been applied to the draft.

The ladder diagram/state machine discussion ignores the real problem,
which is not having either represented in the code. It doesn't direct
readers to do anything that helps solve the problem, such as testing
for the correct state transitions.

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



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

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

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

[Salz, Rich]

> I hadn't seen that! I wonder is there an appetite here for including more 
> robust LH in TLS1.2 in some form? I mean a real one; as in - let's it get it 
> into servers and browsers sooner than TLS1.3. 

H2 has padding; put it there.

There is probably zero interest in adding padding to TLS 1.2, especially since 
the record type is plaintext and could easily be bypassed.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Include Speck block cipher?

[Mike Hamburg]

No.  The goal should be to remove ciphers, not add new ones, unless we have a 
really compelling reason.  Short source code is not a compelling reason in a 
protocol so complicated as TLS.

Cheers,
— Mike

> On Mar 16, 2016, at 11:35 PM, Efthymios Iosifides  
> wrote:
> 
> Hello all.
> 
> I have just found on the ietf archives an email discussion about the 
> inclusion of the SPECK Cipher 
> in the tls standards. 
> It's reference is below 
> :https://www.ietf.org/mail-archive/web/tls/current/msg13824.html 
> 
> 
> Even though that this cipher originates from the NSA one cannot find a 
> whitepaper that describes it's full cryptanalysis. In the above discussion 
> Mr. Strömbergson somehow perfunctorily presents two whitepapers that describe 
> the SPECK's cryptanalysis. Although we shall keep in mind that these papers 
> describe a limited round cryptanalysis. Also we shall not forget that a 
> similar cryptanalysis has taken place for the famous AES. Therefore i 
> personally do not see any actual arguments apart from the facts that concerns 
> the algorithm's  provenance for not including it in a future tls 
> specification. In conclusion even by this day the SPECK cipher has not been 
> yet fully cryptanalyzed succesfully. 
> 
> Thank you!
> 
> 
> Yours sincerely,
> Efthimios Iosifides 
> 
> 
> 
> 
> ___
> 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] Simplifying signature algorithm negotiation

[Ilari Liusvaara]

On Tue, Mar 15, 2016 at 05:37:20PM +, David Benjamin wrote:
> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla  wrote:
> 
> 
> I would probably characterize it less as suites vs orthogonality, but as
> wanting to keep divisions in meaningful and universal places and not
> splitting up tightly-coupled decisions. The flexibility from orthogonality
> can be handy, but going too far---as I believe TLS 1.2 did with signature,
> prehash, and curve---complicates everything. Imagine if negotiating
> AES_128_GCM required separately negotiating block cipher AES-128, mode CTR,
> and MAC GHASH.

It isn't even orthogonal, it is coupled, which is way worse and quite
difficult to implement correctly.

I now consider the way TLS 1.3 draft / RFC4492bis draft currently does
EdDSA negotiation a bad idea (what is proposed here is vast improvement).


-Ilari

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