Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Ilari Liusvaara]

On Wed, Dec 07, 2016 at 07:18:56AM +0900, Martin Thomson wrote:
> On 7 December 2016 at 03:24, Sean Turner  wrote:
> > Just a reminder that this WGLC will close on Friday December 9th.
> 
> A timely reminder :)
> 
> I reviewed the document and it looks pretty good.  I'd have sent a PR
> with some minor changes to grammar.
> 
> The question I wanted to ask was how we wanted to manage the
> relationship with TLS 1.3, particularly for EdDSA.
> 
> The draft asks for a NEW codepoint in the hash and signature
> algorithms structure.  That clobbers a whole bunch of space that TLS
> 1.3 is going to rework.  I don't think it's a good idea to perform
> concurrent surgery on this registry, particularly since new codepoints
> have the effect of taking out new swathes of space.  At best we send
> confusing signals to IANA.
> 
> I would prefer to take the arrangement that we have in TLS 1.3 and
> backport it here so that we have a consistent story.  I also think
> that taking a single 2 octet codepoint from the SignatureScheme space
> is better all around.

I actually reviewed the document and noticed the exact same thing.


Also, in my TLS implementation, doing EdDSA in TLS 1.2 by backporting
the TLS 1.3 mechanism (using ECDSA legacy type) just fell naturally
out of the implementation. It was easier to have all the machinery
needed to handle it than not to have that machinery.


-Ilari

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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Sean Turner]

Just a reminder that this WGLC will close on Friday December 9th.

spt

> On Nov 18, 2016, at 18:55, Sean Turner  wrote:
> 
> All,
> 
> This is a working group last call for the “4492bis to Standards Track" draft 
> available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/.  
> Please review the document and send your comments to the list by 9 December 
> 2016.  
> 
> Note that we are particularly interesting in the issue Yoav raises in the 
> following message:
> https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk
> 
> Thanks,
> J

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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Sean Turner]

>> - Section 1
>> "This is illustrated in the following table, based on [Lenstra_Verheul],
>> which gives approximate comparable key sizes for symmetric- and
>> asymmetric-key cryptosystems based on the best-known algorithms for
>> attacking them."
>> 
>> The key sizes for DH/DSA/RSA does not seem to be based on the
>> Lenstra-Verheuls equations which gives much higher key sizes for
>> DH/DSA/RSA.
>> 
>> The DH/DSA/RSA key sizes seem to be based on NIST recommendations. I
>> suggest either:
>> 
>> A) Fully based the table on NIST recommendation, which means keeping
>> DH/DSA/RSA as is but simplifying ECC to 2 * Symmetric.
>> B) Update the DH/DSA/RSA key sizes based on state-of-the-art. But then I
>> would say that this is not [Lenstra_Verheul], but rather [RFC3766],
>> [Lenstra 2004], [ECRYPT 2012]. I think these three all use the same
>> equation.
>> C) Just remove DH/DSA/RSA as the draft is about ECC.
> 
> I’m inclined to get rid of this table and all the text from “This is 
> illustrated…” entirely. ECC is by now in wide use. We don’t need to “sell” it 
> any more. so unless someone would like to make a PR with better text, I will 
> just get rid of it.

You could be more draconian and start the draft with the paragraph:

  This document describes additions to TLS to support ECC ….

Because you’re right we don’t really need to do much selling here.

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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Yaron Sheffer]

I’m not even sure what my position is on this. Specifying the use of a
context here goes against the recommendation in the CFRG draft:

  Contexts SHOULD NOT be used opportunistically, as that kind of use
  is very error-prone.  If contexts are used, one SHOULD require all
  signature schemes available for use in that purpose support
  contexts.

If someone knows why this recommendation was made, that would be great.


Basically, then those other methods would be a weak point for attack.



But we are trying to migrate away from the old methods, into the new 
methods. The fewer servers use the old methods, the better off we are, 
right? So we expect the attack surface to gradually be reduced over the 
coming years.





Then there's the serious deployment problems with contexts, as those
don't fit into any standard notion of signature various libraries have.



These are new algorithms that are still not widely deployed. The fact 
that several open source libraries (still) don't support a certain 
function parameter is not a very strong reason not to require it.


Thanks,
Yaron

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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Ilari Liusvaara]

