Re: [TLS] padding bug

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.

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
>
>