> On May 17, 2018, at 1:31 AM, Peter Gutmann wrote:
>
>> And again, nobody has said that they intend to implement the proposed
>> mechanism - indeed, when asked, people have said that they won't.
>
> Doesn't that resolve the issue then? If no-one's going to implement it
> then it doesn't m
Melinda Shore writes:
>And again, nobody has said that they intend to implement the proposed
>mechanism - indeed, when asked, people have said that they won't.
Doesn't that resolve the issue then? If no-one's going to implement it
then it doesn't matter how many bits you use. Make it one bi
On 5/16/18 2:20 PM, James Cloos wrote:
> The sixteen bit field harms no one, and when defined and used provides
> significant benefit to many.
It is one of the peculiarities of the IETF (and engineers
in general, I guess) that when we sit down to design a
protocol most people will start talking ab
> "TL" == Ted Lemon writes:
TL> Melinda made a pretty serious technical objection. Your response is not
TL> responsive to her objection. She explicitly said that her objection was
TL> not the two bytes.
I don't see anything in her note today which is a technical objection.
And I've seen
We really need to get this published, and in the interest of
making progress I will not block the addition of two bytes
to the extension. I am highly reassured by Viktor's suggestion
that they will never be used, as unused fields with murky
semantics have never been shown to be a problem in IETF
p
> On May 16, 2018, at 2:38 PM, Christian Huitema wrote:
>
> Did you publish the proposed pinning draft already? That would certainly
> help clarifying the issue.
Only the proposed text defining the interim 16-bit field. The follow-on
specification has not yet been written. It has not to date
On 5/16/2018 11:14 AM, Viktor Dukhovni wrote:
>
>> On May 16, 2018, at 1:59 PM, Christian Huitema wrote:
>>
>> The way I understand it, your proposal is not so much to "reserve 16
>> bits" but rather to "include a 16 bit field defined as the pinning time
>> in hours". Or maybe, "reserve 16 bits a
> On May 16, 2018, at 1:59 PM, Christian Huitema wrote:
>
> The way I understand it, your proposal is not so much to "reserve 16
> bits" but rather to "include a 16 bit field defined as the pinning time
> in hours". Or maybe, "reserve 16 bits as set to zero on send and ignored
> on receive" in
On 5/16/2018 5:34 PM, Viktor Dukhovni wrote:
> For the record, the reason that we're confident that two bytes are
> enough is that DNS TTLs already take care of sub-hour continuity
> for any provided TLSA records. So units of hours are natural, and
> make 16 bits quite sufficient.
The way I unde
> On May 16, 2018, at 12:20 PM, Tom Ritter wrote:
>
> On the balance, I support adding the two bytes.
Thanks for responding, and sorry to frame the request as "please
support", I've previously tried to careful and ask people to
respond with their comments whatever they might be, and should
hav
On 15 May 2018 at 22:14, Viktor Dukhovni wrote:
> I therefore appeal to the readers who've so far stayed silent on this
> issue, to lend support to paving the way for a more broadly applicable
> downgrade-resistant protocol, by supporting the inclusion of a two byte
> field for that purpose.
Sorr
> On May 16, 2018, at 1:34 AM, Viktor Dukhovni wrote:
>
>> I would be grateful if you would have a consistent story on this.
>> Clearly, it's not just two bytes, or there wouldn't be a perceived
>> need for them. It's two bytes plus the associated semantics and
>> processing algorithms. In th
I have no pony in this race, but FWIW ~5 people on each side represents a
lack of consensus. A lack of consensus means that the work doesn't happen
in the working group.
Thomas, your response (sorry to pick on you!) illustrates another consensus
issue: consensus exists when all technical objecti
FWIW: I support the changes proposed by Viktor and others. In particular, I
support reserving 2 bytes for which the semantics will be defined in a
separate draft.
For me, the advantages of this proposal outweighs the disadvantage of
having to reserve 2 bytes that might, in worst case, never get use
El 2018-05-11 09:05, Nikos Mavrogiannopoulos escribió:
On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote:
Good to know. Does any implementation other than OpenSSL support
external PSKs? How do you distinguish between external PSKs and
resumption PSKs?
gnutls does. For external PSKs I
15 matches
Mail list logo