On Wed, Nov 23, 2016 at 03:39:38PM +0200, Yoav Nir wrote:
> 
> > On 23 Nov 2016, at 12:22, John Mattsson  wrote:
> > 
> > On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer"
> >  on behalf of 
> > yaronf.i...@gmail.com > wrote:
> > 
> >> So the key schedule changed and therefore we think cross-version attacks
> >> are impossible. Have we also analyzed other protocols to ensure that
> >> cross protocol attacks, e.g. with SSH or IPsec, are out of the question?
> >> 
> >> Put differently, algorithm designers gave us a cheap, easy to use tool
> >> to avoid a class of potential attacks. Why are we insisting on not using
> >> it?
> > 
> > Unless someone points out any major disadvantages with using a context, I
> > agree with Yaron.
> 
> I’m not even sure what my position is on this. Specifying the use of a
> context here goes against the recommendation in the CFRG draft:
> 
>   Contexts SHOULD NOT be used opportunistically, as that kind of use
>   is very error-prone.  If contexts are used, one SHOULD require all
>   signature schemes available for use in that purpose support
>   contexts.
> 
> If someone knows why this recommendation was made, that would be great.

Basically, then those other methods would be a weak point for attack.



Then there's the serious deployment problems with contexts, as those
don't fit into any standard notion of signature various libraries have.


-Ilari

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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Yoav Nir]

> On 23 Nov 2016, at 12:22, John Mattsson  wrote:
> 
> On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer"
>  on behalf of 
> yaronf.i...@gmail.com > wrote:
> 
>> So the key schedule changed and therefore we think cross-version attacks
>> are impossible. Have we also analyzed other protocols to ensure that
>> cross protocol attacks, e.g. with SSH or IPsec, are out of the question?
>> 
>> Put differently, algorithm designers gave us a cheap, easy to use tool
>> to avoid a class of potential attacks. Why are we insisting on not using
>> it?
> 
> Unless someone points out any major disadvantages with using a context, I
> agree with Yaron.

I’m not even sure what my position is on this. Specifying the use of a context 
here goes against the recommendation in the CFRG draft:

  Contexts SHOULD NOT be used opportunistically, as that kind of use
  is very error-prone.  If contexts are used, one SHOULD require all
  signature schemes available for use in that purpose support
  contexts.

If someone knows why this recommendation was made, that would be great.

However, three working groups are currently faced with this same decision: TLS, 
IPsecME and Curdle. I think it would be weird if these three groups came up 
with different answers to what is essentially the same question. At least for 
TLS and IKE there are no operational differences either. 

So Curdle, I’ve been told, is leaning towards empty context for Ed448 and no 
OID for Ed25519ctx. IPsecME has a thread similar to this one (with similar 
participants…)

Yoav

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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Yoav Nir]

Hi, John

Thanks for the review.  See my responses below:

> On 23 Nov 2016, at 12:15, John Mattsson  wrote:
> 
> I have not read the processing parts in detail. Here are comments on the
> first and last sections of the document.
> 
> Cheers,
> John
> 
> - Somewhere
> I suggest adding the following sentence from TLS 1.3:
> "Applications SHOULD also enforce minimum and maximum key sizes.  For
> example, certification paths containing keys or signatures weaker than
> 2048-bit RSA or 224-bit ECC are not appropriate for secure applications."
> 
> This is as true for TLS 1.0, 1.1, and 1.2 as for TLS 1.3

I can add a sentence like that, but the draft does even better: It deprecates 
all curves smaller than 256-bit ECC. Now it’s true that this draft is about 
TLS, not PKIX, so this only forces the public key in the EE certificate to be 
at least 256-bit, but in general CA keys are no weaker than EE keys. I will add 
such a sentence , though.

> - Section 1
> "Compared to currently prevalent cryptosystems such as RSA, ECC offers"
> 
> I think this should be updated, ECDHE is already very well-spread.

Yes, this is copied from 4492.  How about: “Compared to previous cryptosystems 
such as RSA and finite-field diffie-hellman, ECC offers…"

> - Section 1
> "This is illustrated in the following table, based on [Lenstra_Verheul],
> which gives approximate comparable key sizes for symmetric- and
> asymmetric-key cryptosystems based on the best-known algorithms for
> attacking them."
> 
> The key sizes for DH/DSA/RSA does not seem to be based on the
> Lenstra-Verheuls equations which gives much higher key sizes for
> DH/DSA/RSA.
> 
> The DH/DSA/RSA key sizes seem to be based on NIST recommendations. I
> suggest either:
> 
> A) Fully based the table on NIST recommendation, which means keeping
> DH/DSA/RSA as is but simplifying ECC to 2 * Symmetric.
> B) Update the DH/DSA/RSA key sizes based on state-of-the-art. But then I
> would say that this is not [Lenstra_Verheul], but rather [RFC3766],
> [Lenstra 2004], [ECRYPT 2012]. I think these three all use the same
> equation.
> C) Just remove DH/DSA/RSA as the draft is about ECC.

