Re: [TLS] padding bug

On 9 September 2013 14:31, Ben Laurie <benl@google.com> wrote:

>
>
>
> On 9 September 2013 14:01, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> Ben,
>>
>> Generally, we're not doing advance code point assignments for documents
>> that haven't been accepted by the TLS WG.
>>
>> Of course, this naturally raises the question of whether this document
>> will
>> be accepted by the TLS WG. However, as I think recent discussion
>> indicates,
>> there are a number of proposed approaches and there isn't really consensus
>> to adopt this particular one (especially in view of the increased
>> adoption of existing
>> mechanisms such as GCM). If someone (Peter? You?) wants agenda time
>> to argue for this particular approach instead of others, we're happy to
>> have the
>> discussion in YVR. This of course also applies to proponents of other
>> approaches.
>>
>
> I'm not planning to be at YVR, what happened to using the mailing list for
> discussion?
>
> So, in favour of the WG adoption this I-D:
>
> 1. Nothing in this I-D prevents the adoption of other approaches.
>
> 2. If fixes the problem for all versions of TLS and SSLv3.
>
> 3. I've seen no objection that makes any sense. One objection I have seen
> was that it "may not protect from key-recovery in a weak MAC
> construction" - firstly, I am not aware of any such constructions in use in
> SSL/TLS, and secondly, if there are any, it would be trivial to deprecate
> their use in conjunction with this extension.
>
> How about we take a vote?
>

I am reminded that we don't vote - so I guess I should rephrase this as -
"so, should we adopt this I-D?".

>
> Note, BTW, that unless convinced otherwise, we intend to implement this in
> OpenSSL (it went into master yesterday), so you can consider that a vote in
> favour :-)
>
>
>> Best,
>> -Ekr
>>
>> [As Chair]
>>
>>
>>
>> On Sun, Sep 8, 2013 at 10:57 AM, Ben Laurie <benl@google.com> wrote:
>>
>>>
>>>
>>>
>>> On 8 September 2013 14:47, Dr Stephen Henson <
>>> lists@drh-consultancy.co.uk> wrote:
>>>
>>>> On 08/09/2013 13:07, Dr Stephen Henson wrote:
>>>> > On 08/09/2013 03:59, Peter Saint-Andre wrote:
>>>> >> [old thread alert!]
>>>> >>
>>>> >>
>>>> >>> 2.       An extension for Encrypt-then-MAC (i.e. this draft)
>>>> >>
>>>> >>> Was any consensus achieved as to the best approach?
>>>> >>
>>>> >
>>>> > I can add a data point to this. I spent an afternoon implementing
>>>> this (i.e.
>>>> > the encrypt then mac draft) a while ago in OpenSSL. It was pretty
>>>> easy to do
>>>> > and interoped fine with the test servers.
>>>> >
>>>> > I'll make it available as an experimental feature in OpenSSL master
>>>> branch.
>>>> >
>>>>
>>>> Well I've added this and spotted a problem. The draft extension value
>>>> (0x10)
>>>> clashes with the draft value used in the ALPN specification.
>>>>
>>>
>>> Given that the ALPN draft apparently has an allocated number, can we get
>>> one allocated to this I-D?
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>