I removed all these recommendations on 128/256 security. I believe this
address this thread.
I also believe a profile document would be useful and detail these details.
Do you have any opinion about such a document ?
Tank you for the feed backs!
Yours,
Daniel
On Tue, Nov 8, 2016 at 7:24 PM, Mar
On 8 November 2016 at 21:08, Daniel Migault wrote:
> TLS enable curve negotiation but not for code point. This makes restrictions
> on code points hard to implement. As a result Endpoints MAY treat
> negotiation of key sizes smaller than the lower limits as a connection error
> of type insufficie
If I understand correctly, you recommend something that is of the flavor in
the security recommendation section:
TLS enable curve negotiation but not for code point. This makes
restrictions on code points hard to implement. As a result Endpoints MAY
treat negotiation of key sizes smaller than the
On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote:
> Regarding Niko, my understanding is that the WG preferred not to have
> the definition of profiles in this document. I am not sure you wanted
> the text to be removed as MUST NOT was to normative or if you would
> like no recommendation at
Hi Martin, Niko,
Thanks for the comment. Regarding Martin comment, I agree the text should
not comment the SHAX as these are defined by the cipher suites. What is not
clear to me is how the reference to DH should be handled. I also did not
feel that the provided text provides different recommendat
On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote:
> Hi,
>
> Please find the text I propose. Let me know if you have any comment
> regarding the proposed text. Unless I receive comment on it, the text
> will be publish as soon as draft submission is possible.
>
> Yours,
> Daniel
>
> T
I don't understand this. I have no problems with a recommendation
(i.e., SHOULD), but you will find that many implementations will not
comply with these requirements when pushed.
On 8 November 2016 at 14:09, Daniel Migault wrote:
>The cipher suites defined in this document are based on the A
Hi,
Please find the text I propose. Let me know if you have any comment
regarding the proposed text. Unless I receive comment on it, the text will
be publish as soon as draft submission is possible.
Yours,
Daniel
The cipher suites defined in this document are based on the AES-GCM
and AES-C
Hi,
My understanding is that the updated version should not introduce any
profile. Am I correct ?
BR,
Daniel
On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault wrote:
> Hi,
>
> I am not very clear on how to update the text of the draft. The problem
> seems to me that code point restriction are ha
Hi,
I am not very clear on how to update the text of the draft. The problem
seems to me that code point restriction are hard to implement. As a result,
the session is aborted with - insufficient_security(71) or equivalent -
when the code point does not match the security strength. I am encline to
Hi Peter,
Yes, it should end with ...SHA384. We will fix this in the next update.
(Related question from Martin Thompson can be found in [0])
Cheers,
John
[0] https://www.ietf.org/mail-archive/web/tls/current/msg21517.html
On 10/07/16 12:51, "TLS on behalf of Peter Dettman" wrote:
>Hi,
>I'v
Hi Dan, Sean, Nikos,
First, let me state that I think requiring 128-bit key management for
AES-128 is quite reasonable.
HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies
when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key sizes
smaller than the lower limit
Hi Sean,
That might be a good thing, yes. If so, it would be best to make that
relationship explicit with an "Updates: " header note, referencing DICE in this
document, and explaining how it is extending it.
thanks,
Gabriel
On Monday, July 11, 2016 7:35 AM, Sean Turner wrote:
> On
I'm glad I have to opportunity to make you happy Sean :-)
On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
> I think I can take this bit:
>
> On Jul 10, 2016, at 06:51, Peter Dettman
> wrote:
>>
>> I'm also curious whether there is a precedent in other RFCs for an
>> explicit minimum curve bi
I think I can take this bit:
On Jul 10, 2016, at 06:51, Peter Dettman wrote:
>
> I'm also curious whether there is a precedent in other RFCs for an
> explicit minimum curve bits, or perhaps a de facto implementer's rule?
I’d be happy to be wrong here. but to my knowledge no there’s not been an
> On Jul 10, 2016, at 03:36, g_e_montene...@yahoo.com wrote:
>
> Hi,
>
> I'm curious as to the relationship between this TLS WG draft and the DICE
> profile for IoT (currently in Auth48):
> https://tools.ietf.org/html/draft-ietf-dice-profile
>
> The dice profile uses two TLS ciphershuites
>
>
Hi,
I've just implemented these ciphersuites in BouncyCastle TLS, and have a
couple of questions:
In Section 3., should
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 = {0xTBD,0xTBD};
end with ...SHA384 instead?
For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash
function SHAL
Hi,
I'm curious as to the relationship between this TLS WG draft and the DICE
profile for IoT (currently in
Auth48):https://tools.ietf.org/html/draft-ietf-dice-profile
The dice profile uses two TLS ciphershuites
TLS_PSK_WITH_AES_128_CCM_8 (defined in
https://tools.ietf.org/html/rfc6
18 matches
Mail list logo