I’m inclined to get rid of this table and all the text from “This is 
illustrated…” entirely. ECC is by now in wide use. We don’t need to “sell” it 
any more. so unless someone would like to make a PR with better text, I will 
just get rid of it.

> 
> - Section 2
> "However, the computational cost incurred by a server is higher for
> ECDHE_RSA than for the traditional RSA key exchange, which does not
> provide forward secrecy."
> 
> True, but I think it gives the wrong impression. I think the additional
> cost is negligible. I don't have any TLS benchmarks but for i5-6600,
> bench.cr.yp.to gives:
> 
> ronald3072 decrypt  8776864 cycles
> 
> ronald3072 sign 8781842 cycles
> curve25519 keygen163200 cycles
> curve25519 compute   165816 cycles
> 
> That's only 3.8% overhead for crypto, and much less if calculated for the
> whole handshake. I suggest removing the sentence, or writing that the
> additional server cost for forward secrecy is negligible and well worth it.

Makes sense. How about:
OLD:
   However, the computational cost incurred by a server is higher
NEW:
   The computational cost incurred by a server is marginally higher
> 
> - Section 6
> "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256"
> 
> Should this be "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"?
> I don't think the document should recommend support of cipher suites
> without forward secrecy.

Definitely. It would be a very poor show to deprecate this ciphersuite (along 
with all other ECDH_RSA and ECDH_ECDSA ciphersuites), declare that all 
ciphersuites have forward secrecy, and then make this (sort of ) MTI.  Will fix.

> 
> - Section 7
> "documemts" -> “documents"

OK

> 
> - Section 7
> "NEED TO ADD A PARAGRAPH HERE ABOUT WHY X25519/X448 ARE PREFERRABLE TO
> NIST CURVES."
> 
> I suggest using the excellent explanation in RFC7748 as a basis.
> Suggestion:
> 
> "Modern curves such X25519 and X448 [RFC7748] are preferable as they lend
> themselves to constant-time implementation and an exception-free scalar
> multiplication that is resistant to a wide range of side-channel attacks,
> including timing and cache attacks. For more information see [SafeCurves]."
> 
> [SafeCurves]  https://safecurves.cr.yp.to/

Cool.  Will add.

> - Section 7
> "Substantial additional information on elliptic curve choice can be found
> in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4]".
> 
> I think it is better to refer people to [SafeCurves].

In addition, OK. I don’t think we should remove everything else, especially 
when unlike 7748 this draft is specifying NIST curves, and the choice for them 
was not in [SafeCurves]

> - Section 7
> The paragraph about structure gives the impression that "F_p with p
> random" is the optimal choice. I think this should be expanded with more
> information explaining why we do not 

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[John Mattsson]

On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer"
 wrote:

>So the key schedule changed and therefore we think cross-version attacks
>are impossible. Have we also analyzed other protocols to ensure that
>cross protocol attacks, e.g. with SSH or IPsec, are out of the question?
>
>Put differently, algorithm designers gave us a cheap, easy to use tool
>to avoid a class of potential attacks. Why are we insisting on not using
>it?

Unless someone points out any major disadvantages with using a context, I
agree with Yaron.


>
>Thanks,
>   Yaron
>
>On 20/11/16 17:33, Salz, Rich wrote:
>>> For those who missed CURDLE, could you please briefly explain why we
>>>don't
>>> need signature context in non-TLS areas.
>>
>> The one place we were concerned about attacks was in pre-hash
>>signatures, and we made those a MUST NOT.  And yes, your'e right, it's
>>not relevant to TLS.
>>
>>> So why are we now saying that contexts are not needed even for TLS?
>>
>> I think because the key schedule changed.
>>
>> --
>> Senior Architect, Akamai Technologies
>> Member, OpenSSL Dev Team
>> IM: richs...@jabber.at Twitter: RichSalz
>>
>>
>
>___
>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] WGLC for draft-ietf-tls-rfc4492bis

[Yaron Sheffer]

So the key schedule changed and therefore we think cross-version attacks 
are impossible. Have we also analyzed other protocols to ensure that 
cross protocol attacks, e.g. with SSH or IPsec, are out of the question?


Put differently, algorithm designers gave us a cheap, easy to use tool 
to avoid a class of potential attacks. Why are we insisting on not using it?


Thanks,
Yaron

On 20/11/16 17:33, Salz, Rich wrote:

For those who missed CURDLE, could you please briefly explain why we don't
need signature context in non-TLS areas.


The one place we were concerned about attacks was in pre-hash signatures, and 
we made those a MUST NOT.  And yes, your'e right, it's not relevant to TLS.


So why are we now saying that contexts are not needed even for TLS?


I think because the key schedule changed.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz




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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Salz, Rich]

> For those who missed CURDLE, could you please briefly explain why we don't
> need signature context in non-TLS areas.

The one place we were concerned about attacks was in pre-hash signatures, and 
we made those a MUST NOT.  And yes, your'e right, it's not relevant to TLS.

> So why are we now saying that contexts are not needed even for TLS?

I think because the key schedule changed.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz


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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Yaron Sheffer]

Hi Rich,

I am confused by your response.

For those who missed CURDLE, could you please briefly explain why we 
don't need signature context in non-TLS areas.


And even if this is the case, the current thread is about TLS! So why 
are we now saying that contexts are not needed even for TLS?


Thanks,
Yaron

On 20/11/16 13:21, Salz, Rich wrote:

In CURDLE this week, we had consensus (to be confirmed on the list, of course) 
that
Signature contexts were created in the TLS arena, we all thought we 
needed them in other areas, and we don't, therefore all CURDLE documents for 
those other areas will specify a zero-length context.

FWIW.

I agree with Yoav's message, for the reasons he states.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz



-Original Message-
From: Sean Turner [mailto:s...@sn3rd.com]
Sent: Friday, November 18, 2016 6:56 PM
To: <tls@ietf.org>
Subject: [TLS] WGLC for draft-ietf-tls-rfc4492bis

All,

This is a working group last call for the “4492bis to Standards Track" draft
available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/.  Please
review the document and send your comments to the list by 9 December
2016.

Note that we are particularly interesting in the issue Yoav raises in the
following message:
https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk

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

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



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

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Salz, Rich]

In CURDLE this week, we had consensus (to be confirmed on the list, of course) 
that
Signature contexts were created in the TLS arena, we all thought we 
needed them in other areas, and we don't, therefore all CURDLE documents for 
those other areas will specify a zero-length context.

FWIW.

I agree with Yoav's message, for the reasons he states.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz


> -Original Message-
> From: Sean Turner [mailto:s...@sn3rd.com]
> Sent: Friday, November 18, 2016 6:56 PM
> To: <tls@ietf.org>
> Subject: [TLS] WGLC for draft-ietf-tls-rfc4492bis
> 
> All,
> 
> This is a working group last call for the “4492bis to Standards Track" draft
> available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/.  
> Please
> review the document and send your comments to the list by 9 December
> 2016.
> 
> Note that we are particularly interesting in the issue Yoav raises in the
> following message:
> https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk
> 
> Thanks,
> J
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

[Yaron Sheffer]

I have not read the document in full (but still noticed a typo in the 
paragraph we're discussing), so I will not comment on its readiness.


Regarding signature context: I don't understand the CFRG recommendation 
that Yoav is citing. IMO we should include a context string wherever we 
can, to reduce the number of possible cross-protocol (or cross-signature 
scheme) attacks. As far as I know context strings do not cost anything 
and can only improve the protocol's security.


Maybe one day we will only have signatures deployed that support 
context, but if we don't add the context string now we will never get 
there. We are not going to revise TLS just to add a context string to EdDSA.


Thanks,
Yaron

On 19/11/16 08:55, Sean Turner wrote:

All,

This is a working group last call for the “4492bis to Standards Track" draft 
available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/.  Please 
review the document and send your comments to the list by 9 December 2016.

Note that we are particularly interesting in the issue Yoav raises in the 
following message:
https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk

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



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

[TLS] WGLC for draft-ietf-tls-rfc4492bis

[Sean Turner]

All,

This is a working group last call for the “4492bis to Standards Track" draft 
available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/.  Please 
review the document and send your comments to the list by 9 December 2016.  

Note that we are particularly interesting in the issue Yoav raises in the 
following message:
https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk

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